Fallback-Recovery-Agent: Wiederherstellung nach Ausfallen

Kern des Patterns

Fallback-Recovery Agent ist ein Pattern, bei dem ein Agent bei einem Fehler nicht einfach stoppt, sondern einen kontrollierten Wiederherstellungsprozess durchläuft: Fehler klassifizieren, Fallback anwenden und die Ausführung fortsetzen.

Wann nutzen: wenn es wichtig ist, nicht beim ersten Fehler zu scheitern, sondern die Ausführung kontrolliert wiederherzustellen.

In realen Systemen sind Ausfalle unvermeidbar:

• Timeouts externer APIs
• vorubergehende Tool-Nichtverfugbarkeit
• Validierungsfehler in der Antwort
• partielle Outages von Abhangigkeiten

Der Fallback-Recovery-Ansatz verwandelt "Fehler = stop" in "Fehler = kontrolliertes Recovery-Szenario".

Problem

Stell dir vor, ein Agent erstellt einen taglichen Bericht fur einen Kunden:

1. Metriken aus einer API lesen
2. Tabelle zusammenstellen
3. Ergebnis senden

Im zweiten Schritt liefert die API timeout.

Ohne Recovery-Logik stoppt der workflow einfach.

Ein lokaler Fehler sollte nicht den gesamten Prozess zerstoren, wenn die restlichen Schritte noch funktionsfahig sind.

Das Ergebnis:

• Deadline verpasst
• Zwischenfortschritt verloren
• manueller Neustart von null
• unvorhersehbares Verhalten in Prod

Das ist das Kernproblem: Ohne Recovery-Strategie bricht schon ein einzelner Fehler das gesamte Szenario.

Losung

Fallback-Recovery fuhrt eine recovery-policy fur kontrollierte Wiederherstellung nach Fehlern ein.

Analogie: Das ist wie Autosave im Editor. Wenn das Programm absturzt, startest du nicht von vorn, sondern machst beim letzten sicheren Zustand weiter. Die gleiche Logik gilt hier, aber mit klaren Grenzen.

Grundprinzip: Nicht jeder Fehler sollte hart mit stop enden. Ein Teil der Fehler muss klassifiziert und sicher wiederhergestellt werden.

Der Agent kann retry vorschlagen, aber die Ausfuhrungsschicht entscheidet:

• ob retry erlaubt ist
• ob fallback erforderlich ist
• ob escalation/stop notig ist

Kontrollierter Ablauf:

1. Erkennen: Fehler erfassen
2. Klassifizieren: Fehlertyp bestimmen
3. Entscheiden: retry/fallback/escalation
4. Wiederherstellen: ab Checkpoint fortsetzen
5. Sicher beenden: mit transparentem stop_reason stoppen

Das bringt:

• Wiederherstellung langer Prozesse nach temporaren Ausfallen
• sanfte Degradierung (cached/partial result)
• keine Duplikation bereits erfolgreicher Schritte
• transparenten Grund fur den Stopp

Funktioniert gut, wenn:

• Limits fur max_retries und max_fallbacks gesetzt sind
• Checkpoint nach sicherem Fortschritt gespeichert wird
• Klassifikation retriable/non-retriable trennt
• High-Risk-Falle nicht automatisch wiederhergestellt werden

Das Modell kann unendlich retry wollen, aber die recovery-policy definiert die sicheren Grenzen.

Wie es funktioniert

Kritisch: Recovery muss Grenzen haben.

• max_retries und max_fallbacks
• step_timeout und total_timeout
• stop_reason fur jeden Exit
• Verbot von “fallback -> retry -> fallback” ohne Zahler

Im Code sieht das so aus

fallbacks_used = 0

for attempt in range(max_retries + 1):
    try:
        result = run_step(goal, context, timeout_sec=step_timeout)
        checkpoint.save(task_id, context, result)
        return result

    except TimeoutError as err:
        kind = "retriable"

    except ToolUnavailableError as err:
        kind = "tool_unavailable"

    except ValidationError as err:
        kind = "invalid_output"

    except Exception as err:
        kind = classify_error(err)

    if kind == "retriable" and attempt < max_retries:
        sleep(backoff(attempt))
        continue

    if kind == "tool_unavailable" and fallbacks_used < max_fallbacks:
      fallbacks_used += 1
      context.append(f"fallback_used={fallbacks_used}")
      context.append("route=secondary_tool")  # oder alt_model / cached_path
      continue

    if kind == "high_risk":
        return escalate_to_human(goal, err, stop_reason="high_risk")

    return stop_with_reason(goal, stop_reason=kind, detail=str(err))

Checkpoints nach einem erfolgreichen Schritt oder nach sicherem Teilfortschritt (idempotent state) speichern. Sonst kann Retry Aktionen duplizieren.

So sieht es wahrend der Ausfuhrung aus

Goal: Kundenbericht erstellen

Step 1: Metriken sammeln
- timeout in der primaren Analytics-API
- classify: retriable
- retry #1 -> fail
- retry #2 -> fail

Fallback:
- Wechsel auf Read-Replica-API
- Erfolg

Resume:
- Bericht erstellt
- Schritt beendet ohne totalen Prozessabbruch

Wann es passt - und wann nicht

Passt

Passt nicht

Denn ein Recovery-Pattern erhoht die operative Komplexitat: Fehlerlogik, Zustand und Wartungs-Overhead.

Unterschied zu Supervisor

Supervisor ist Pravention. Fallback-Recovery ist Wiederherstellung nach Fehlern.

Wann Fallback-Recovery nutzen (vs andere Patterns)

Nutze Fallback-Recovery, wenn du Ausfuhrung nach Fehlern wiederherstellen musst statt den ganzen Prozess zu stoppen.

Kurzer Test:

• wenn du "retry/fallback/escalation nach einem Fehler" brauchst -> Fallback-Recovery
• wenn du "riskante Aktion schon vor Ausfuhrung stoppen" musst -> Guarded-Policy Agent

Mit anderen Patterns kombinieren

• Fallback-Recovery + ReAct: Wenn der Fehler mitten im Loop passiert, wiederholt der Agent nur den fehlerhaften Schritt statt bei null zu starten.
• Fallback-Recovery + Orchestrator: Bei paralleler Ausfuhrung wird nur der defekte Branch wiederhergestellt, andere Subtasks laufen weiter.
• Fallback-Recovery + Supervisor: Vor Recovery werden Policies gepruft, damit der Fallback keine Sicherheitsregeln verletzt.

Kurzfassung

Vorteile und Nachteile

FAQ

Q: Reicht es, einfach Retries hinzuzufugen?
A: Nein. Das minimale sichere Set ist max_retries + backoff + step_timeout + stop_reason. Ohne das werden Retries zu einem Loop, der Budget verbrennt.

Q: Wann ist Fallback besser als Retry?
A: Wenn der Fehler systemisch ist: Tool nicht verfugbar, quota erschopft oder Endpoint degradiert.

Q: Warum checkpoint, wenn es schon fallback gibt?
A: Fallback andert den Ausfuhrungspfad, aber der Checkpoint bewahrt den Fortschritt, damit nicht das ganze Szenario von vorne lauft.

Was kommt als Nachstes

Fallback-Recovery bringt Ausfallstabilitat.

Aber wie stellt man sicher, dass riskante Aktionen ohne Policy-Prufung gar nicht gestartet werden?