Fehlerbehandlung in Multi-Agent-Systemen: Retries, Fallbacks, Circuit-Breaker

Fehlerbehandlung in Multi-Agent-Systemen umfasst alle Mechanismen, die verhindern, dass der Fehler eines einzelnen Agenten das Gesamtsystem kippt: Timeouts, Retries mit Backoff, Fallback-Agents, Circuit-Breaker und durchgängige Observability. Ziel ist Fehlertoleranz – ein Sub-Agent darf scheitern, ohne dass Fehler kaskadieren oder sich fortpflanzen. In einem Single-Agent-System ist Fehlerbehandlung weitgehend ein gelöstes Problem; sobald mehrere Agenten mit eigenen Kontextfenstern, Tools und Rollen zusammenarbeiten, entstehen Fehlerklassen, die es in einem einzelnen Tool-Use-Loop schlicht nicht gibt.

• Trennen Sie Lese- und Schreibpfad: Viele Agenten dürfen parallel lesen und vorschlagen, aber nur einer (oder eine Pipeline-Stufe) committet – das ist das wirksamste Mittel gegen Fehlerfortpflanzung.
• Begrenzen Sie jede Task: Timeout, Token-Cap und ein expliziter failed-Zustand pro Sub-Agent verhindern Deadlocks und Kosten-Explosionen.
• Verifizieren Sie vor Synthese: Ein Verifier-Judge-Agent fängt halluzinierte Fakten ab, bevor der Lead-Agent sie als Wahrheit in die Antwort schreibt.

Warum Fehlerbehandlung in Multi-Agent-Systemen anders ist

Ein Multi-Agent-System besteht aus mehreren LLM-basierten Agenten – jeder mit eigenem Prompt, eigener Rolle, eigenem Toolset und im strengen Fall eigenem Kontextfenster –, die gemeinsam eine Aufgabe lösen. Genau diese Verteilung erzeugt neue Fehleroberflächen. Es gibt keinen einzelnen Trace mehr, sondern N Sub-Agent-Trajektorien plus eine Synthese. Läufe sind nicht-deterministisch: derselbe Input spawnt unterschiedliche Sub-Agenten in unterschiedlicher Reihenfolge. Und das System kann emergentes Verhalten zeigen, das kein einzelner Agent so geplant hat.

Die zentrale Gefahr ist die Fehlerfortpflanzung. Halluziniert ein Sub-Agent einen Fakt, synthetisiert der Lead-Agent ihn in die finale Antwort, und nachgelagerte Agenten handeln auf Basis dieser falschen Tatsache. Aus einem lokalen Fehler wird ein systemweiter Fehlentscheid. Fehlerbehandlung in Multi-Agent-Systemen bedeutet daher zweierlei: einzelne Agenten robust gegen transiente Ausfälle machen und verhindern, dass sich Fehler entlang der Agent-Kette ausbreiten.

Die acht Fehlerklassen, die Single-Agent-Systeme nicht haben

Die folgende Aufstellung ist der von Anthropic, Cognition, Sierra, Salesforce und Microsoft in Produktion dokumentierte Fehlerkatalog. Wer Multi-Agent in Produktion bringt, muss ihn kennen.

Drei dieser Klassen – Kaskaden, Deadlock und Kontext-Fragmentierung – sind die eigentlichen Treiber der Fehlerfortpflanzung. Die anderen fünf verstärken sie oder machen sie unsichtbar.

Fehlerfortpflanzung verhindern: Lese- und Schreibpfad trennen

Die wichtigste Architekturentscheidung gegen Fehlerfortpflanzung ist nicht ein Tool, sondern ein Prinzip. Cognition.ai hat es in "Don't Build Multi-Agents" (Juni 2025) und im Update "Multi-Agents: What's Actually Working" (April 2026) auf den Punkt gebracht: Multi-Agent-Fan-out fürs Lesen ist robust, Multi-Agent-Fan-out fürs Schreiben ist fragil. Die Konsequenz ist die Regel der single-threaded Writes:

• Single-threaded Writes: Viele Agenten lesen, recherchieren, schlagen vor – aber nur ein Agent oder eine Pipeline-Stufe committet. Ein fehlerhafter Lese-Agent liefert nur einen Fragment-Beitrag, den der Lead verwerfen oder neu anfordern kann.
• Unabhängige Writes mit Reconciliation: Jeder Sub-Agent liefert ein Fragment, der Lead-Agent versöhnt sie zur finalen Ausgabe (das Anthropic-Research-Agent-Muster).
• Konkurrierende Writes auf geteilten State: Die Todesspirale – vermeiden.

