6 Multi-Agent-Orchestrierungsmuster, die in der Produktion tatsächlich funktionieren

Gartner meldete einen Anstieg um 1.445 % bei Anfragen zu Multi-Agenten-Systemen zwischen Q1 2024 und Q2 2025. Unternehmen setzen bereits durchschnittlich 12 Agenten ein, und diese Zahl soll innerhalb von zwei Jahren um 67 % steigen.

Doch 40 % der Multi-Agenten-Piloten scheitern innerhalb von sechs Monaten nach dem Produktivgang. Das Muster ist nicht, dass Multi-Agenten-Systeme nicht funktionieren. Es liegt daran, dass Teams für ihr Problem das falsche Orchestrierungsmodell wählen oder das richtige wählen, ohne zu verstehen, wie es scheitert.

Hier sind sechs Muster, die sich im Produktivbetrieb bewähren, sowie die konkreten Arten, wie jedes davon scheitert, wenn es das nicht tut.

1. Orchestrator-Worker

Ein Agent übernimmt die Aufgabe, zerlegt sie in Teilaufgaben, delegiert jede an einen spezialisierten Worker und setzt die Ergebnisse zusammen. Der Orchestrator nutzt ein leistungsfähiges Modell, während die Worker günstigere, aufgaben­spezifische Modelle verwenden, wodurch die Kosten um 40-60 % sinken.

Wann einsetzen: Cross-funktionale Workflows mit klarer Aufgabenzerlegung. Weiterleitung im Kundenservice zwischen Rechnungs-, Technik- und Produktspezialisten. Jede Aufgabe, bei der Sie einen einzelnen Verantwortungs­punkt benötigen.

Wells Fargo nutzt dieses Muster, um 35.000 Bankern in 30 Sekunden Zugriff auf 1.700 Prozesse zu geben, statt in 10 Minuten. Salesforce Agentforce 2.0 implementiert es über die Atlas Reasoning Engine.

Wie es scheitert

Der Orchestrator ist ein Single Point of Failure. Wenn er eine Aufgabe falsch klassifiziert, landet sie beim falschen Worker, und Fehlklassifizierungen summieren sich im großen Maßstab.

Überlauf des Kontextfensters ist das subtilere Problem. Der Orchestrator sammelt den Kontext jedes Workers. Ab vier oder mehr Workern überschreitet der Kontext häufig die Fenstergrenzen. Workflows, die im Test 0,50 $ kosten, können bei 100.000 Ausführungen 50.000 $/Monat erreichen, weil der Orchestrator zusätzlich zu jedem Worker-Aufruf mehrere LLM-Aufrufe für Zerlegung und Aggregation macht.

2. Sequentielle Pipeline

Agenten arbeiten in einer vordefinierten linearen Kette. Jeder verarbeitet die Ausgabe des vorherigen Agenten über einen gemeinsamen Zustand. Die Reihenfolge ist deterministisch und wird zur Entwurfszeit festgelegt.

Wann einsetzen: Dokumentenverarbeitung (parsen, extrahieren, validieren, zusammenfassen). Vertragserstellung. Content-Moderation. Jeder mehrstufige Prozess mit klaren linearen Abhängigkeiten.

Das Azure Architecture Center von Microsoft dokumentiert ein Beispiel aus einer Kanzlei, die dieses Muster für die Vertragserstellung nutzt: Vorlagenauswahl, Klauselanpassung, Compliance-Prüfung und Risikobewertung, jeweils von einem separaten KI-Agenten übernommen.

Wie es scheitert

Fehlerfortpflanzung. Schlechte Ergebnisse in Phase 1 ziehen sich ohne Rücksprung durch alle nachgelagerten Stufen.

Das weniger offensichtliche Problem ist der Overhead. Eine Pipeline mit vier Agenten verursacht rund 950 ms Koordinations-Overhead, während die eigentliche Verarbeitung 500 ms dauert. Eine Pipeline mit drei Agenten verbraucht 29.000 Tokens gegenüber 10.000 bei einem äquivalenten Single-Agent-Ansatz. Wenn Ihre Pipeline die Spezialisierung nicht braucht, zahlen Sie das Dreifache für dasselbe Ergebnis.

3. Fan-out / Fan-in

Mehrere Agenten arbeiten gleichzeitig am selben Input oder an unabhängigen Teilaufgaben. Ein Dispatcher verteilt die Arbeit, ein Collector aggregiert die Ergebnisse mithilfe von Abstimmung, gewichteter Zusammenführung oder LLM-basierter Synthese.

