Warum KI-Agenten scheitern: typische Probleme in Production

Das Problem

03:07 Uhr nachts.

Der On-Call-Ingenieur sieht: Der Agent bekam eine normale Anfrage, hat mehrfach ein tool aufgerufen, Ergebnisse bekommen, aber die Aufgabe trotzdem nicht abgeschlossen.

In den Logs wiederholt sich:

plan → call_tool → analyze → plan → call_tool → analyze

Viele Schritte, viele Tokens, kein Ergebnis.

Der Agent versucht, eine E-Mail im CRM zu finden. Die Suche liefert 404, aber statt "nicht gefunden" zu antworten, verändert der Agent die Anfrage:

• john@example.com
• John@example.com
• JOHN@example.com
• john@company.com

In 2 Minuten hat der Agent 47 API-Calls ausgeführt, etwa 5 $ an Tokens verbraucht und ist trotzdem keiner Antwort näher gekommen.

Ein Runaway Loop kann in 30-40 Minuten ein Budget verbrennen, das für eine ganze Woche geplant war.

Analogie: Stell dir einen Kassierer vor, der denselben Artikel endlos scannt und dabei das Kartenlimit des Kunden ignoriert. Er wirkt "beschäftigt", aber jede neue Aktion erhöht nur den Schaden. Bei KI-Agenten übernimmt runtime diese Kontrollrolle: stop conditions, Budgets und policy gates.

Warum das passiert

In Production:

1. Das LLM schlägt den nächsten Schritt vor;
2. ein Tool-Call wird ausgeführt;
3. das Ergebnis geht zurück in den Reasoning Loop;
4. runtime prüft keinen echten Fortschritt und stoppt den Loop nicht rechtzeitig.

Das Problem ist nicht das Modell. Das Problem ist, dass runtime nicht weiß, wann gestoppt werden muss.

Welche Ausfälle am häufigsten auftreten

Um die Analyse nicht unnötig zu verkomplizieren, startet man in Production meist mit drei Haupttypen von Ausfällen.

Loop-Fehler (Loop failures)

Der Agent wiederholt dieselben Schritte ohne neue Beobachtungen. Von außen sieht es so aus, als würde er noch arbeiten, aber tatsächlich dreht sich das System im Kreis und verbrennt Zeit und Geld.

Typische Ursache: fehlendes max_steps, kein progress check oder kein klarer stop reason.

In Production sieht das meistens wie ein Infinite Loop aus.

Tool-Fehler (Tool failures)

Der Agent ruft Tools zu oft oder falsch auf. Latenz und API-Last steigen, und Fehler breiten sich über Service-Ketten aus.

Typische Ursache: eine zu offene Tool Execution Layer und schwache Argument-Validierung.

Das endet oft in einem Tool-Fehler.

Budget-Fehler (Budget failures)

Token- und Zeitbudget steigen ohne sichtbaren Fortschritt. Das System wird teurer, und abhängige Services laufen häufiger in Timeouts.

Typische Ursache: keine execution budgets für Schritte, Tokens, Zeit und Anzahl von tool-Aufrufen.

Ohne Limits eskaliert das oft zur Budget Explosion.

Context Drift

Wenn ein Agent zu lange läuft, wächst die Nachrichtenhistorie. Neue Tokens können den System Prompt verdrängen, und der Agent beginnt, seine Rolle oder die ursprüngliche Aufgabe zu "vergessen". Das ist Context Drift. Üblicherweise behebt man das mit Summarization und Context-Window-Limits; ein ähnliches Symptom-Bild ist Context Poisoning.

Zusätzlich sollte man zwei weitere Klassen im Blick behalten:

• Security failures: Prompt Injection und unautorisierter Zugriff auf Write-Tools.
• Data failures: falsche oder nicht validierte Zwischendaten, die die finale Antwort beschädigen.

Wie man diese Probleme erkennt

Damit solche Ausfälle erkannt werden, bevor sie zum Incident werden, überwachen Production-Systeme in der Regel einige zentrale Metriken.

Wie man einen Fehler von einer wirklich schwierigen Aufgabe unterscheidet

Nicht jeder lange Run ist ein Fehler. Das entscheidende Signal ist nicht die Anzahl der Schritte, sondern fehlender realer Fortschritt.

