Bevor du einen KI-Agenten baust, konfiguriere einen

«Wir sollten einen Agenten bauen» kann drei völlig unterschiedliche Projekte bedeuten.

Die eine Person meint damit, einen eigenen Workspace in ChatGPT, Claude oder einem Coding-Agenten einzurichten. Eine andere meint, ein paar Apps in einem visuellen Automatisierungs-Builder zu verbinden. Ein Engineering-Team hört dabei Authentifizierung, APIs, Datenbanken, Logs, Monitoring, Testing und jemanden, der den Pager trägt, wenn etwas schiefgeht.

Alle drei können sinnvoll sein. Sie haben aber völlig unterschiedliche Kosten und Verpflichtungen.

Für meinen eigenen Assistenten habe ich bewusst den dritten Weg gewählt. Ich habe einen Server gemietet, ein Open-Source-Agent-Framework von Hand installiert und ein Wochenende investiert, weil ich Agenten von innen verstehen wollte und nicht aus einer Keynote. Es hat funktioniert und läuft bis heute. Es hat mich aber auch mehrere Setups gekostet, die ich so gründlich zerschossen habe, dass nur die Wiederherstellung des ganzen Servers aus einem Backup zurückführte.

Für den Lerneffekt war das ein guter Deal. Für einen Job mit Deadline ist es ein schlechter — und genau das meinen die meisten, wenn sie sagen, sie wollten bei der Arbeit einen Agenten bauen.

Mein Standardansatz: zuerst einen bestehenden General-Purpose-Agenten konfigurieren. Gib ihm einen klar begrenzten Job, statische Dateien, klare Anweisungen und keinen Live-Schreibzugriff. Lass den Job mehrmals laufen, während jemand zuschaut. So siehst du, wo die eigentliche Unschärfe und das eigentliche Risiko liegen, bevor du aus einer groben Idee Software machst.

Eine API-Integration rettet keinen unklaren Job und keinen instabilen Prozess. Hängt die Arbeit von Live-Daten ab, beginne mit der schmalsten Nur-Lese-Verbindung, die du unter Aufsicht testen kannst.

Das hier ist Teil zwei von Der Agenten-Guide. Teil eins erklärt, wie du Chat, Workflows, Agenten und Autonomie unterscheidest. Hier mache ich aus diesem Denkmodell eine praktische Bauanleitung.

Was ein General-Purpose-Agent ist

«General-Purpose-Agent» hat in der Branche keine feste Definition. Ich verwende den Begriff für einen breit einsetzbaren, wiederverwendbaren Agenten, der innerhalb einer Umgebung viele Arten von Zielen bewältigen kann.

Ein Coding-Agent kann in einem Softwareprojekt fast alles lesen und bearbeiten, Terminal-Befehle ausführen, Dokumentation durchsuchen und Versionskontroll-Änderungen verwalten. Ein Business-Agent kann Dateien, Tabellen, E-Mail, Kalender und verbundene Business-Apps nutzen. Ein Recherche-Agent kann breit recherchieren, Dokumente analysieren und Reports erstellen.

Keiner davon ist wirklich universell. Jeder ist nur innerhalb des Workspace und der Tools, die er bekommen hat, universell einsetzbar.

Der Vorteil ist Flexibilität. Ich kann denselben Coding-Agenten heute bitten, einen Guide hinzuzufügen, morgen einen kaputten Build zu untersuchen und nächste Woche einen Pull Request zu reviewen. Ich brauche keine eigene Anwendung für jeden Job.

Der Nachteil ist der Führungsaufwand. Ich wähle das Ziel, liefere fehlenden Context, beurteile das Ergebnis und entscheide, wie es weitergeht.

Diesen Generalisten kannst du deutlich besser machen, ohne neue Software zu schreiben. Füge Projektanweisungen, kuratiertes Wissen, gezielt freigegebene Connectors und wiederverwendbare Prozeduren hinzu. Das Ergebnis nenne ich einen konfigurierten General-Purpose-Agenten: einen Generalisten, den du in deine Umgebung und Arbeitsweise eingearbeitet hast. Du weist ihm weiterhin unterschiedliche Jobs zu und beurteilst jedes Ergebnis selbst.

