Snack 13 – Failure Handling: Retries, Fallback, Human Handoff

In agentischen Systemen ist „Failure Handling“ kein Afterthought, sondern Teil der Architektur. Ein Agent, der Tools ausführt, wird zwangsläufig mit Timeouts, Netzwerkfehlern, Rate Limits, invaliden Inputs, partial failures und widersprüchlichen Tool-Outputs konfrontiert. Im Exam zählt vor allem, dass du Failure Handling systematisch denken kannst: Erkennen → Klassifizieren → Reagieren → Validieren → Dokumentieren.

1) Retries: wann wiederholen sinnvoll ist

Retries sind sinnvoll, wenn der Fehler transient ist (z. B. 502, Netzwerk-Jitter, kurzzeitige Rate-Limits). Sie sind gefährlich bei deterministischen Fehlern (z. B. 400 Bad Request, Schema verletzt, fehlende Berechtigung), weil du nur Kosten und Latenz erhöhst.

Praxisregeln:

• **Exponential Backoff + Jitter** (z. B. 0.5s, 1s, 2s, 4s ± random) verhindert Thundering Herd.
• **Retry Budget** (max. Versuche oder max. Zeit) schützt vor endlosen Schleifen.
• **Idempotenz** ist der Schlüssel: Nur wenn ein Tool-Aufruf idempotent ist (oder du Idempotency Keys nutzt), sind Retries sicher. Sonst riskierst du doppelte Bestellungen, doppelte Tickets, doppelte Zahlungen.

2) Fallback: degradieren statt sterben

Fallback bedeutet: Wenn der bevorzugte Pfad scheitert, nutzt du einen alternativen Pfad mit akzeptablen Trade-offs. Das kann sein:

• **Model fallback** (z. B. kleineres/anderes Modell, weniger Kosten, ggf. weniger Qualität)
• **Tool fallback** (API → cached data → heuristische Berechnung)
• **Workflow fallback** (vollautomatisch → halbautomatisch)

Wichtig ist, Fallbacks zu designen, ohne „Silent Failure“ zu erzeugen. Der Agent sollte explizit markieren:

• Was ist ausgefallen?
• Welcher Fallback wurde gewählt?
• Welche Einschränkungen gelten jetzt (z. B. „Datenstand möglicherweise 24h alt“)?

Ein gutes Pattern ist: Primary → Secondary → Safe Stop. Wenn auch Secondary nicht sicher ist, ist „Stop + Human“ besser als kreatives Weiterwürfeln.

3) Human Handoff: kontrollierte Übergabe

Human Handoff ist kein Eingeständnis von Schwäche, sondern ein Sicherheits- und Qualitätsmechanismus. Du nutzt ihn, wenn:

• **Risiko hoch** ist (z. B. Geld, Datenlöschung, Security-relevant)
• **Unklarheit hoch** ist (fehlende Anforderungen, widersprüchliche Inputs)
• **Tool-Access fehlt** (Permissions) oder Policies greifen

Gute Übergabe heißt: der Agent liefert entscheidungsreife Informationen.

• Kontext: Ziel + aktueller Stand
• Diagnose: Fehlerklasse + reproduzierbare Details (Request IDs, Fehlermeldungen)
• Optionen: 2–3 nächste Schritte mit Risiko/Impact
• Minimaler manueller Input: „Bitte bestätige X“ oder „Bitte liefere Y“

3 Takeaways

1. Retry nur bei transienten Fehlern und nur mit Backoff, Budget und (idealerweise) Idempotency.

2. Fallbacks müssen transparent sein: chosen path + trade-offs klar kommunizieren.

3. Human Handoff ist ein Pattern: kompakter Status, Diagnose, Optionen – statt „geht nicht“.

Mini-Testfrage

Du orchestrierst einen Agenten, der ein externes Ticket-System per Tool-Aufruf aktualisiert. Der Tool-Call timed out, du weißt nicht, ob das Update durchging. Wie gestaltest du Retries und was ist dein sicherster nächster Schritt?

Lösung

Du brauchst Idempotenz (z. B. Idempotency Key oder vorher/nachher Zustand prüfen), sonst sind Retries riskant. Der sicherste Schritt ist: Status verifizieren (Ticket erneut lesen/abgleichen) und erst dann retryen – mit begrenztem Retry-Budget und Backoff. Wenn Verifikation nicht möglich ist, stoppe und mache einen Human Handoff mit klarer Lage („unklar ob Update applied“).