Unkritisch, wenn:

• tool-Schritte die Beobachtungen verändern;
• neue Daten auftauchen;
• das Ergebnis näher an final_answer kommt.

Gefährlich, wenn:

• Wiederholungen ohne neue Beobachtungen;
• derselbe tool_call ohne geänderte Argumente;
• Kosten steigen, Ergebnis verbessert sich nicht.

Wie man solche Ausfälle stoppt

Der einfachste Weg, einen Execution Loop zu kontrollieren, sind Runtime-Limits. Üblich sind max_steps, max_tool_calls, max_tokens und timeout.

max_steps ist die erste Notbremse gegen Runaway Loops. Eine fortgeschrittene Variante ist ein semantic progress check: Ein separates kleines Modell (zum Beispiel Gemini Flash oder Claude Haiku) analysiert die letzten 3 Agent-Schritte und prüft, ob ein neues Signal auftaucht oder das System nur im Kreis läuft. Das Ergebnis kann so aussehen:

{
  "is_progressing": true,
  "is_looping": false
}

Ein grundlegendes Runtime-Gerüst, das die meisten Runaway Loops stoppt:

class RunLimits:
    def __init__(self):
        self.max_steps = 8
        self.max_tool_calls = 12
        self.max_tokens = 4000
        self.max_seconds = 30
        self.steps = 0
        self.tool_calls = 0

    def check(self, step_tokens: int, elapsed_ms: int) -> str | None:
        self.steps += 1
        self.max_tokens -= step_tokens

        if self.steps > self.max_steps:
            return "max_steps_reached"
        if self.tool_calls > self.max_tool_calls:
            return "max_tool_calls_reached"
        if self.max_tokens <= 0:
            return "max_tokens_reached"
        if elapsed_ms > self.max_seconds * 1000:
            return "timeout"
        return None

    def register_tool(self):
        self.tool_calls += 1

In Production werden solche Limits oft in Redis gehalten, damit sie über stateless workers hinweg durchgesetzt werden.

Aber Limits allein garantieren kein korrektes Verhalten. Sie stoppen nur den Runaway Loop. Für stabile Agenten braucht es zusätzlich Tool-Output-Validierung, Policy Boundaries und Kontrolle von Write-Aktionen.

Selbstcheck

Schneller Check vor dem Release. Hake die Punkte ab und sieh dir den Status unten an.
Das ist ein kurzer Sanity-Check, kein formales Audit.

FAQ

Q: Warum scheitern KI-Agenten häufiger als normale Workflows?
A: In Workflows sind die Schritte vorab festgelegt. Beim Agent schlägt das LLM den nächsten Schritt dynamisch vor, und ohne Runtime-Grenzen gerät der Loop schnell außer Kontrolle.

Q: Hilft der Wechsel auf ein stärkeres Modell?
A: Teilweise vielleicht, aber es löst das Kernproblem nicht. Ohne Runtime-Kontrolle kann selbst ein starkes Modell loopen, Budget überschreiten oder Tools zuspammen.

Wenn der Agent vom Anfang max_steps = 8 und dedupe für tool+args gehabt hätte, wäre der 03:07-Incident in wenigen Sekunden beendet gewesen.

In Production wird Agent-Stabilität nicht vom Modell definiert, sondern von den Grenzen, die runtime um den Execution Loop zieht.

Verwandte Seiten

Um besser zu verstehen, wie man solche Ausfälle verhindert, sieh dir die Systemschichten an, die Agent-Verhalten kontrollieren:

• Agent Runtime - steuert Agent-Loop, Limits und stop reasons.
• Tool Execution Layer - führt tool_call sicher aus über Validierung, Policy und Timeout.
• Policy Boundaries - definiert, welche Aktionen erlaubt sind und welche standardmäßig blockiert werden.
• Memory Layer - hilft, den Zustand sauber zu halten, damit der Agent keine Schritte ohne Fortschritt wiederholt.

Außerdem hilfreich: direkte Failure-Szenarien:

• Infinite Loop - wie man Wiederholungen ohne Fortschritt erkennt und stoppt.
• Tool Spam - wie man doppelte Tool-Calls begrenzt.
• Budget Explosion - wie man Token-Kosten und API-Budget kontrolliert.