Mein Guide zu Project Memory zeigt, wie diese Ebenen in einem aktuellen Produkt aussehen. Das Muster lässt sich weit darüber hinaus anwenden.

Was einen massgeschneiderten Agenten unterscheidet

Ein massgeschneiderter Agent übernimmt eine bekannte Art von Arbeit unter einem festen Betriebsvertrag. Seine Eingaben, Ausgaben, Grenzen, sein Fehlerpfad und sein Verantwortlicher werden einmal festgelegt, statt bei jedem Job neu vom Nutzer zusammengebaut zu werden.

Stell dir einen konfigurierten General-Purpose-Agenten als gut ausgestatteten Arbeitsplatz für eine Person vor. Ein massgeschneiderter Agent ist ein wiederholbarer Job, für den jemand verantwortlich ist, wenn er schiefgeht.

Konfigurierter General-Purpose-Agent	Massgeschneiderter Agent
Nimmt unterschiedliche Ziele an, die ihm Aufgabe für Aufgabe zugewiesen werden	Nimmt eine bekannte Art von Arbeit an, ausgelöst durch einen definierten Trigger
Bietet einen breiten Workspace und Werkzeugkasten	Erhält nur den jobspezifischen Context, die Tools und die Befugnisse
Die Person wählt oder liefert die Eingaben für die aktuelle Aufgabe	Erwartete Eingaben sind definiert und werden vor jedem Lauf geprüft
Die Ausgabe folgt der aktuellen Anfrage	Die Ausgabe oder Systemänderung folgt einem festen Vertrag
Die Person legt aufgabenspezifische Erfolgskriterien fest und beurteilt das aktuelle Ergebnis	Dieselben Ergebnisprüfungen sind in jeden Lauf eingebaut
Freigaben werden für den aktuellen Job festgelegt	Freigabepunkte sind fest im Dienst eingebaut
Probleme gehen zurück an die aktuelle Person	Wiederherstellung und Eskalation gehen an einen benannten Verantwortlichen

Memory, Zeitpläne, eng gefasste Tools und automatisierte Prüfungen entscheiden nicht über die Kategorie. Ein General-Purpose-Agent kann alle vier haben. Dieselbe Aufgabe jeden Montag laufen zu lassen, macht daraus noch keinen operativen Dienst.

Die Grenze verläuft auch unabhängig vom Code. Ein No-Code-Setup kann massgeschneidert sein. Tausend Zeilen Agent-Framework können trotzdem nur eine vage Demo ergeben.

Wann sich der Mehraufwand für eine massgeschneiderte Lösung lohnt

Bleib beim konfigurierten Generalisten, solange sich der Prozess noch verändert, eine sachkundige Person jeden Fall bearbeitet oder das Ergebnis ein Entwurf bleibt. Die General-Purpose-Umgebung gibt dir Flexibilität und deckt Annahmen günstig auf.

Ein massgeschneiderter Dienst wird sinnvoll, sobald mehrere Bedingungen erfüllt sind:

• der Job wiederholt sich oft genug, um den Wartungsaufwand zu rechtfertigen;
• die erwarteten Eingaben und Ausgaben ändern sich nicht mehr jede Woche;
• mehrere Personen brauchen dasselbe Ergebnis;
• Live-Systeme oder Event-Trigger müssen angebunden werden;
• die Prüfungen und Freigabegrenzen lassen sich klar formulieren; und
• die Organisation braucht durchgängige Logs, Zugriffskontrollen, Kostenlimits und klare Verantwortlichkeiten.

Volumen allein reicht nicht. Einen instabilen Prozess im grossen Massstab zu automatisieren, produziert nur schneller Ausnahmefälle. Und «reguliert» heisst nicht automatisch, dass eigener Code sicherer ist. Eine freigegebene Plattform mit ausgereiften Identitäts-, Audit- und Datenkontrollen kann die bessere Grundlage sein, bis ein eigenes System da mithalten kann.

Wähle deine Ausbaustufe

Es gibt drei sinnvolle Wege zu bauen.

Einen General-Purpose-Agenten konfigurieren

Füge Anweisungen, Dateien, wiederverwendbare Prozeduren und freigegebene Connectors in einem Produkt hinzu, das du schon nutzt. Das ist der richtige Startpunkt für persönliche Arbeit, interne Entwürfe, Recherche und umkehrbare Aufgaben. Du bekommst das meiste vom Lerneffekt bei geringstem Aufwand.

