KI-Agenten entwickeln, die den Produktivbetrieb überstehen

KI-Agenten-Entwicklung heißt: Software bauen, in der ein Sprachmodell entscheidet, welcher Schritt als Nächstes kommt, dafür echte Werkzeuge aufruft, das Ergebnis liest und erneut entscheidet — bis ein Ziel erreicht ist oder eine Grenze stoppt. Das Produkt ist nicht das Modell, sondern die Schleife darum. Genau dort steckt das Engineering: was der Agent aufrufen darf, wie Fehler zu ihm zurückkommen, wie Zustand zwischen Schritten getragen wird, was passiert, wenn er vom Kurs abkommt, und woran Sie hinterher erkennen, ob er die Arbeit erledigt hat. Ein Chatbot antwortet. Ein Agent handelt — und dieses Handeln macht daraus ein Softwareprojekt statt eines Prompts.

Ein funktionierender Prototyp für eine enge Aufgabe braucht meist ein bis drei Wochen. Diesen Prototypen so weit zu bringen, dass Sie ihn Kunden zeigen würden, dauert deutlich länger — typischerweise zwei bis vier Monate — und fast nichts davon geht ins Prompting. Es geht in Integrationen, die auf Arten scheitern, die das Modell abfangen muss, in ein Eval-Set, das Regressionen erkennt, in Berechtigungen, in Logs, aus denen man debuggen kann, und in den Übergabeweg an Menschen für alles, was der Agent nicht allein entscheiden sollte. Teams, die nur die Demo budgetieren, kommen über den Piloten nie hinaus.

Beginnen Sie mit dem Leichtesten, das die Aufgabe löst. Für einen einzelnen Agenten mit einer Handvoll Tools ist oft das SDK des Modellanbieters plus eine selbst geschriebene Schleife bereits die ganze Arbeit — und Sie können jeden Schritt debuggen. Zu einem Orchestrierungs-Framework greifen Sie, wenn Sie wirklich dauerhaften Zustand, verzweigten Kontrollfluss, Wiederholungen über lang laufende Schritte oder mehrere koordinierte Agenten brauchen. Der Preis eines Frameworks ist nicht die API, sondern dass genau die Teile, die Sie an einem schlechten Tag prüfen müssen, in fremder Abstraktion liegen. Halten Sie Prompts, Tool-Definitionen und Eval-Set außerhalb des Frameworks — dann ist ein Wechsel ein Tag Arbeit und keine Neuentwicklung.

Es gibt zwei Kosten, und Teams planen regelmäßig die falsche. Baukosten: ein enger interner Agent liegt typischerweise zwischen 8.000 und 30.000 $ Engineering; ein kundenseitiger Agent mit echten Integrationen, Evaluation und Monitoring eher bei 30.000 bis 120.000 $. Betriebskosten: Token-Ausgaben sind meist der kleinere Posten und am leichtesten zu senken — einfache Schritte auf ein günstigeres Modell routen, Caching, Kontext regelmäßig kürzen halbieren die Rechnung oft. Vergessen wird die Wartung: Modelle werden abgekündigt, APIs ändern sich, das Eval-Set muss neu laufen. Rechnen Sie mit rund 15–25 % der Baukosten pro Jahr.

Indem Sie begrenzen, was er tun kann, statt auf gutes Benehmen zu hoffen. Praktisch: Antworten auf abgerufene Dokumente stützen und die Quelle zitieren lassen; Tools mit strengen, typisierten Argumenten versehen und vor der Ausführung validieren; ein ehrliches „nicht gefunden“ zulassen und dem Agenten beibringen, dass „nichts“ ein zulässiges Ergebnis ist; Schrittzahl und Ausgaben pro Lauf deckeln; und vor alles Unumkehrbare — Zahlungen, Löschungen, Nachrichten an Kunden — ein menschliches Freigabetor setzen. Und dann messen: ein Eval-Set aus fünfzig echten Fällen, gerade den unangenehmen, sagt mehr über Verlässlichkeit als jedes Prompt-Tuning.

Nehmen Sie eine No-Code-Plattform, wenn die Aufgabe Standard ist, das Volumen überschaubar und eine falsche Antwort wenig kostet — internes FAQ-Routing, Lead-Triage, erste Antwortentwürfe. Sie führen wirklich schneller zu einem Ergebnis und lehren Sie, was die Aufgabe braucht. Bauen Sie selbst, wenn der Agent Ihre Systeme mit echten Rechten anfasst, wenn Latenz oder Stückkosten bei Ihrem Volumen zählen, wenn Sie eigene Evaluation und Audit-Trail brauchen oder wenn der Agent Teil Ihres Produkts ist. Der übliche Weg ist vernünftig: den Ablauf auf einer Plattform beweisen, dann die Teile neu bauen, die es verdient haben.