Wann einsetzen: Analyse aus mehreren Perspektiven (Finanzanalyse mit fundamental-, technisch-, sentiment- und ESG-Agenten, die parallel laufen). Parallele Code-Reviews für Sicherheit, Stil und Performance. Jedes Szenario mit vier oder mehr unabhängigen Aufgaben, bei dem Sie die Durchlaufzeit um 75 % senken müssen.

Wie es scheitert

API-Rate-Limits. Fünfzehn parallele Agenten verbrauchen 150 Requests pro Sekunde, wenn Ihr Limit bei 100 liegt. Jeder Agent bleibt für sich genommen innerhalb der Limits, aber die Gesamtlast überschreitet die Kapazität.

Race Conditions auf gemeinsam genutztem Zustand skalieren quadratisch. Ein System mit N Agenten hat N(N-1)/2 potenzielle gleichzeitige Interaktionen. Bei fünf Agenten sind das 10 potenzielle Konflikte. Bei zehn sind es 45.

Der Aggregationsschritt selbst führt zu Fehlern. LLM-basierte Synthese kann einen Konsens halluzinieren, der in den zugrunde liegenden Ergebnissen gar nicht existiert. Wenn Ihre parallelen Agenten sich uneinig sind (Sentiment sagt Kaufen, Fundamentals sagt Verkaufen), brauchen Sie eine explizite Konfliktlösungsstrategie und nicht nur "die Ergebnisse zusammenfassen".

4. Multi-Agenten-Debatte

Mehrere Agenten beteiligen sich an einem gemeinsamen Gespräch, bringen Perspektiven ein, hinterfragen sich gegenseitig und schärfen Positionen über mehrere Runden hinweg. Enthält Maker-Checker-Schleifen, in denen ein Agent erzeugt und ein anderer validiert, bis die Freigabe erfolgt.

Wann einsetzen: Compliance-Prüfungen, die mehrere Expertenperspektiven erfordern. Qualitätssicherung mit strukturierter Prüfung. Forschung zeigt, dass Debatten Halluzinationen im Vergleich zu Single-Model-Abfragen reduzieren, weil Agenten die Fehler der jeweils anderen erkennen.

Eine praktische Variante: Verwenden Sie ein günstiges, schnelles Modell für den Maker und ein leistungsfähiges Modell für den Checker. So erhalten Sie den Qualitätsgewinn der Debatte bei 40-60 % geringeren Kosten als beim Betrieb beider Rollen auf leistungsfähigen Modellen.

Wie es scheitert

Gesprächsschleifen. Agenten debattieren weiter, ohne zu einem Ergebnis zu kommen. Microsoft empfiehlt aus diesem Grund, den Gruppenchat auf drei oder weniger Agenten zu begrenzen.

Kaskadierende Gefälligkeit ist das schwierigere Problem. Agenten neigen dazu, der Mehrheitsposition zuzustimmen, selbst wenn sie falsch ist, und erzeugen so einen falschen Konsens. Fünf Runden mit drei Agenten bedeuten 15 LLM-Aufrufe pro Aufgabe, und das Ergebnis kann trotzdem mit hoher Sicherheit falsch sein, weil die Agenten die Fehler der anderen verstärkt haben.

5. Dynamische Übergabe

Jeder Agent bewertet die aktuelle Aufgabe und entscheidet, ob er sie selbst bearbeitet oder die Kontrolle an einen geeigneteren Spezialisten übergibt. Anders als beim Orchestrator-Worker gibt es keinen zentralen Koordinator. Agenten delegieren einander basierend auf Laufzeitkontext. Zu jedem Zeitpunkt ist nur ein Agent aktiv.

Wann einsetzen: Kundensupport, bei dem sich der richtige Spezialist im Verlauf des Gesprächs herausstellt (ein Abrechnungsproblem entpuppt sich als eigentlich technisches Problem). Aufgaben, bei denen der Fachbedarf im Voraus nicht bekannt ist.

HCLTech berichtete über 40 % schnellere Falllösungen durch dynamische Agentenübergabe. Das Muster funktioniert gut, wenn Sie zu Beginn wirklich nicht vorhersagen können, welcher Spezialist für eine Interaktion benötigt wird.

Wie es scheitert