Einen No-Code- oder Low-Code-Prozess bauen

Füge ein Formular, einen Zeitplan oder einen Event-Trigger hinzu, lass einen Agenten den unklaren Mittelteil übernehmen, und kehre danach zu festen Workflow-Schritten und menschlichen Freigaben zurück. Das funktioniert, wenn sich der Prozess wiederholt und bestehende Connectors die beteiligten Systeme abdecken.

Eine Agent-Anwendung bauen

Das ist ein Softwareprodukt. Es braucht Nutzeridentität und Zugriffskontrollen, massgeschneiderte Verbindungen, einen Aufgabenstatus, Logs, Testing, Fehlerbehebung, Monitoring und laufenden Support. Wähle diesen Weg, wenn die nötige Kontrolle, Integration, Audit-Nachweisbarkeit, Skalierung oder Produktdifferenzierung den Besitz dieser Software rechtfertigt.

Starte oben. Steig nur runter, wenn dich eine erprobte Grenze dazu zwingt.

Schreib den Job auf, bevor du den Agenten baust

Vermeide breite Ambitionen wie «einen Assistenten für Marketing». Wähl einen Job, den du schon verstehst.

Als durchgehendes Beispiel nutze ich in diesem Guide eine wöchentliche Kampagnen-Review. Der Agent bekommt drei freigegebene Quellen, prüft Performance und Budget, markiert fehlende Belege und entwirft Entscheidungen, die eine Person freigibt.

Schreib den Betriebsvertrag, bevor du einen Builder oder ein Software Development Kit (SDK) anfasst:

Job: Die wöchentliche Kampagnen-Review vorbereiten.
Auslöser: Ich starte sie jeden Montag manuell.
Eingaben: Freigegebener Analytics-Export, Kampagnenplan und Budget-Tabelle.
Erlaubte Tools: Diese drei Quellen lesen; Summen in einer Tabelle berechnen.
Ergebnis: Einseitige Review mit Ergebnissen, Auffälligkeiten und Entscheidungsvorschlägen.
Fertigstellungskriterium: Jede Zahl stimmt mit einer genannten Quelle überein; Lücken werden markiert.
Freigabe einholen vor: Änderungen am Kampagnen-Tracker oder dem Versand von irgendetwas.
Niemals: Eine fehlende Zahl schätzen oder eine Quelldatei verändern.
Bei Fehlern: Anhalten und die fehlenden Daten oder das fehlgeschlagene Tool auflisten.
Verantwortlich: Kampagnenleitung.

Dieser Vertrag leistet mehr als die Wahl eines Agent-Frameworks. Er macht die unklaren Stellen sichtbar: was den Job auslöst, woher die Fakten kommen, welche Aktionen erlaubt sind, wie Erfolg geprüft wird und wer sich um Fehler kümmert.

Kannst du diese Felder nicht ausfüllen, bist du noch nicht so weit, die Arbeit zu automatisieren. Mach sie zuerst manuell und lern den Prozess kennen.

Bau es in sechs Stufen

1. Führ den Job in einem General-Purpose-Agenten aus

Öffne ein eigenes Projekt oder einen eigenen Workspace in dem KI-Tool, das deine Firma bereits freigegeben hat. Trag den Vertrag in die Projektanweisungen ein, füge die drei Quelldateien hinzu und lass dir einen Entwurf erstellen. Verbinde noch keine Live-Konten.

Erledige denselben Job parallel selbst. Beobachte, wo der Agent zögert, rät, die falsche Frage stellt oder zur falschen Quelle greift. Die erste Version kann aus nicht mehr bestehen als einem Projekt, einer Instruction-Datei und ein paar Dokumenten.

So lernst du den echten Prozess kennen, bevor du ihn automatisierst.

2. Mach aus dem, was funktioniert hat, eine wiederverwendbare Prozedur

Speichere die Anweisungen als wiederverwendbaren Skill, als Template oder als Standard-Vorgehensweise. Nimm Beispiele für gute Ergebnisse und die Grenzfälle auf, die du gefunden hast. Beschreib die verfügbaren Tools so klar, dass das Modell sie auseinanderhalten kann.

