Multi-Agent-Chaos: Wenn zu viele Agenten konkurrieren

Das Problem

Die Anfrage wirkt normal: einen Kundenfall prüfen und eine kurze Antwort vorbereiten.

In Traces sieht man etwas anderes: Der Orchestrator startete 5 Agenten, drei davon bearbeiteten fast dieselbe Subtask, die Zahl der handoffs zwischen Agenten stieg auf 14 in einem Run, und die finale Antwort wurde bis zum timeout nicht gebildet.

Das System stürzt nicht sofort ab.

Es beginnt zu rauschen: Duplikate, handoffs, queue und latency wachsen.

Analogie: Stell dir eine Restaurant-Schicht vor, in der die Kellner die Tische nicht aufgeteilt haben. Drei Personen nehmen dieselbe Bestellung auf, während andere Tische warten. Es gibt mehr Aktivität, aber ein schlechteres Ergebnis. Multi-Agent-Chaos in AI-Systemen funktioniert genauso: mehr Aktionen, aber weniger nützlicher Fortschritt.

Warum das passiert

Multi-Agent-Chaos entsteht nicht durch die reine Anzahl an Agenten, sondern durch fehlende strikte Koordination zwischen ihnen.

In production ist es typischerweise so:

1. Rollen der Agenten überlappen, und eine Subtask hat mehrere Owner;
2. Delegation läuft ohne klare Grenzen für Tiefe und Anzahl der Übergaben;
3. es gibt keine einheitliche Regel für arbitration, wer final entscheidet;
4. duplizierte tool_call von verschiedenen Agenten vervielfachen Last;
5. ohne stop reasons und budget gates konvergiert der Run zu lange nicht.

Das Problem liegt nicht im Multi-Agent-Ansatz selbst.

Mehrere Agenten handeln ohne gemeinsamen Kontrollkreis.

Welche Ausfälle am häufigsten auftreten

In production sieht man am häufigsten vier Muster von Multi-Agent-Chaos.

Rollenüberlappung (Role overlap)

Zwei oder mehr Agenten übernehmen dieselbe Subtask und liefern unterschiedliche Zwischenresultate.

Typische Ursache: keine role map und kein expliziter Owner der Subtask.

Delegationsschleife (Delegation loop)

Agent A delegiert an B, B delegiert an C, C delegiert zurück an A. Von außen wirkt der Run "aktiv", aber es gibt keinen Fortschritt.

Typische Ursache: kein Limit für Delegationstiefe und Handoff-Budget.

Duplizierte Arbeit zwischen Agenten (Cross-agent duplicate work)

Verschiedene Agenten rufen dasselbe tool mit identischen oder fast identischen Argumenten auf. Das wird schnell zu tool spam.

Typische Ursache: dedupe fehlt auf Run-Ebene, nicht nur pro einzelner Agent.

Unbegrenzter Fan-out (Unbounded fan-out)

Ein Agent erzeugt viele Child-Tasks, und das System verbraucht Ressourcen schneller, als es nützliche Arbeit abschließt.

Typische Ursache: keine Caps für aktive Agenten und parallele Tasks.

Wie man diese Probleme erkennt

Multi-Agent-Chaos ist gut sichtbar über die Kombination aus orchestration- und runtime-Metriken.

Wie man Multi-Agent-Chaos von nützlicher Spezialisierung unterscheidet

Nicht jeder lange Multi-Agent-Run bedeutet Chaos. Die Kernfrage: liefert jeder Agent einen einzigartigen Beitrag zum finalen Ergebnis.

Normal, wenn:

• eine Subtask genau einen Owner und klare Verantwortung hat;
• ein handoff den Task-Zustand ändert und nicht nur weiterreicht;
• Zahl von Agenten und Aufrufen zusammen mit Antwortqualität steigt.

Gefährlich, wenn:

• eine Subtask mehrere Owner hat;
• Agenten Aufgaben ohne neues Signal hin- und herschieben;
• Kosten und latency steigen, während der Run nicht zu final_answer konvergiert.

Wie man solche Ausfälle stoppt

Praktisch bedeutet das:

1. eine role map definieren: wer was tut und wer jede Subtask besitzt;
2. Limits für aktive Agenten, Anzahl Übergaben und Delegationstiefe setzen;
3. vor jeder neuen Delegation einen arbitration step einführen;
4. bei Konflikten oder Budgetüberschreitung auf fallback umschalten (single-agent oder partielle Antwort).

Minimaler Guard für Multi-Agent-Koordination:

from dataclasses import dataclass
import json


def task_signature(task: dict) -> str:
    return json.dumps(task, sort_keys=True, ensure_ascii=False)


@dataclass(frozen=True)
class MultiAgentLimits:
    max_agents_per_run: int = 4
    max_handoffs: int = 8
    max_delegation_depth: int = 3
    max_parallel_subtasks: int = 6
    max_duplicate_signature: int = 2


