Einen KI-Agenten bauen, der im Produktivbetrieb wirklich funktioniert

Die Demo lief perfekt. Natürlich tat sie das: Ich hatte sie fünfmal durchgespielt, bevor ich sie überhaupt jemandem zeigte. Zwei Wochen später, zu nachtschlafender Stunde, hängte sich derselbe Agent daran auf, immer und immer wieder dasselbe defekte Tool aufzurufen, verbrannte sein Budget und lieferte am Ende gar nichts. Genau diese Kluft, zwischen der Version, die einen Raum begeistert, und der Version, die still versagt, wenn niemand hinsieht, ist die ganze Geschichte davon, KI-Agenten in den Produktivbetrieb zu bringen. Ich betreibe meinen, Tree AI, inzwischen seit über einem Jahr jeden einzelnen Tag. Fast alles, was ich wirklich über Agenten weiß, habe ich in dieser Kluft gelernt, nicht in der Demo.

Das Wichtigste in Kürze

• Eine Demo beweist, dass ein Agent einmal Erfolg haben kann. Im Produktivbetrieb geht es darum, was er tut, wenn er scheitert.
• Vier Dinge bringen Agenten in der realen Welt zum Scheitern: aufgeblähter Kontext, Tool-Fehler, Endlosschleifen und langsamer Persona-Drift. Die Lösungen sind bewusst langweilig.
• Der Agent, der den Produktivbetrieb übersteht, ist nicht der leistungsfähigste. Es ist der, der elegant scheitert und sauber wieder hochkommt.

Was er tatsächlich tut

Tree AI läuft rund um die Uhr auf demselben kleinen Server wie der Rest meiner Infrastruktur. Ich spreche mit ihm: Sprache rein über Speech-to-Text, eine Antwort, Sprache wieder raus. Er kümmert sich um einen Teil meines Zuhauses, behält Kalender und E-Mail im Auge, betreibt die Marktanalyse-Pipeline, die in meine Telegram-Kanäle publiziert, und wechselt je nach Anforderung die Persona. Er ist das Werkzeug, mit dem ich meinen Tag organisiere, und genau deshalb sind seine Fehler nie theoretisch: Sie passieren mir, an einem Dienstag, wenn ich gebraucht hätte, dass die Sache funktioniert.

Die vier Arten, wie ein Agent stirbt

Die Fehler sind erstaunlich konsistent, wenn man eine Weile mit einem gelebt hat.

Der erste ist der Kontext. Lange Gespräche häufen sich an, bis man an die Grenze stößt oder die Antworten still zu Brei zerfallen. Meine Antwort ist strukturierte Verdichtung: hin und wieder wird das Gespräch in ein kompaktes Objekt zusammengefasst, und der Agent startet mit dieser Zusammenfassung als Gedächtnis von Neuem. Nicht elegant, aber es hält.

Der zweite ist der Tool-Fehler. Tools fallen aus, APIs laufen in Timeouts, Rate Limits greifen. Ein Agent, der beim ersten Tool-Fehler abstürzt, ist nutzlos, weil Tools ständig ausfallen. Die Lösung ist das Gegenteil von clever, dazu komme ich gleich zurück.

Der dritte ist die Todesschleife. Der Agent gerät durcheinander, versucht dieselbe Aktion, scheitert und versucht es erneut, endlos, wenn man ihn lässt. Also lasse ich ihn nicht. Jeder Lauf hat eine harte Obergrenze für Tool-Aufrufe; ist sie erreicht, stoppt er und berichtet, was er versucht hat. Diese eine Grenze hat mich öfter vor entgleisten Schleifen bewahrt, als ich zählen kann.

Der vierte ist der stille: Persona-Drift. Über ein langes Gespräch hinweg entfernt sich der Agent langsam davon, wie er sich verhalten soll. Erst verschiebt sich die Sprache, dann der Ton, dann, der gefährliche Teil, die Entscheidungen. Die Lösung ist, den System-Prompt regelmäßig erneut einzuspeisen, statt darauf zu vertrauen, dass die anfänglichen Anweisungen tausend Runden später noch gelten.

Ein Agent, der beim ersten fehlgeschlagenen Tool-Aufruf abstürzt, ist nur eine Demo mit zusätzlichen Schritten.

Das Protokoll schlägt die Intelligenz

Hier kommt die kontraintuitive Lektion. Wenn ein Tool fehlschlägt, lass das Modell sich nicht improvisierend herauswinden. Gib ihm ein festes Protokoll: Wenn Tool X fehlschlägt, versuche Y, dann Z, dann sag klipp und klar, dass es nicht ging. Fest verdrahtete Fallback-Ketten schlagen die „intelligente" Wiederherstellung jedes Mal, denn die Improvisation des Modells ist genau die Stelle, aus der das unvorhersehbare, teure, schwer zu debuggende Verhalten kommt. In einem Agenten ist der langweilige, deterministische Pfad ein Feature.

MCP hat die Form der Arbeit verändert

Das Model Context Protocol war das Beste, was der Agentenentwicklung in letzter Zeit passiert ist. Davor bedeutete jede Fähigkeit eine maßgeschneiderte Integration, die an einen einzigen Client geklebt war. Mit MCP schreibt man einmal einen Server, und jeder kompatible Agent kann ihn entdecken und nutzen. Meine Hausautomatisierung, mein Kalender und mein Dateizugriff stellen alle MCP-Server bereit; der Agent verbindet sich und findet von selbst heraus, was verfügbar ist. Eine neue Fähigkeit hinzuzufügen wurde vom Projekt zur Routinearbeit: Server schreiben, Agent neu starten, fertig.

Was ich jemandem raten würde, der heute anfängt

Nimm ein echtes Modell: Der Abstand zwischen einem Spitzenmodell und einem kleinen offenen ist bei chaotischen Aufgaben der realen Welt enorm, und am Modell zu sparen kostet dich anderswo meist mehr. Baue Beobachtbarkeit vor Funktionen, denn du kannst nicht debuggen, was du nicht sehen kannst. Fang mit genau einem Anwendungsfall an und mach ihn wirklich solide, bevor du einen zweiten hinzufügst. Und akzeptiere von vornherein, dass es auf Arten kaputtgehen wird, die du dir nicht ausgemalt hast.

Der Agent, der im Produktivbetrieb funktioniert, ist nie der mit der längsten Liste an Fähigkeiten. Es ist der, der in seinem Rahmen bleibt, ohne Drama scheitert und sich von selbst erholt. Was ist der Teil deines Tages, den du tatsächlich etwas anvertrauen würdest, das so elegant scheitert, und was müsste es zuerst beweisen?