Anti-Pattern Multi-Agent Overkill: zu viele Agenten

Idee in 30 Sekunden

Multi-Agent Overkill ist ein Anti-Pattern, bei dem für eine Aufgabe zu viele Agenten ohne klare Rollengrenzen gestartet werden.

Dadurch wächst Koordinationsrauschen: unnötige handoffs, doppelte Aktionen und widersprüchliche Entscheidungen zwischen Agenten. Das erhöht latency, cost und das Risiko von Regressionen in einfachen Szenarien.

Einfache Regel: Fügt einen neuen Agenten nur hinzu, wenn es eine klare Rolle, messbaren Nutzen und eine eindeutige Ownership-Grenze gibt.

Beispiel für das Anti-Pattern

Das Team baut ein Support-System für Anfragen zu Zahlung, Rückgabe und Bestellstatus.

Statt eines Routers und 1-2 spezialisierter Agenten ergänzt das Team eine Kaskade vieler Rollen.

response = orchestrator_agent.run(
    "User: Wo ist meine Bestellung #18273?"
)

In diesem Setup läuft eine einfache Anfrage durch viele handoffs:

plan = planner_agent.run(user_message)
route = router_agent.run(plan)
facts = retrieval_agent.run(route)
draft = responder_agent.run(facts)
checked = policy_agent.run(draft)
final = critic_agent.run(checked)

In so einer Kette beginnen mehrere Agenten oft ähnliche Funktionen auszuführen: etwa planner und router duplizieren Klassifikation, während policy und critic dieselben Regeln prüfen.

Für diesen Fall reicht eine einfachere Architektur:

order = get_order(order_id)
return format_order_status(order)

In diesem Fall fügt Agenten-Overload hinzu:

• unnötige handoffs zwischen Rollen
• doppelte Prüfungen und Entscheidungen
• schwierige Wartung nach Änderungen

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn ein Team zu früh auf Skalierung designt und Agenten "auf Vorrat" ergänzt.

Typische Ursachen:

• Wunsch, Architektur früh "enterprise-ready" zu machen
• Kopieren von multi-agent Demo-Schemata ohne Anpassung auf eigene Aufgaben
• fehlende klare Grenzen zwischen Agentenrollen
• Versuch, jeden Edge Case mit einem separaten Agenten abzudecken

Daraus folgen Probleme:

• höhere latency - jeder handoff ist ein zusätzlicher Schritt
• höhere cost - mehr LLM/tool-Calls pro Anfrage
• Entscheidungskonflikte - Agenten liefern unterschiedliche Interpretationen desselben Kontexts
• fragile Änderungen - Änderung einer Rolle bricht Nachbarszenarien
• schwieriges Debugging - schwer zu finden, welcher Agent die kritische Entscheidung getroffen hat

Im Unterschied zu allgemein überengineerter Architektur entsteht der Hauptfehler hier genau an den Grenzen zwischen Agenten: bei handoff, Rollenduplikation und verlorenem Ownership der Entscheidung.

Typische Production-Signale, dass bereits zu viele Agenten im Spiel sind:

• eine typische User-Anfrage verursacht 4+ agent handoffs, obwohl 1-2 reichen würden
• derselbe Case läuft in verschiedenen Runs durch unterschiedliche Ketten
• ein neuer Agent verschlechtert success rate oder P95 bestehender Routen
• das Team kann nicht klar erklären, wer Owner der finalen Antwort ist

Wichtig: Jeder handoff bedeutet meist einen neuen Prompt und eine neue LLM inference. Wenn es davon zu viele gibt, wächst die Zahl möglicher Interpretationen, und das Systemverhalten wird instabiler.

Wenn dieses Setup wächst, ist ohne trace und Ausführungsvisualisierung schwer nachvollziehbar, welcher Agent die finale Entscheidung getroffen hat und wo die Kette gebrochen ist.

Richtiger Ansatz

Startet mit einem minimalen Multi-Rollen-Setup: eine Routing-Schicht und nur Agenten mit einzigartigem Nutzen. Neue Rollen nur nach Metriken oder Incidents ergänzen.

Praktischer Rahmen:

• behaltet workflow für deterministische Aufgaben
• ergänzt handoff zwischen Agenten nur bei echter Spezialisierung
• definiert Stage-Owner explizit (wer finale Entscheidung trifft)
• messt Effekt einer neuen Rolle (zum Beispiel bessere success rate ohne starken Anstieg von latency und cost per request)

Wenn ein multi-agent Setup wirklich nötig ist, startet minimal: ein coordinator und ein specialist, nicht die volle Rollen-Kaskade.

def run_support_flow(user_message: str):
    route = classify_intent(user_message)  # simple classifier or rules

    if route == "order_status":
        return run_order_status_workflow(user_message)

    response = specialist_agent.run(user_message)

    if not validate_output(response):  # format, required fields, no empty answer
        return stop("invalid_output")

    return response

In diesem Setup gehen einfache Szenarien nicht durch unnötige multi-agent Kaskaden, und komplexe Cases werden mit der minimal nötigen Rollenanzahl bearbeitet.

Schnelltest

Wenn diese Fragen mit "ja" beantwortet werden, habt ihr ein multi-agent-overkill Risiko:

• Läuft eine typische Anfrage regelmäßig durch 4+ agent handoffs?
• Läuft derselbe Case in verschiedenen Runs durch unterschiedliche Agenten-Ketten?
• Steigen nach einer neuen Rolle häufiger latency und cost als Qualität?

Worin es sich von anderen Anti-Patterns unterscheidet

Overengineering Agents vs Multi-Agent Overkill

Agent Everywhere Problem vs Multi-Agent Overkill

Too Many Tools vs Multi-Agent Overkill

Selbstcheck: Habt ihr dieses Anti-Pattern?

Schnellcheck für Anti-Pattern Multi-Agent Overkill.
Markiert die Punkte für euer System und prüft den Status unten.

Prüft euer System:

FAQ

Q: Bedeutet das, dass ein multi-agent Ansatz immer schlecht ist?
A: Nein. Er ist nützlich, wenn Rollen wirklich verschieden sind, handoff eine klare Aufgabe hat und der Owner der finalen Antwort explizit definiert ist. Das Problem entsteht, wenn es mehr Agenten als realen Bedarf gibt.

Q: Wann sollten wir einen neuen Agenten hinzufügen?
A: Wenn es ein konkretes Signal gibt: Qualitätsgewinn, neue Aufgabenklasse oder Incidents, die das aktuelle Setup nicht ohne unverhältnismäßigen Anstieg von latency, cost oder Debugging-Komplexität abdeckt.

Q: Wie vereinfacht man ein bereits überladenes multi-agent System?
A: Startet mit Rollen-Mapping: Duplikate zusammenführen, deterministische Fälle zurück in workflow bringen und Agenten-handoffs nur dort behalten, wo es echte Spezialisierung gibt.

Was als Nächstes

Ähnliche Anti-Patterns:

• Overengineering Agents - wenn das System zusätzliche Schichten ohne messbaren Nutzen aufbaut.
• Agent Everywhere Problem - wenn Agenten sogar für einfache Aufgaben ergänzt werden.
• Too Many Tools - wenn Tool-Übermaß die Aktionswahl instabil macht.

Was ihr stattdessen bauen solltet:

• Routing Agent - wie einfache Cases in workflow gehen und komplexe an die passende Rolle geroutet werden.
• Orchestrator Agent - wie eine Koordinationsschicht ohne unnötige handoffs gebaut wird.
• Hybrid Workflow + Agent - wie deterministische Branches und Agent-Entscheidungen ohne Systemüberladung kombiniert werden.