Endlose Übergabeschleifen. Agent A übergibt an B, B an C, C wieder an A. Das ist der häufigste Fehler. Jeder Agent plant ständig neu, weil niemand die Verantwortung für die Aufgabe übernimmt.

Der Kontextverlust verstärkt sich mit jeder Übergabe. Entweder übergeben Sie den vollständigen Kontext (teuer und irgendwann über den Fenstergrenzen) oder Sie fassen zusammen (verlustbehaftet, und kumulierte Zusammenfassungsfehler verschlechtern die Qualität). Und weil das Routing nicht deterministisch ist, kann derselbe Input völlig unterschiedliche Agentenketten erzeugen, was das Debugging nahezu unmöglich macht.

6. Adaptive Planung

Ein Manager-Agent erstellt, verfeinert und führt dynamisch einen Aufgabenplan aus, indem er Spezialisten konsultiert. Anders als beim Orchestrator-Worker, bei dem der Plan im Voraus bekannt ist, wird der Plan hier selbst durch Zusammenarbeit entdeckt. Der Manager iteriert, springt zurück und delegiert bei Bedarf, während er kontinuierlich prüft, ob das ursprüngliche Ziel erreicht wurde.

Wann einsetzen: Offene Probleme ohne vorgegebenen Lösungsweg. Incident Response, bei der Abhilfeschritte aus der Diagnose entstehen. Komplexe Migrationen, bei denen sich der Umfang während der Umsetzung ändert.

Microsoft dokumentiert ein SRE-Beispiel: Der Manager erstellt einen ersten Plan, konsultiert Diagnose- und Infrastruktur-Agenten, und wenn die Diagnose statt eines Bereitstellungsproblems ein Datenbankproblem offenbart, schwenkt der gesamte Plan in Echtzeit um.

Wie es scheitert

Langsam beim Erreichen eines stabilen Ergebnisses. Das Muster optimiert auf Korrektheit statt auf Geschwindigkeit. Zeitkritische Aufgaben sind daher schlecht geeignet.

Zieldrift ist der Killer im Produktivbetrieb. Über mehrere Iterationen kann der verfeinerte Plan des Managers deutlich vom ursprünglichen Ziel abweichen. Backtracking verschärft das Problem: Wenn der Manager einen toten Pfad entdeckt, ist die gesamte Arbeit dieses Zweigs verlorene Rechenzeit, und die Kosten sind im Voraus nicht vorhersehbar. Wenn die ursprüngliche Anfrage vage ist, kann der Manager endlos versuchen, einen "vollständigen" Plan zu erstellen, der ein unpräzise formuliertes Ziel erfüllt.

Wie Sie das richtige Muster auswählen

Beginnen Sie mit dem einfachsten Muster, das zu Ihrem Problem passt. Die meisten Teams überarchitektieren.

Bekannte Aufgabenzerlegung? Orchestrator-Worker. Sie kennen die Teilaufgaben zur Entwurfszeit und möchten einen einzigen Verantwortungs­punkt.

Feste lineare Schritte? Sequentielle Pipeline. Die Reihenfolge ändert sich nie und jeder Schritt hängt von der vorherigen Ausgabe ab.

Unabhängige parallele Arbeit? Fan-out/Fan-in. Vier oder mehr Aufgaben ohne Abhängigkeiten untereinander.

Qualitätsprüfung nötig? Multi-Agenten-Debatte. Besonders Maker-Checker-Schleifen, bei denen Genauigkeit wichtiger ist als Geschwindigkeit.

Unvorhersehbares Routing? Dynamische Übergabe. Sie können erst im Verlauf des Gesprächs wissen, welcher Spezialist benötigt wird.

Offenes Problem? Adaptive Planung. Der Plan selbst muss entdeckt und nicht nur ausgeführt werden.

Princeton NLP fand heraus, dass ein einzelner Agent bei 64 % der Benchmark-Aufgaben gleichgezogen oder Multi-Agenten-Systeme übertroffen hat, wenn ihm dieselben Werkzeuge und derselbe Kontext zur Verfügung standen. Multi-Agenten erhöhen die Genauigkeit um 2,1 Prozentpunkte bei ungefähr doppelten Kosten. Dieser Kompromiss lohnt sich bei komplexer, domänenübergreifender Arbeit. Für alles andere ist ein gut gebauter einzelner KI-Agent einfacher, schneller und günstiger.

Das beste Orchestrierungsmodell ist dasjenige, das zu Ihrem tatsächlichen Problem passt – nicht das anspruchsvollste, das Sie bauen können.