Anti-Pattern No Stop Conditions: wenn Agenten nie stoppen

Idee in 30 Sekunden

No Stop Conditions ist ein Anti-Pattern, bei dem ein Agent ohne klare Abschlussbedingungen gestartet wird.

Dadurch kann der Agent in einer Schleife laufen und Budget ohne realen Fortschritt verbrauchen. Das erhöht latency, cost und das Risiko für Seiteneffekte (Zustandsänderungen).

Einfache Regel: Jeder Agent-Run braucht explizite stop conditions für erfolgreichen Abschluss und sicheren Exit.

Beispiel für das Anti-Pattern

Das Team baut einen Support-Agenten, der eine Antwort in internen Daten finden und dem Nutzer zurückgeben soll.

Aber im Agent-Loop gibt es keine klaren stop conditions.

state = init_state(user_message)

while True:
    decision = agent.next_step(state)
    result = run_tool(decision.tool, decision.args)
    state.append(result)
    # kein has_final_answer(...)
    # kein no_progress(...)
    # keine repeated_action(...) Prüfung

In diesem Setup kann der Agent ähnliche Schritte endlos wiederholen:

search_docs -> fetch_page -> summarize -> search_docs -> ...

Für diesen Fall braucht ihr einen kontrollierten Loop mit expliziten Grenzen:

for step in range(MAX_STEPS):
    ...
    if has_final_answer(state):
        return build_answer(state)

In diesem Fall führen fehlende stop conditions zu:

• Risiko für runaway loop (Endlosschleife)
• unnötigen Tool- und LLM-Calls
• unkontrolliertem Verbrauch von Zeit und Budget

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn ein Team sich auf das Modell verlässt und erwartet, dass es "selbst erkennt", wann es stoppen soll.

Typische Ursachen:

• kein explizites max_steps, timeout oder budget limit
• nicht definiert, was als "fertige Antwort" gilt
• keine no_progress- oder Wiederholungsprüfungen
• Stopp-Kontrolle bleibt nur auf Infrastruktur-Ebene

Daraus folgen Probleme:

• endlose oder lange Schleifen - Agent wiederholt ähnliche Schritte ohne Abschluss
• höhere latency - Antwort kommt deutlich später oder gar nicht
• höhere cost - Zahl der LLM/tool-Schritte pro Anfrage wächst
• Seiteneffekte (Zustandsänderungen) - Wiederholte Aktionen können Duplicate-Records erzeugen, Status mehrfach updaten, API-Calls duplizieren oder externe Aktionen erneut auslösen
• instabile Ergebnisse - dieselbe Anfrage endet in verschiedenen Runs unterschiedlich

Typische Production-Signale, dass stop conditions fehlen oder schwach sind:

• ein sichtbarer Anteil der Runs endet mit Infrastruktur-timeout statt kontrolliertem Stopp
• P95 bei Schrittzahl steigt kontinuierlich
• in Traces sind wiederholte identische Calls mit minimalen Argument-Änderungen zu sehen
• cost per request steigt schneller als success rate

Wichtig: Jeder nächste Schritt ist Teil der LLM inference. Wenn im Loop klare Abschlussbedingungen fehlen, wählt das Modell weiter "noch einen Schritt", selbst wenn kaum neue nützliche Information entsteht.

Wenn dieses Setup wächst, wird ohne trace und Ausführungsvisualisierung schwer erklärbar, warum ein Run nicht rechtzeitig gestoppt wurde. Deshalb haben Production-Systeme meist eine dedizierte Observability-Schicht für Agent-Runs.

Richtiger Ansatz

Startet mit dem einfachsten kontrollierten Loop, der heute die meisten Anfragen stabil löst. Neue stop conditions ergänzt ihr nur, wenn es einen messbaren Ausfall, ein Risiko oder eine Grenze im aktuellen Design gibt.

Praktischer Rahmen:

• definiert eine positive Abschlussbedingung (final_answer_ready)
• setzt Schutzgrenzen (max_steps, timeout, budget)
• ergänzt no_progress- und Wiederholungsprüfungen
• erfasst stop reason pro Run und beobachtet Metriken (zum Beispiel bessere success rate ohne starken Anstieg von latency und cost per request)

In der Praxis bedeutet no_progress oft wiederholte gleiche Tool-Calls, minimale Zustandsänderungen oder fehlende neue nützliche Information nach einem weiteren Schritt.

MAX_STEPS = 8

def run_agent(user_message: str):
    state = init_state(user_message)

    for step in range(MAX_STEPS):  # hard limit for runaway loops
        if timed_out():
            return stop("timeout")
        if budget_exceeded():
            return stop("budget_exceeded")

        decision = agent.next_step(state)

        if decision.type == "final_answer":
            if validate_output(decision.output):  # format, required fields, no empty answer
                return decision.output
            return stop("invalid_output")

        result = run_tool(decision.tool, decision.args)
        if no_progress(state, result):  # same tool/result pattern or no meaningful state change
            return stop("no_progress")

        state.append(result)

    return stop("max_steps_exceeded")

In diesem Setup wird der Loop kontrolliert: Das System liefert entweder eine valide Antwort oder stoppt mit transparentem Grund.

Schnelltest

Wenn diese Fragen mit "ja" beantwortet werden, habt ihr ein no-stop-conditions Risiko:

• Endet ein Teil der Runs mit timeout statt kontrolliertem stop_reason?
• Macht eine Anfrage manchmal unverhältnismäßig viele Schritte ohne sichtbaren Fortschritt?
• Zeigen Traces wiederholte ähnliche Aktionen ohne neue Ergebnisse?

Worin es sich von anderen Anti-Patterns unterscheidet

No Monitoring vs No Stop Conditions

Agents Without Guardrails vs No Stop Conditions

Selbstcheck: Habt ihr dieses Anti-Pattern?

Schnellcheck für das Anti-Pattern No Stop Conditions.
Markiert die Punkte für euer System und prüft den Status unten.

Prüft euer System:

FAQ

Q: Wenn max_steps da ist, reicht das schon?
A: Nein. max_steps ist nötig, deckt aber allein nicht alle Risiken ab. Ihr braucht auch timeout, budget limit, Fortschrittsprüfung und ein valides Kriterium für eine fertige Antwort.

Q: Wann sollten wir eine neue stop condition ergänzen?
A: Wenn es ein konkretes Signal gibt: Incidents, wiederholte Loops oder Wachstum von cost oder latency, das die aktuellen Regeln nicht ohne unverhältnismäßige Systemkomplexität abdecken.

Q: Wie starten, wenn aktuell fast keine stop conditions existieren?
A: Startet mit dem Minimum: max_steps, timeout, budget, stop_reason in Logs. Dann ergänzt no_progress und Final-Answer-Validierung.

Was als Nächstes

Ähnliche Anti-Patterns:

• No Monitoring - wenn ihr nicht seht, dass der Agent in eine Schleife gerät oder degradiert.
• Too Many Tools - wenn Tool-Übermaß die Anzahl unnötiger Schritte erhöht.
• Overengineering Agents - wenn zusätzliche Komplexität die Abschlusskontrolle erschwert.

Was ihr stattdessen bauen solltet:

• Stop Conditions - Basismodell, wie sichere stop conditions definiert werden.
• Step Limits - wie ihr Schrittlimits auf Governance-Ebene setzt.
• Budget Controls - wie ihr Kosten pro Run begrenzt.
• Kill Switch - Not-Aus, wenn das System außer Kontrolle gerät.