Cognitions Beobachtung dahinter: "Apparent disagreements" zwischen Agenten sind meist Symptome von Kontext-Fragmentierung, nicht echter Uneinigkeit. Wo die Kopplung hoch ist, muss man volle Agent-Traces teilen statt nur einzelner Nachrichten. Für den geteilten externen Speicher (Vektor-Store, Postgres, SAP HANA) gilt in den meisten Produktionssystemen dieselbe Regel: ein Schreiber, viele Leser.

Retries mit Backoff, Timeouts und Circuit-Breaker

Auf der Ebene des einzelnen Agent- oder Tool-Aufrufs greifen die klassischen Resilienz-Muster – übertragen aus der Microservice-Welt:

• Retries mit exponentiellem Backoff: Transiente Fehler (Rate-Limit, kurzer Tool-Ausfall, Timeout) werden mit wachsenden Wartezeiten wiederholt, idealerweise mit Jitter, um Thundering-Herd-Effekte zu vermeiden. Wichtig: Retries helfen nur gegen transiente, nicht gegen semantische Fehler. Ein erneuter Aufruf eines halluzinierenden Agenten liefert dieselbe Halluzination.
• Timeouts auf jeder Task: Das A2A-Protokoll definiert einen Task-Lebenszyklus submitted → working → input-required → completed | failed | canceled. Ein Timeout auf jeder Task plus der explizite input-required-Zustand sind die dokumentierte Gegenmaßnahme gegen Resource-Deadlocks. Ohne Timeout kann ein wartender Agent das gesamte System blockieren.
• Circuit-Breaker: Häufen sich Fehler eines Sub-Agenten oder Tools über einem Schwellwert, öffnet der Breaker und blockiert weitere Aufrufe für ein Zeitfenster. Das stoppt die Kosten-Explosion und gibt Raum für einen Fallback.
• Fallback-Agents und degradierte Antworten: Fällt ein spezialisierter Agent aus, übernimmt ein einfacherer Fallback-Agent, ein anderes Modell-Tier oder eine bewusst reduzierte Antwort. Besser eine ehrlich eingeschränkte Ausgabe als ein kaskadierter Fehlentscheid.

Die praktische Token-Disziplin aus der Anthropic-Research-Agent-Referenz ergänzt das: Sub-Agent-Token-Spend explizit deckeln (von Bedrock AgentCore, LangGraph und Claude Agent SDK unterstützt), Sub-Agent-Ausgaben in ein typisiertes Schema (Pydantic, JSON-Schema, A2A-Artifact) zwingen und vor der Rückgabe komprimieren – niemals ein volles Sub-Agent-Transkript an den Lead durchreichen. Ein typisiertes Schema ist zugleich eine Fehlergrenze: Was nicht ins Schema passt, wird abgewiesen statt weitergereicht.

Monitoring und Observability: Voraussetzung, kein Add-on

Debuggability-Collapse ist die heimtückischste Fehlerklasse: Geht etwas schief, gibt es keinen einzelnen Trace, der den Lauf erklärt. Observability ist deshalb für kein Multi-Agent-System in Produktion optional. Die Bausteine:

• Verteiltes Tracing über den gesamten A2A-Mesh, mit einer durchgängigen Korrelations-/Trace-ID in jedem A2A-Task und jedem MCP-Call. OpenTelemetry ist 2026 der querliegende Standard.
• Werkzeuge (Stand 2026): LangSmith für interne LangGraph-Traces; Galileo oder Arize Phoenix für Multi-Agent-Traces über Vendor-Grenzen; Pydantic Logfire in Python-lastigen Teams; Datadog/Splunk/Grafana für SIEM-Korrelation.
• Verifier-Judge-Pattern: Ein separater Judge-Agent – oft ein stärkeres Modell als die Worker – bewertet jede Trajektorie an einer kleinen Rubrik: Aufgabe erledigt? Antwort grounded? Agenten on-task geblieben? Budget eingehalten? Das ist die leichteste produktionstaugliche Antwort gegen Kaskaden-Fehler.

