Die meisten Multi-Agent-System-Ausfälle sind Architekturprobleme, die als Modellprobleme getarnt sind. Teams optimieren Prompts für Agents, die ständig Kontext verlieren, Aufgaben wiederholen oder widersprüchliche Ergebnisse liefern. Das eigentliche Problem: Sie haben das falsche Koordinationsmuster für ihre Aufgabe gewählt. Google, O’Reilly und LangChain haben in den letzten zwölf Monaten jeweils eigene Multi-Agent-Architektur-Guides veröffentlicht. Alle drei kommen zum selben Ergebnis: Das Muster, das man wählt, ist wichtiger als das Modell, das man einsetzt.
Forschungsarbeiten zu Multi-Agent-Systemen sind laut O’Reillys Radar-Report von 820 im Jahr 2024 auf über 2.500 im Jahr 2025 gestiegen. Gartner dokumentierte einen Anstieg von 1.445 % bei Multi-Agent-Anfragen von Q1 2024 bis Q2 2025. Das akademische Interesse ist da. Die Produktionsreife noch nicht. Dieser Beitrag destilliert den praktischen Entscheidungsrahmen aus dem Rauschen.
Googles acht Design Patterns, sortiert nach praktischem Nutzen
Google hat einen Guide zu Multi-Agent Design Patterns auf Basis ihres Agent Development Kit (ADK) veröffentlicht. Acht Muster, jeweils mit Beispielcode. Die Liste ist umfassend, aber nicht jedes Muster verdient die gleiche Aufmerksamkeit. So ordnen sie sich im Produktionseinsatz ein.
Die drei Muster, die 80 % der Anwendungsfälle abdecken
Sequential Pipeline ist der Ausgangspunkt für die meisten Teams. Agents sind wie ein Fließband angeordnet: Die Ausgabe von Agent A wird zur Eingabe für Agent B, dessen Ausgabe geht an Agent C. Kein Branching, keine Parallelität. Das funktioniert, wenn Aufgaben strikte Abhängigkeiten haben. Beispiel: Eine Compliance-Review-Pipeline, bei der ein Dokumentenextraktions-Agent strukturierte Daten an einen Regulierungsabgleich-Agent übergibt, der markierte Klauseln an einen Risikobewertungs-Agent weiterreicht. Googles Guide nennt dieses Muster “linear, deterministisch und erfrischend einfach zu debuggen”.
Coordinator/Router fügt eine Entscheidungsschicht hinzu. Ein Agent empfängt alle eingehenden Anfragen und leitet sie an Spezialisten weiter. Ein Kundenservice-System routet Rechnungsfragen an einen Agent, technische Probleme an einen anderen und Kontoverwaltung an einen dritten. Der Koordinator hält den Session-Kontext und fasst Ergebnisse zusammen. Dieses Muster eignet sich, wenn die Aufgabenkategorien vorab bekannt sind, aber nicht, welche Kategorie eine bestimmte Eingabe erfordert.
Parallel Fan-Out sendet dieselbe Eingabe gleichzeitig an mehrere Agents. Ein Recherchesystem fragt akademische Datenbanken, Nachrichtenquellen und interne Wissensdatenbanken parallel ab, dann führt ein Aggregator die Ergebnisse zusammen. Sinnvoll, wenn Teilaufgaben unabhängig sind und die Latenz der Engpass ist.
Die Muster, die man aufschieben sollte
Die übrigen fünf Muster (hierarchische Delegation, konsensbasierte Abstimmung, kompetitive Evaluation, Human-in-the-Loop-Checkpoints und dynamisches Agent-Spawning) lösen reale Probleme, aber sie erhöhen die Koordinationskomplexität erheblich. Hierarchische Delegation mit Sub-Supervisors ist sinnvoll ab 10+ Agents mit unterschiedlichen Berechtigungsstufen. Konsensbasierte Abstimmung, bei der mehrere Agents dasselbe Problem unabhängig lösen und ein Richter das beste Ergebnis wählt, lohnt sich, wenn Genauigkeit wichtiger ist als Kosten. Für die meisten Produktionssysteme 2026 sind das Optimierungen, keine Startpunkte.
Supervisor vs Swarm: LangChains Benchmark-Daten
LangChain hat Benchmark-Ergebnisse veröffentlicht, die zwei der häufigsten Multi-Agent-Muster in LangGraph vergleichen: Supervisor und Swarm. Die Zahlen klären eine Debatte, die bisher hauptsächlich auf Intuition basierte.
Wie sie sich unterscheiden
Beim Supervisor-Muster empfängt ein zentraler Agent jede Anfrage, zerlegt sie in Teilaufgaben, delegiert jede an einen spezialisierten Worker-Agent und fasst die endgültige Antwort zusammen. Worker kommunizieren nie direkt miteinander oder mit dem Nutzer. Alles läuft über den Supervisor.
Beim Swarm-Muster kann jeder Agent die Kontrolle an jeden anderen Agent in der Gruppe übergeben. Es gibt keinen zentralen Koordinator. Wenn ein Agent seinen Teil erledigt hat, übergibt er an den Agent, der seiner Einschätzung nach als nächstes dran ist. Der aktive Agent antwortet direkt dem Nutzer.
Die Performance-Unterschiede
Das Supervisor-Muster verbraucht konsistent mehr Tokens als Swarm. LangChains Analyse führt das auf den “Übersetzungs-Overhead” zurück: Da Sub-Agents im Supervisor-Muster nicht direkt antworten können, muss der Supervisor jede Worker-Ausgabe neu verarbeiten und formatieren. Das Swarm-Muster erzielte durch Wegfall dieser Zwischenschicht eine Reduktion der End-to-End-Antwortzeit um rund 40 % bei gleichzeitig weniger LLM-Aufrufen pro Anfrage.
Das macht Swarm nicht universell besser. Das Supervisor-Muster bietet stärkere Garantien für Ausgabequalität, Fehlerbehandlung und Aufgabenabschlussverifizierung. Wer sicherstellen muss, dass alle Teilaufgaben vor der Rückgabe eines Ergebnisses abgeschlossen sind, oder wer einen einzigen Audit-Punkt für Compliance braucht, zahlt den Overhead des Supervisors als Preis für Kontrolle.
Die Entscheidungsregel
Supervisor einsetzen, wenn der Workflow ein definiertes Ziel hat und Zuverlässigkeit zählt: Berichterstellung, mehrstufige Datenanalyse, regulierte Prozesse. Swarm wählen, wenn der Lösungsweg unbekannt ist und Agents dynamisch herausfinden müssen, wer was übernimmt: offene Recherche, kreatives Brainstorming, explorative Fehlersuche. LangChains Empfehlung ist unmissverständlich: Von den Zielen und Einschränkungen ausgehen, nicht davon, welches Muster eleganter klingt.
Warum Hybridmuster in Produktionssystemen dominieren
Weder reiner Supervisor noch reiner Swarm entspricht der Realität der meisten Produktionssysteme. O’Reillys Architektur-Guide beschreibt das Muster, auf das erfahrene Teams konvergieren: Eine kleine Zahl schneller Spezialisten arbeitet parallel, während ein langsamerer, überlegter Orchestrator periodisch Ergebnisse aggregiert, Annahmen prüft und entscheidet, ob das System weiterlaufen oder stoppen soll.
Wie Hybrid in der Praxis aussieht
Ein Beispiel: Ein Enterprise-Due-Diligence-System. Drei Spezialisten-Agents laufen parallel: Einer zieht Finanzberichte, einer durchsucht Regulierungsdatenbanken, einer scannt Nachrichtenarchive. Jeder arbeitet unabhängig mit eigenen Tools und eigenem Kontext. Ein vierter Agent, der Orchestrator, läuft auf einem längeren Zyklus. Alle 30 Sekunden prüft er, was die Spezialisten gefunden haben, sucht nach Widersprüchen zwischen Quellen, identifiziert Lücken, die zusätzliche Recherche erfordern, und entscheidet, ob die Gesamtanalyse genug Abdeckung für einen Bericht hat.
Das ist weder Supervisor (der Orchestrator verteilt nicht jede Aufgabe) noch Swarm (die Spezialisten übergeben nicht aneinander). Es ist ein Hybrid, der Durchsatz mit Qualitätskontrolle ausbalanciert. Die Spezialisten maximieren Geschwindigkeit durch Parallelarbeit ohne auf Genehmigungen zu warten. Der Orchestrator verhindert, dass sich Fehler unkontrolliert aufschaukeln, weil er periodisch den Gesamtzustand validiert.
Der Prompting-Trugschluss
O’Reillys Guide benennt ein Muster, das er den “Prompting-Trugschluss” nennt: Wenn Agents schlecht performen, greifen die meisten Teams instinktiv zu besseren Prompts. System-Prompt umschreiben. Mehr Few-Shot-Beispiele hinzufügen. Temperatur anpassen. Die Position des Guides ist eindeutig: Man kann sich nicht aus einem systemischen Fehler herausprompten. Wenn drei Agents widersprüchliche Ergebnisse liefern, ist die Lösung meist eine Koordinationsänderung (Validierungsschritt hinzufügen, Informationsfluss ändern, Reconciliation-Agent einführen), keine Prompt-Änderung.
Das deckt sich mit Googles Skalierungsprinzipien: Die meisten “Agent-Fehler” sind Koordinations- und Kontextübergabe-Probleme an Handoff-Punkten, keine Modell-Fähigkeitsprobleme.
Die vier Fragen, die das Muster bestimmen
Aus der Synthese aller drei Guides ergibt sich ein Entscheidungsrahmen. Vier Fragen beantworten, und das Architekturmuster folgt.
1. Sind die Teilaufgaben unabhängig?
Wenn ja: Parallel Fan-Out. Wenn Teilaufgaben strikte Abhängigkeiten haben (Ausgabe von A ist erforderliche Eingabe für B): Sequential Pipeline. Wenn einige unabhängig sind und andere von früheren Ergebnissen abhängen: Hybrid.
2. Sind die Aufgabenkategorien vorab bekannt?
Wenn alle Anfragetypen aufzählbar sind: Coordinator/Router. Wenn Anfragen offen sind und nicht vorhersehbar ist, welche Fähigkeiten benötigt werden: Swarm, weil Agents basierend auf Laufzeitbedingungen dynamisch übergeben können.
3. Wie wichtig ist Auditierbarkeit?
Regulierte Branchen (Finanzwesen, Gesundheitswesen, Recht, alles was unter DSGVO oder den EU AI Act fällt) brauchen typischerweise ein Supervisor-Muster. Jede Entscheidung läuft über einen einzigen Punkt, der protokolliert, geprüft und auditiert werden kann. Swarm-Muster, bei denen die Kontrolle unvorhersehbar zwischen Agents wechselt, sind schwerer zu auditieren, aber schneller iterierbar.
4. Wie viele Agents braucht man wirklich?
Googles Forschung und die Multi-Agent-Falle zeigen Performance-Einbußen von 39-70 %, wenn Teams mehr Agents hinzufügen als die Aufgabe erfordert. Vor der Wahl eines Multi-Agent-Musters prüfen, ob ein einzelner Agent mit gutem Tool-Zugang das Problem nicht allein lösen kann. O’Reillys Guide formuliert es als “Agents-as-Teams”-Denkweise: Die meisten Produktionsausfälle sind Koordinationsprobleme, keine Fähigkeitsprobleme. Mehr Agents auf ein Koordinationsproblem zu werfen macht es schlimmer.
Protokollschicht: A2A und MCP als Architektur-Enabler
Das gewählte Architekturmuster bestimmt, welche Kommunikationsprotokolle funktionieren. Googles Agent-to-Agent (A2A) Protokoll und Anthropics Model Context Protocol (MCP) sind keine konkurrierenden Standards; sie lösen verschiedene Schichten des Stacks.
MCP standardisiert, wie Agents sich mit Tools und Datenquellen verbinden. A2A standardisiert, wie Agents miteinander kommunizieren. Ein Supervisor-Muster braucht A2A (oder etwas Vergleichbares), damit der Supervisor Aufgaben delegieren und Ergebnisse von Workers einsammeln kann. Jedes Muster braucht MCP (oder Äquivalent), damit Agents auf externe Tools und Datenbanken zugreifen können.
Die praktische Konsequenz: Wer 2026 ein Multi-Agent-System baut, muss in der Architektur Inter-Agent-Kommunikation und Agent-Tool-Kommunikation als separate Anliegen behandeln. Beides zu vermischen ist eine häufige Quelle unnötiger Komplexität.
Häufig gestellte Fragen
Was ist das beste Multi-Agent-Architekturmuster?
Es gibt kein einzelnes bestes Muster. Sequential Pipelines funktionieren für Aufgaben mit strikten Abhängigkeiten, Coordinator/Router-Muster für bekannte Aufgabenkategorien, Parallel Fan-Out maximiert den Durchsatz für unabhängige Aufgaben, und Hybridmuster dominieren die meisten Produktionssysteme. Das richtige Muster hängt davon ab, ob Teilaufgaben unabhängig sind, ob Aufgabenkategorien bekannt sind und wie wichtig Auditierbarkeit ist.
Was ist der Unterschied zwischen Supervisor- und Swarm-Multi-Agent-Mustern?
Beim Supervisor-Muster delegiert ein zentraler Agent alle Aufgaben und fasst alle Ergebnisse zusammen. Worker antworten nie direkt. Beim Swarm-Muster kann jeder Agent an jeden anderen übergeben, der aktive Agent antwortet direkt. LangChain-Benchmarks zeigen, dass Swarm rund 40 % weniger Tokens verbraucht und schneller ist, aber Supervisor bietet stärkere Garantien für Zuverlässigkeit und Auditierbarkeit.
Wie viele Agents sollte ein Multi-Agent-System haben?
So wenige wie möglich. Googles Forschung zeigt Performance-Einbußen von 39-70 %, wenn Teams mehr Agents hinzufügen als nötig. Vor dem Multi-Agent-Design prüfen, ob ein einzelner Agent mit gutem Tool-Zugang das Problem lösen kann. Die meisten Produktionsausfälle sind Koordinationsprobleme, nicht Fähigkeitsprobleme.
Was ist der Prompting-Trugschluss bei Multi-Agent-Systemen?
Der Instinkt, Multi-Agent-Fehler durch bessere Prompts zu beheben. O’Reillys Guide argumentiert, dass man sich nicht aus einem systemischen Fehler herausprompten kann. Wenn Agents widersprüchliche Ergebnisse liefern, ist die Lösung meist eine Koordinationsänderung, keine Prompt-Änderung.
Welche Rolle spielen A2A und MCP bei Multi-Agent-Architekturen?
A2A standardisiert die Kommunikation zwischen Agents. MCP standardisiert die Verbindung von Agents zu Tools und Datenquellen. Sie lösen verschiedene Schichten: A2A die Inter-Agent-Kommunikation, MCP die Agent-Tool-Kommunikation. Die meisten Multi-Agent-Architekturen brauchen beides.