Ein Agent ruft ein System auf, doch die Antwort kommt nicht. Ein Tool liefert einen Fehler. Oder die Aktion wurde ausgeführt, aber der Agent erhält keine Bestätigung. Für klassische Software lassen sich solche Fälle relativ eindeutig definieren: Timeout, Fehlercode, Retry, Abbruch. Das Verhalten ist im Code festgelegt und bei jedem Durchlauf gleich.
Bei einem AI-Agenten kommt eine zusätzliche Frage hinzu: Was macht der Agent als Nächstes? Erneut versuchen? Eine andere Methode verwenden? Den Vorgang abbrechen? Oder einen Menschen informieren? Die Antwort trifft nicht mehr ausschließlich der Entwickler zur Entwicklungszeit, sondern zum Teil das System zur Laufzeit.
Je autonomer ein Agent arbeitet, desto wichtiger wird deshalb nicht nur die Frage, was er im Normalfall tun soll, sondern auch, wie er mit Fehlern umgehen soll. Fehlerbehandlung wird damit zu einem zentralen Bestandteil agentischer Architektur.
Warum klassische Fehlerbehandlung nicht ausreicht
In einer herkömmlichen Integration ist der Ablauf deterministisch. Ein Prozess ruft Schritt A auf, dann Schritt B, dann Schritt C. Für jeden Schritt ist definiert, was bei einem Fehler passiert. Wer den Code liest, kann jeden möglichen Pfad nachvollziehen.
Ein Agent arbeitet anders. Er erhält ein Ziel, eine Menge von Tools und Kontext. Welche Tools er in welcher Reihenfolge aufruft, entscheidet er selbst. Das ist seine Stärke: Er kann mit Situationen umgehen, die niemand vorab vollständig modelliert hat. Es ist aber auch der Grund, warum Fehler bei Agenten eine neue Qualität bekommen.
Wenn ein Tool-Aufruf scheitert, interpretiert der Agent die Fehlermeldung und leitet daraus seinen nächsten Schritt ab. Dabei kann er richtig liegen. Er kann aber auch einen Aufruf wiederholen, der nicht wiederholt werden darf. Er kann einen Umweg wählen, der Berechtigungen umgeht. Oder er kann die Fehlermeldung als Erfolg interpretieren und weitermachen, als wäre nichts passiert.
Das Problem ist nicht, dass Agenten Fehler machen. Das Problem ist, dass ihre Reaktion auf Fehler ohne klare Regeln unvorhersehbar wird.
Vier Arten von Fehlern, mit denen ein Agent umgehen muss
Nicht jeder Fehler ist gleich. Für die Architektur hilft es, vier Kategorien zu unterscheiden:
| Fehlertyp | Beispiel | Typisches Risiko |
|---|---|---|
| Technischer Fehler | Timeout, HTTP 500, System nicht erreichbar | Agent versucht es unkontrolliert erneut |
| Fachlicher Fehler | Tool antwortet, aber das Ergebnis ist unplausibel oder verletzt eine Regel | Agent arbeitet mit falschen Daten weiter |
| Unklarer Zustand | Aktion wurde ausgelöst, Bestätigung fehlt | Doppelte Ausführung oder fälschlicher Abbruch |
| Eigener Fehler des Agenten | Falsches Tool, falsche Parameter, falsche Schlussfolgerung | Fehler wird nicht erkannt und pflanzt sich fort |
Technische Fehler sind am einfachsten zu behandeln, weil sie aus der klassischen Integration bekannt sind. Fachliche Fehler und unklare Zustände sind deutlich anspruchsvoller. Und die vierte Kategorie ist neu: Ein Agent kann Fehler machen, die kein System als Fehler meldet, weil der Aufruf technisch korrekt war.
Der gefährlichste Fall: Die Aktion wurde ausgeführt, aber keiner weiß es
Von den vier Kategorien verdient der unklare Zustand besondere Aufmerksamkeit. Ein Agent legt ein Ticket an, löst eine Bestellung aus oder verschickt ein Angebot. Der Aufruf geht raus. Dann bricht die Verbindung ab, oder das Zielsystem antwortet nach dem Timeout. Der Agent weiß nicht, ob die Aktion stattgefunden hat.
Was passiert jetzt? Wenn der Agent den Aufruf wiederholt, existiert das Ticket möglicherweise doppelt. Die Bestellung wird zweimal ausgelöst. Der Kunde erhält zwei Angebote mit unterschiedlichen Nummern. Wenn der Agent hingegen abbricht, obwohl die Aktion durchgeführt wurde, ist der Prozess aus Sicht des Agenten gescheitert, aus Sicht des Zielsystems aber erfolgreich. Beide Seiten haben einen anderen Stand.
Dieses Problem ist nicht neu. In der Systemintegration wird es seit Jahren über Idempotenz gelöst: Ein Aufruf mit demselben Idempotency Key führt beim zweiten Mal nicht zu einer zweiten Aktion, sondern liefert das Ergebnis der ersten. Für Agenten ist dieses Prinzip nicht optional. Jede schreibende Aktion, die ein Agent auslösen darf, sollte idempotent sein oder vor der Wiederholung eine Statusabfrage erlauben.
Regel für Agenten: Bevor ein schreibender Aufruf wiederholt wird, muss geklärt sein, ob die erste Ausführung stattgefunden hat. Wer das nicht prüfen kann, darf nicht wiederholen.
Erneut versuchen ist keine Strategie
„Bei Fehler nochmal versuchen" klingt nach einer vernünftigen Anweisung. Ohne Regeln ist sie aber gefährlich. Ein Agent, der einen fehlschlagenden Aufruf zehnmal wiederholt, erzeugt Last auf einem System, das ohnehin schon Probleme hat. Ein Agent, der einen fachlichen Fehler wie einen technischen behandelt, versucht es mit denselben falschen Daten immer wieder.
Eine belastbare Retry-Strategie beantwortet mindestens vier Fragen:
- Was darf wiederholt werden? Lesende Aufrufe fast immer. Schreibende Aufrufe nur, wenn sie idempotent sind.
- Wie oft und in welchem Abstand? Eine feste Obergrenze mit wachsendem Abstand zwischen den Versuchen, nicht in Endlosschleife.
- Welche Fehler rechtfertigen einen Retry? Ein Timeout ja. Eine Validierungsmeldung nein, denn derselbe Aufruf wird wieder scheitern.
- Wann ist Schluss? Ein Retry-Budget pro Vorgang, nach dessen Ausschöpfung ein anderer Pfad greift.
Wichtig ist, dass diese Regeln nicht vom Agenten selbst festgelegt werden. Sie sind Teil der Tool-Schicht, die zwischen Agent und Zielsystem liegt.
Alternative Wege: Wo Flexibilität hilft und wo sie schadet
Die Fähigkeit, bei einem Fehler einen anderen Weg zu wählen, ist einer der Gründe, warum Unternehmen Agenten überhaupt einsetzen. Wenn die Live-Abfrage des Lagerbestands scheitert, kann der Agent auf einen zwischengespeicherten Wert zurückgreifen und diesen als solchen kennzeichnen. Wenn ein Suchdienst nicht antwortet, kann er einen zweiten Datenpfad nutzen.
Diese Flexibilität braucht aber Grenzen. Ein Agent, der bei einem Berechtigungsfehler einen anderen Weg zu denselben Daten sucht, umgeht eine Regel, die aus gutem Grund existiert. Ein Agent, der bei einem gescheiterten Freigabeschritt die Aktion trotzdem ausführt, hebelt einen Kontrollpunkt aus.
Der Unterschied liegt in der Art des Fehlers. Technische Nichtverfügbarkeit rechtfertigt Alternativen. Eine fachliche Ablehnung, eine fehlende Berechtigung oder ein Validierungsfehler sind keine Hindernisse, die umgangen werden sollen. Sie sind Entscheidungen des Systems, die der Agent respektieren muss. Welche Fallbacks erlaubt sind, gehört deshalb explizit definiert, nicht dem Ermessen des Modells überlassen. Wie sich solche Grenzen in Governance-Regeln übersetzen lassen, haben wir an anderer Stelle beschrieben.
Abbrechen und eskalieren: Sauber aufhören ist eine Fähigkeit
Irgendwann ist der Punkt erreicht, an dem der Agent nicht weiterkommen sollte. Retry-Budget ausgeschöpft, kein zulässiger Alternativpfad, oder eine Situation, die eine menschliche Entscheidung erfordert. Dann muss der Agent abbrechen und eskalieren.
Ein sauberer Abbruch ist anspruchsvoller, als es klingt. Wenn der Agent bereits drei von fünf Schritten ausgeführt hat, hinterlässt ein einfaches Stoppen einen halbfertigen Zustand: Das Ticket existiert, der Kunde wurde aber nicht informiert. Die Bestellung ist angelegt, die Reservierung im Lager fehlt. Für solche Fälle braucht es Kompensationsschritte, die den Zustand entweder vervollständigen oder kontrolliert zurücknehmen. Wer aus der Integrationswelt kommt, kennt dieses Muster als Saga.
Die Eskalation an einen Menschen ist nur dann hilfreich, wenn sie Kontext mitliefert. „Fehler bei der Verarbeitung" hilft niemandem. Nützlich ist eine Übergabe, die enthält:
- Was das Ziel des Vorgangs war
- Welche Schritte bereits ausgeführt wurden und welche nicht
- Welcher Fehler an welcher Stelle aufgetreten ist
- Welche Wiederholungen und Alternativen bereits versucht wurden
- Welcher Zustand in den beteiligten Systemen jetzt vorliegt
Ein Mensch, der diese Informationen erhält, kann in Minuten entscheiden. Ein Mensch, der nur eine Fehlermeldung bekommt, muss die Situation erst rekonstruieren.
Fehlerbehandlung gehört in die Architektur, nicht in den Prompt
Ein häufiger Ansatz besteht darin, dem Agenten im System-Prompt Verhaltensregeln für Fehlerfälle mitzugeben: „Wenn ein Tool fehlschlägt, versuche es maximal zweimal erneut und informiere dann den Nutzer." Das ist besser als nichts. Es ist aber keine verlässliche Fehlerbehandlung.
Prompt-Anweisungen werden vom Modell interpretiert. Sie können in einer langen Konversation an Gewicht verlieren, mit anderen Anweisungen konkurrieren oder in einer unerwarteten Situation anders ausgelegt werden als gedacht. Für unkritische Abläufe mag das akzeptabel sein. Für schreibende Aktionen in Kernsystemen ist es das nicht.
Belastbarer ist eine Trennung der Verantwortung:
| Ebene | Verantwortung | Umsetzung |
|---|---|---|
| Tool- und Integrationsschicht | Timeouts, Retries, Idempotenz, Circuit Breaker, Berechtigungen | Deterministischer Code, API-Gateway, Integrationsplattform |
| Orchestrierung | Retry-Budget, erlaubte Fallbacks, Abbruchkriterien, Kompensation | Konfigurierte Regeln pro Aktionstyp |
| Agent | Fachliche Entscheidung innerhalb der erlaubten Optionen | Modell mit klar begrenztem Handlungsraum |
Der Agent entscheidet, ob es fachlich sinnvoll ist, einen zweiten Datenpfad zu nutzen. Ob dieser Pfad überhaupt zur Verfügung steht, wie oft ein Aufruf wiederholt wird und ob ein Schreibvorgang idempotent abgesichert ist, entscheidet nicht das Modell. Das entscheidet die Infrastruktur. So bleibt die Flexibilität des Agenten erhalten, ohne dass die Verlässlichkeit davon abhängt, wie ein Modell eine Anweisung an einem bestimmten Tag interpretiert.
Für Unternehmen, die bereits eine Integrationsplattform betreiben, ist das eine gute Nachricht. Vieles von dem, was Agenten an Fehlerbehandlung brauchen, existiert dort bereits: Retry-Policies, Circuit Breaker, Dead-Letter-Queues, Idempotency-Handling. Die Aufgabe besteht darin, diese Mechanismen auch für Agenten verbindlich zu machen, statt jedem Agenten den direkten Zugriff auf die Zielsysteme zu geben. Welche Anforderungen sich daraus an APIs im Enterprise ergeben, ist ein eigenes Thema.
Fehler sichtbar machen
Fehlerbehandlung ohne Beobachtbarkeit ist blind. Wenn niemand weiß, wie oft ein Agent Aufrufe wiederholt, wie häufig er auf Fallbacks ausweicht und wie oft er eskaliert, lässt sich weder beurteilen, ob die Regeln passen, noch, ob sich das Verhalten über die Zeit verändert.
Mindestens drei Dinge sollten für jeden produktiven Agenten erfasst werden:
- Jeder Tool-Aufruf mit Ergebnis, inklusive Fehlercode, Dauer und Anzahl der Versuche. Das ist die Grundlage für jede Analyse.
- Kennzahlen pro Tool und Aktionstyp: Fehlerquote, Retry-Rate, Fallback-Rate, Eskalationsrate. Ein plötzlicher Anstieg ist oft das erste Signal für ein Problem im Zielsystem.
- Vollständige Nachvollziehbarkeit pro Vorgang: Welche Schritte hat der Agent in welcher Reihenfolge ausgeführt, und warum? Ohne diese Spur lässt sich ein Fehlverhalten im Nachhinein nicht erklären.
Diese Daten sind nicht nur für den Betrieb wichtig. Sie sind auch die Grundlage, um Retry-Budgets, erlaubte Fallbacks und Eskalationsregeln über die Zeit anzupassen. Fehlerbehandlung ist kein einmaliges Design, sondern ein Regelwerk, das mit dem Einsatz reift. Was das für den Schritt vom Pilotprojekt in den Betrieb bedeutet, haben wir in einem eigenen Beitrag beschrieben.
Was vor dem produktiven Einsatz geklärt sein sollte
Bevor ein Agent schreibend auf Unternehmenssysteme zugreift, sollten diese Fragen beantwortet sein:
| Bereich | Leitfrage |
|---|---|
| Idempotenz | Kann jede schreibende Aktion gefahrlos wiederholt werden, oder gibt es eine Statusabfrage vor der Wiederholung? |
| Retry-Regeln | Welche Fehler rechtfertigen einen Retry, wie oft, und wo liegt die Obergrenze? |
| Fallbacks | Welche Alternativpfade sind erlaubt, und welche Fehler dürfen ausdrücklich nicht umgangen werden? |
| Abbruch | Welche Kompensationsschritte greifen, wenn ein mehrstufiger Vorgang mittendrin scheitert? |
| Eskalation | Wer wird wann informiert, und welchen Kontext erhält diese Person? |
| Verantwortung | Welche Regeln liegen in der Infrastruktur, und welche Entscheidungen bleiben beim Agenten? |
| Beobachtbarkeit | Werden Retries, Fallbacks und Eskalationen gemessen, und wer schaut auf diese Zahlen? |
Diese Fragen müssen nicht für jeden denkbaren Agenten auf einmal beantwortet werden. Sinnvoller ist ein Start mit den Aktionen, die ein konkreter Agent tatsächlich auslösen darf. Für diese Teilmenge sollten die Antworten vor dem Rollout vorliegen.
Fazit
Die Diskussion über AI-Agenten dreht sich oft um Fähigkeiten: Was kann der Agent, welche Tools nutzt er, wie autonom arbeitet er? Die Frage, was er tut, wenn etwas schiefgeht, kommt meist erst später. Dabei entscheidet genau sie darüber, ob ein Agent im produktiven Betrieb Vertrauen aufbaut oder verspielt.
Ein Agent, der bei jedem Fehler unkontrolliert wiederholt, Regeln umgeht oder halbfertige Zustände hinterlässt, ist im Unternehmen nicht tragbar, egal wie gut sein Modell ist. Ein Agent, dessen Fehlerverhalten definiert, in der Architektur verankert und messbar ist, kann dagegen auch dann verlässlich arbeiten, wenn die Systeme um ihn herum es nicht sind.
Je autonomer ein Agent arbeitet, desto weniger geht es um die Frage, ob Fehler passieren. Sie passieren. Es geht darum, ob die Architektur dafür sorgt, dass aus einem Fehler kein Schaden wird.