Bewährte Vorgehensweisen, wenn aus der Demo ein Produkt wird

Jedes agentische System hat eine Demo, die funktioniert. Der Agent erhält ein Ziel, ruft einige Tools auf, arbeitet sich durch die Aufgabe und liefert ein Ergebnis, das überzeugt. Die Demo ist schnell und beeindruckend genug, dass schon bald alle dieselbe Frage stellen: „Wann können wir damit in Produktion gehen?“

Dann geht das System in Produktion. Plötzlich trifft es auf echten Production Traffic, reale Kunden, externe APIs und reale Kosten. Die zuvor überzeugende Demo beginnt auf Arten zu scheitern, die auf der Bühne niemand gesehen hat. Eine Abhängigkeit läuft in ein Timeout. Ein Workflow wird nur zur Hälfte ausgeführt, bevor er abbricht. Der Agent führt dieselbe Aktion zweimal aus, weil er seinen aktuellen Zustand verloren hat. Oder schlimmer noch: Er verursacht unbemerkt Hunderte Dollar an API-Kosten, bevor es jemand bemerkt.

Die unangenehme Wahrheit ist, dass die Lücke zwischen einer beeindruckenden Demo und einem zuverlässigen Produkt nur wenig mit der Intelligenz des Modells selbst zu tun hat. Dasselbe Modell, das im Meeting überzeugt hat, läuft auch in Produktion. Der Unterschied liegt in all den Situationen, mit denen sich die Demo nie auseinandersetzen musste: Demos sind für den „Happy Path“ optimiert, während Produkte einen Grossteil ihrer Lebensdauer mit Failure Paths verbringen.

Um diese Lücke zu schliessen, braucht es einige Engineering-Muster, die in Konferenzvorträgen oder Launch-Videos selten im Mittelpunkt stehen, aber darüber entscheiden, ob einem AI-Agenten in Produktion tatsächlich vertraut werden kann. Keines davon ist besonders glamourös. Aber jedes einzelne ist entscheidend.

Muster 1 – Fehlerbehandlung bei Tool Calls und Retry-Strategie

Jeder Tool Call ist letztlich ein Netzwerkaufruf – und Netzwerkaufrufe können fehlschlagen. APIs sind vorübergehend nicht verfügbar. Verbindungen laufen in Timeouts. Rate Limits werden erreicht. Wenn Ihr Agent davon ausgeht, dass jeder Tool Call beim ersten Versuch erfolgreich ist, bleibt er nur bis zum ersten temporären Fehler zuverlässig.

Eine produktionsreife Retry-Strategie basiert auf drei Entscheidungen:

• Fehler klassifizieren. Bei manchen Fehlern ist ein Retry sinnvoll – etwa bei einem temporären Timeout oder einer „Service unavailable“-Antwort. Andere Fehler sind endgültig und sollten sofort zum Abbruch führen. Werden alle Fehler gleich behandelt, verzögert das lediglich unvermeidbare Fehler oder verschärft bestehende Störungen.
• Exponential Backoff mit Jitter. So verhindern Sie, dass mehrere Agenten gleichzeitig eine bereits überlastete Abhängigkeit erneut belasten.
• Anzahl der Versuche begrenzen und anschliessend an einen Dead-Letter-Prozess weiterleiten. Nach einer definierten Anzahl von Retries sollte die fehlgeschlagene Anfrage zur Untersuchung weitergeleitet werden, anstatt den Vorgang unbegrenzt zu wiederholen.

Nicht jeder Fehler sollte einen weiteren Versuch auslösen. Zu wissen, wann ein Retry sinnvoll ist, ist genauso wichtig wie zu wissen, wann der Prozess beendet werden sollte.

Muster 2 – Recovery nach Teilausfällen

Die schwierigsten Fehler sind nicht vollständige Ausfälle. Stellen Sie sich einen Agenten vor, der vier Systeme aufruft: Drei Operationen werden erfolgreich abgeschlossen, die vierte schlägt fehl. Das Gesamtsystem befindet sich nun in einem inkonsistenten Zustand – einige Änderungen wurden übernommen, andere fehlen. Genau an diesem Punkt enden viele Demos stillschweigend.

Produktionssysteme brauchen eine explizite Recovery-Strategie für solche Teilerfolge:

• Idempotency Keys – damit Operationen sicher wiederholt werden können, ohne doppelte Aktionen auszulösen.
• Ist-Zustand vor der Planung abgleichen – lesen Sie den tatsächlichen Systemzustand aus, anstatt davon auszugehen, dass vorherige Aktionen exakt wie erwartet abgeschlossen wurden.
• Kompensationsmechanismen – um bereits abgeschlossene Aktionen sicher rückgängig zu machen, wenn der Workflow nicht fortgesetzt werden kann.

Muster 3 – Human-in-the-Loop Checkpoints