Kodiere nicht den Prozess, den du dir wünschst. Kodiere den, der sich an echten Fällen bewährt hat.

Dieser Schritt macht aus einem Agenten etwas Eigenes statt etwas Generisches. Für mein eigenes Setup habe ich eine Prozedur fürs Hinzufügen eines Tool-Reviews auf dieser Site geschrieben: das genaue Format, wohin die Datei kommt, welche Felder wichtig sind, wie meine Einschätzung klingen soll. Danach musste ich es nicht mehr jedes Mal neu erklären. Es ist derselbe Move wie beim Onboarding eines brillanten neuen Teammitglieds — am ersten Tag fähig, aber ahnungslos, wie dein Laden tickt, bis es jemand aufschreibt.

3. Gib ihm das kleinstmögliche sinnvolle Set an Tools

Beginne mit Lesen. Lass den Agenten Dokumente durchsuchen, Einträge prüfen und eine vorgeschlagene Aktion vorbereiten. Füge Schreibzugriff erst hinzu, wenn sich die Nur-Lese-Version bewährt hat.

Eine einzelne, eng gefasste Aktion namens «Kampagnen-Review-Entwurf erstellen» ist sicherer und einfacher zu testen als die Berechtigung, jeden Eintrag in einem Marketing-System zu bearbeiten. Gutes Tool-Design begrenzt die Fehler, die das Modell machen kann.

4. Setz Kontrollpunkte vor alles, was Folgen hat

Verlang eine Freigabe, bevor externe Nachrichten verschickt, Zahlungen ausgelöst, Einträge geändert, Deployments in Produktion vorgenommen, Löschungen durchgeführt oder Entscheidungen über Personen getroffen werden.

Der Kontrollpunkt bei meiner eigenen Assistentin ist eine einzige Nachricht lang. Sie macht die Änderung, baut eine Vorschau und schickt mir einen Link. Nichts geht live, bis ich zurückschreibe, dass es gut aussieht. Genau dieser eine Schritt ist der Grund, warum ich entspannt bin, wenn sie von meinem Handy aus eine öffentliche Site bearbeitet, und er kostet mich etwa fünf Sekunden.

Halt regelbasierte Prüfungen in Software oder Workflow-Regeln. Pflichtfelder, Beträge, Berechtigungen und Policy-Schwellenwerte sollten nicht davon abhängen, dass ein LLM sie sich im richtigen Moment merkt.

Genau hier übernehmen Code, Automatisierung und KI unterschiedliche Jobs. Starke Systeme kombinieren sie, statt das Modell alles improvisieren zu lassen.

5. Teste Ergebnisse, nicht Zuversicht

Sammle echte Fälle: normale Beispiele, fehlende Informationen, widersprüchliche Anweisungen, ungewöhnliche Formate, Tool-Fehler und bekannte vergangene Fehler. Leg fest, was am Ende jedes Laufs zutreffen muss.

Wenn ein Agent behauptet, er habe einen Eintrag erstellt, prüf, ob der Eintrag mit den richtigen Feldern existiert. Wenn er sagt, die Tests seien grün, führ die Tests aus. Anthropics Guide zur Agent-Evaluierung zieht dieselbe Grenze zwischen einem überzeugenden Transcript und dem tatsächlichen Zustand der Umgebung.

Behalte jeden nützlichen Fehlschlag. Diese Fälle werden zu einem Regressions-Set, das du jedes Mal neu durchläufst, wenn du Modell, Anweisungen, Wissen oder Tools änderst.

6. Füge unbeaufsichtigten Betrieb zuletzt hinzu

Zeitpläne, Hintergrund-Trigger und automatische Schreibvorgänge kommen erst, wenn die beaufsichtigte Version läuft. Leg eine maximale Anzahl Schritte, ein Zeit- oder Ausgabenlimit und eine klare Übergabe fest, wenn der Agent hängen bleibt.

Jetzt brauchst du ein Protokoll zu jedem Lauf: welche Version lief, was gelesen wurde, welche Tools aufgerufen wurden, was sich geändert hat, was es gekostet hat, wer es freigegeben hat und warum er gestoppt ist. Verlassen sich mehrere Personen auf den Dienst, muss jemand für Wartung und Incident Response verantwortlich sein.

Die Sicherheitsanforderungen steigen mit der Befugnis