class MultiAgentChaosGuard:
    def __init__(self, limits: MultiAgentLimits = MultiAgentLimits()):
        self.limits = limits
        self.seen_agents: set[str] = set()
        self.handoffs = 0
        self.in_flight_signatures: set[str] = set()
        self.signature_claims: dict[str, int] = {}
        self.owner_by_signature: dict[str, str] = {}

    def register_agent(self, agent_id: str) -> str | None:
        self.seen_agents.add(agent_id)
        if len(self.seen_agents) > self.limits.max_agents_per_run:
            return "multi_agent_chaos:agent_fanout"
        return None

    def on_handoff(self, _from_agent: str, to_agent: str, depth: int) -> str | None:
        self.handoffs += 1
        if self.handoffs > self.limits.max_handoffs:
            return "multi_agent_chaos:handoff_budget"
        if depth > self.limits.max_delegation_depth:
            return "multi_agent_chaos:delegation_depth"
        return self.register_agent(to_agent)

    def claim_subtask(self, agent_id: str, task: dict) -> str | None:
        sig = task_signature(task)

        owner = self.owner_by_signature.get(sig)
        if owner is not None and owner != agent_id:
            return "multi_agent_chaos:ownership_conflict"
        self.owner_by_signature.setdefault(sig, agent_id)

        self.signature_claims[sig] = self.signature_claims.get(sig, 0) + 1
        if self.signature_claims[sig] > self.limits.max_duplicate_signature:
            return "multi_agent_chaos:duplicate_subtask"

        if sig not in self.in_flight_signatures:
            if len(self.in_flight_signatures) >= self.limits.max_parallel_subtasks:
                return "multi_agent_chaos:parallel_fanout"
            self.in_flight_signatures.add(sig)
        return None

    def finish_subtask(self, task: dict) -> None:
        self.in_flight_signatures.discard(task_signature(task))

Das ist ein Basis-Guard. In dieser Version zählt seen_agents auch Versuche, den fan-out zu erweitern, nicht nur bereits zugelassene Agenten. max_agents_per_run begrenzt hier die Anzahl einzigartiger Agenten innerhalb eines Runs. In production ergänzt man das meist durch shared state store, priority queue für Subtasks und expliziten fallback in single-agent mode. on_handoff(...) wird vor Übergabe an einen anderen Agenten aufgerufen, claim_subtask(...) vor Start der Arbeit, damit Chaos bereits am Eingang gestoppt wird.

Wo das in der Architektur umgesetzt wird

In production ist die Kontrolle von Multi-Agent-Chaos üblicherweise auf drei Systemschichten verteilt.

Orchestration Topologies definiert, wie Agenten interagieren, wer den Zustand besitzt und wo arbitration stattfindet. Ohne diese Schicht ist Chaos zwischen Agenten fast unvermeidlich.

Agent Runtime steuert execution limits, stop reasons (multi_agent_chaos:*) und fallback-Übergänge. Genau hier setzt man handoff/depth budgets und Bedingungen für erzwungenes Stoppen.

Tool Execution Layer begrenzt duplizierte Tool-Aufrufe zwischen Agenten: dedupe, retries, timeout und shared caching innerhalb des Runs.

Checkliste

Bevor du ein Multi-Agent-Szenario in production shipst:

• [ ] role map und Owner für jede Subtask sind explizit definiert;
• [ ] max_agents_per_run, max_handoffs, max_delegation_depth sind gesetzt;
• [ ] Owner-Lock und per-run dedupe signatures sind vorhanden;
• [ ] bounded fan-out für parallele Subtasks ist aktiviert;
• [ ] stop reasons decken multi_agent_chaos:* ab;
• [ ] es gibt fallback: single-agent mode oder partielle Antwort;
• [ ] Alerts auf agent_handoffs_per_run, duplicate_subtask_rate, queue_backlog;
• [ ] Runbook beschreibt, wie Rollenkonflikte im Incident eingegrenzt werden.

FAQ

Q: Bedeutet mehr Agenten immer bessere Qualität?
A: Nein. Ohne Koordination führen mehr Agenten oft zu mehr Duplikaten und Konflikten statt besseren Ergebnissen.

Q: Kann man Chaos nur durch Prompt-Änderung entfernen?
A: Nein. Prompt hilft, aber die Ursache liegt in orchestration-Kontrolle: Rollen, Task-Ownership, budgets und arbitration.

Q: Was tun, wenn Chaos schon in production gestartet ist?
A: Vorübergehend fan-out begrenzen, aktive Agenten reduzieren, single-agent fallback einschalten und stop reasons in Traces prüfen.

Q: Wer sollte in einem Multi-Agent-System final entscheiden?
A: Üblicherweise ein orchestrator oder ein arbitration step. Ohne einen Owner der finalen Entscheidung gerät das System schnell in Konflikte oder Duplikate.

Multi-Agent-Chaos sieht fast nie wie ein einzelner großer Defekt aus. Meist ist es eine Anhäufung kleiner Konflikte zwischen Agenten. Darum brauchen production-Systeme nicht nur "smarte" Agenten, sondern auch strikte orchestration-Disziplin.

Verwandte Seiten

Wenn dieses Problem in production auftritt, helfen auch diese Seiten:

• Warum AI-Agenten scheitern — allgemeine Karte von Ausfällen in production.
• Deadlocks — wie zyklisches Warten zwischen Agenten den workflow blockiert.
• Cascading failures — wie sich lokaler Fehler im System ausbreitet.
• Tool spam — wie duplizierte Tool-Aufrufe Budget verbrauchen.
• Agent Runtime — wo budgets, stop reasons und fallback gesetzt werden.
• Orchestration Topologies — wie kontrollierte Agent-Interaktion entworfen wird.
• Tool Execution Layer — wo retries, dedupe und timeout zentralisiert werden.