Nicht jede Entscheidung sollte autonom getroffen werden. Die entscheidende Frage ist nicht, ob Menschen weiterhin einbezogen werden sollten, sondern an welchen Stellen ihre Beteiligung den grössten Mehrwert schafft.

Ein hilfreiches Designprinzip ist, den Blast Radius jeder Aktion zu bewerten: Was passiert, wenn der Agent falsch liegt? Aktionen, die irreversibel, finanziell relevant, rechtlich sensibel oder nach aussen sichtbar sind, benötigen häufig eine explizite Freigabe vor der Ausführung. Dazu gehören beispielsweise Kundenkommunikation, Zahlungsfreigaben, das Löschen von Daten oder das Deployment von Infrastruktur.

Ebenso wichtig ist, diese Freigabeschritte schlank zu halten. Wird Human Review zu aufwendig, werden Operatoren versuchen, ihn zu umgehen. Effektive Checkpoints liefern deshalb genau den Kontext, der für eine schnelle und fundierte Entscheidung benötigt wird, ohne den gesamten Durchsatz auszubremsen. Autonomie ist wertvoll – doch erst gezielte menschliche Kontrolle macht autonome Systeme vertrauenswürdig.

Muster 4 – Persistenter State über mehrere Agent Runs hinweg

Agent Workflows laufen häufig über längere Zeit – und solche Prozesse fallen früher oder später aus. Wenn ein Agent im neunten Schritt eines zwölfstufigen Workflows scheitert, bedeutet ein Neustart ab Schritt eins Zeitverlust, doppelte Arbeit und ein höheres Risiko für Inkonsistenzen.

Produktionssysteme speichern deshalb den Execution State über den gesamten Workflow hinweg. Pläne, abgeschlossene Schritte, Zwischenergebnisse und Ausführungsmetadaten sollten persistent gespeichert werden, damit ein unterbrochener Run genau dort fortgesetzt werden kann, wo er aufgehört hat.

Das ist einer der deutlichsten Unterschiede zwischen einer Demo und einem Produkt. Demos halten den State häufig nur im Arbeitsspeicher, weil nicht mit Fehlern gerechnet wird. Reale Systeme gehen dagegen davon aus, dass Fehler unvermeidbar sind. Persistenter State in Kombination mit idempotenten Operationen macht aus Abstürzen keine katastrophalen Ereignisse, sondern routinemässige Recovery-Szenarien.

Muster 5 – Cost Controls

Ein Agent, der in einer Schleife läuft, ist ein Agent, der Geld ausgibt. Anders als bei klassischer Software verursacht jeder zusätzliche Reasoning-Schritt und jeder unnötige Tool Call messbare Kosten. Ohne klare Limits verbraucht ein fehlerhaft arbeitender Agent nicht nur CPU-Zeit – sondern direkt Budget.

Produktionsreife AI-Agenten benötigen deshalb explizite Cost Controls:

• Token-Budgets für jeden Run.
• Ein Limit für Planungsiterationen, damit ein festgefahrener Agent nicht endlos weiterplant.
• Circuit Breakers, die Workflows mit unkontrolliertem Verhalten stoppen.
• Cost-per-Run Monitoring mit Alerts bei unerwarteten Anstiegen, bevor daraus teure Überraschungen werden.

Cost Controls sind nicht nur eine Optimierung – sie sind operative Schutzmechanismen. Ein Agent ohne klare Limits ist nicht nur ineffizient, sondern ein potenzieller Billing Incident.

Fazit

Eine erfolgreiche Demo beweist, dass ein agentisches System grundsätzlich funktioniert. Ein erfolgreiches Produkt beweist, dass es zuverlässig ist. Die Muster, die diesen Unterschied ausmachen, stehen auf Konferenzbühnen selten im Mittelpunkt, weil sie sich nur schwer in fünf Minuten demonstrieren lassen – niemand applaudiert einer gut durchdachten Retry-Strategie oder persistentem State. Doch genau diese Engineering-Entscheidungen bestimmen, ob Ihr System um 2 Uhr morgens unter Produktionslast weiterläuft, nachdem das Unerwartete unvermeidlich eingetreten ist.

Während Agentic AI vom Experiment in den produktiven Einsatz übergeht, entsteht der Wettbewerbsvorteil nicht durch die cleverste Demo. Er entsteht durch Systeme, die auch dann zuverlässig funktionieren, wenn die Realität weniger kooperativ ist als der „Happy Path“. Diese fünf Muster machen die Demo nicht beeindruckender. Sie machen aus ihr ein echtes Produkt.

Produktionsreife AI-Systeme zu entwickeln ist ebenso eine Engineering-Herausforderung wie eine AI-Herausforderung. Wir werden weiterhin die Muster, Erkenntnisse und praktischen Ansätze teilen, die wir beim Design und beim produktiven Einsatz agentischer Systeme sammeln. Folgen Sie unserem Insights Hub und unserer LinkedIn-Seite, um weitere Einblicke aus der Praxis zu erhalten.