Ein Agent, der in eine temporäre Datei schreibt, kostet dich im schlimmsten Fall Zeit. Ein Agent, der Nachrichten verschickt, Produktionsdaten ändert oder mit persönlichen Daten arbeitet, kann anderen Menschen schaden.

Nutze bei der Arbeit nur dein von der Firma freigegebenes Setup und genehmigte Datenquellen. Ein privates KI-Konto mit Firmen-E-Mail, Kundendaten, Gesundheitsdaten oder Personalakten zu verbinden, ist ein Sicherheits- und Datenschutzproblem — egal wie bequem der Workflow aussieht.

Freigabe ist nur der Ausgangspunkt. Bestätige zusätzlich, dass die Nutzung erlaubt ist, schick nur die minimal nötigen Daten, die der Job braucht, wisse, wie lange der Anbieter sie speichert und welche anderen Anbieter sie erhalten, und leg fest, wer Prompts und Lauf-Protokolle lesen darf. Diese Protokolle können dieselben sensiblen Inhalte enthalten wie die ursprünglichen Eingaben.

Mein eigener Ansatz ist hier bewusst langweilig, und das meine ich als Empfehlung. Der Agent läuft auf einem günstigen dedizierten Server, auf dem sonst nichts liegt, also ist der schlimmste Fall ein Neuaufbau. Er bekommt den Zugriff, den ein gegebener Job braucht, und nicht den Generalschlüssel für alles andere.

Dann wende ein paar langweilige Kontrollen an:

• Gib nur den minimal nötigen Zugriff für den Job. Zuerst nur Lesen.
• Halt frühe Läufe in einer Sandbox, einer Kopie, einem Entwurfsordner oder einem Testkonto.
• Verlang eine Freigabe durch eine Person für irreversible oder nach aussen sichtbare Aktionen.
• Behandle Webseiten, E-Mails und Dokumente als nicht vertrauenswürdige Eingabe. Eine Datei kann dem Agenten sagen, er solle seine Regeln ignorieren und eine Kundenliste hochladen. Setz Berechtigungen und Freigabepunkte ausserhalb des Inhalts durch, den der Agent liest.
• Halt Backups und einen getesteten Weg bereit, Änderungen rückgängig zu machen.
• Prüf das veränderte System, statt der Behauptung des Agenten zu vertrauen, es habe geklappt.
• Protokolliere genug vom Lauf, um einen Fehler rekonstruieren zu können.

OpenAIs praktischer Guide zum Bauen von Agenten empfiehlt, Tools anhand von Faktoren wie Lese- vs. Schreibzugriff, Umkehrbarkeit, Kontoberechtigungen und finanzieller Auswirkung zu bewerten. Das ist nützlicher als ein einziger globaler Berechtigungsschalter.

Für Systeme, die rechtliche Entscheidungen, Anstellungen, Kredite, Gesundheit oder andere folgenreiche Entscheidungen beeinflussen, ist ein vielversprechender Prototyp noch lange nicht produktionsreif. Zieh Engineers, Security- und Privacy-Spezialistinnen, Fachverantwortliche und Anwälte hinzu, bevor das System echte Befugnisse bekommt.

Deine erste Version sollte sich fast zu klein anfühlen

Wähl einen wöchentlichen Job. Schreib den Vertrag. Leg drei statische Quelldateien in einen eigenen Workspace im freigegebenen KI-Produkt, das du schon hast. Lass dir einen Entwurf erstellen. Halt Live-Konten getrennt.

Lass diese Version fünfmal laufen. Speichere die Fehlschläge. Schärf die Anweisungen und Prüfungen nach. Erst dann entscheide, ob die nächste Grenze einen Connector, einen Workflow oder eigene Software verlangt.

So baust du deinen eigenen Agenten, ohne aus Versehen ein Softwareprojekt zu starten.

---

Wenn dir die Begriffe «Agent», «Workflow» und «Autonomie» noch schwammig vorkommen, starte mit Teil eins: Ist das wirklich ein KI-Agent?. Für einen konkreten General-Purpose-Coding-Agenten lies Claude Code: Wenn KI aufhört zu reden und anfängt zu handeln. Um Delegation und das Setzen von Berechtigungen zu üben, ohne ein echtes System zu riskieren, spiel The Company Simulator.