Für DACH ist Observability zudem eine Compliance-Frage. BaFin, FMA und FINMA werden 2026 zunehmend auf End-to-End-Traces jedes Agent-Calls, auf Reproduzierbarkeit (Modellversionen in Produktion pinnen, alle Sub-Agent-Prompts, Tool-Calls und AgentCards mitschreiben) und auf Append-only-Audit-Storage drücken. Aufbewahrungsfristen richten sich nach Sektor: BFSI 10 Jahre, Pharma-GxP oft 25–30 Jahre.

Beispiel: Allianz Project Nemo

Project Nemo von Allianz – einem deutschen Versicherer – ist eine der saubersten dokumentierten DACH-relevanten Multi-Agent-Deployments und ein Lehrstück für Fehlerbehandlung. Sieben spezialisierte Agenten (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) bearbeiten Lebensmittelverderb-Schäden nach Naturkatastrophen. Der vollständige Sieben-Agenten-Workflow läuft in unter fünf Minuten.

Zwei Fehlerbehandlungs-Prinzipien sind hier baulich verankert:

• Audit-Agent als Topologie-Element: Ein dedizierter Agent erzeugt eine vollständige Zusammenfassung aller Agent-Entscheidungen und Begründungen – ein kompletter Audit-Trail für Compliance, Qualitätskontrolle und menschliche Prüfung. Auditierbarkeit ist in die Agent-Topologie eingebaut, nicht erst in die Logging-Pipeline.
• Human-in-the-Loop an der kritischen Stufe: Ein menschlicher Sachbearbeiter prüft die Audit-Zusammenfassung und trifft die finale Auszahlungsentscheidung. Eine kaskadierte Fehlentscheidung wird am teuersten, irreversiblen Punkt abgefangen – als explizite Policy.

Das Ergebnis: 80 % Reduktion der Bearbeitungs- und Abwicklungszeit für berechtigte Schäden unter AUD 500, live in unter 100 Tagen (Australien, Juli 2025). Die Lehre für die Fehlerbehandlung: Modulare Agenten mit klaren Rollen, ein dedizierter Audit-Pfad und ein menschlicher Kontrollpunkt machen ein System, das schnell und beherrschbar ist.

Praxis-Checkliste Fehlerbehandlung

• Schreibpfad single-threaded? Genau ein Agent/eine Stufe committet; Leser fan-out, Schreiber nicht.
  
• Timeout auf jeder Task? Plus expliziter input-required-Zustand gegen Deadlocks.
  
• Retries mit Backoff + Jitter nur für transiente Fehler, nicht für semantische.
  
• Circuit-Breaker pro Sub-Agent/Tool mit Schwellwert und Reset-Fenster.
  
• Fallback-Agent oder degradierte Antwort für jeden kritischen Agenten definiert.
  
• Sub-Agent-Token-Caps gesetzt; Ausgaben in typisiertes Schema gezwungen und komprimiert.
  
• Verifier-Judge-Agent prüft Trajektorien vor finaler Synthese.
  
• Grounded Retrieval + verpflichtende Quellen gegen Halluzinations-Kaskaden.
  
• Geteilte volle Traces bei hoher Kopplung; Entscheidungs-Verträge explizit.
  
• Korrelations-ID in jedem A2A-Task und MCP-Call; OTel-Export.
  
• Human-in-the-Loop an irreversiblen/teuren Schritten.
  
• Modellversionen gepinnt, Audit-Trail append-only, Aufbewahrung sektorkonform.
  

Für Agenturen und B2B-Entscheider

Für Marketing-Agenturen und AI-native Anbieter ist Fehlerbehandlung ein Produktqualitäts-Merkmal, kein Hintergrund-Detail: Eine Newsletter- oder SEO-Audit-Pipeline mit Research-, Outline-, Draft- und Review-Agent steht und fällt mit dem Verifier-Judge und der single-threaded Schreibstufe. Für DACH-B2B-Entscheider gilt: Verlangen Sie von jedem Multi-Agent-Pitch – intern oder vom Vendor – konkrete Antworten auf Timeout-, Fallback-, Verifier- und Trace-Strategie. Ein System ohne Galileo-/LangSmith-Klasse-Observability ist unter Regulator-Anfrage nicht untersuchbar. Wer Fehlerbehandlung von Anfang an in die Agent-Topologie baut – nach dem Allianz-Nemo-Muster mit Audit-Agent und Human-in-the-Loop –, liefert Systeme, die schnell sind und gleichzeitig prüfbar bleiben.