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

Gartner verzeichnete einen Anstieg von 1.445 % bei Anfragen zu Multi-Agenten-Systemen zwischen dem 1. Quartal 2024 und dem 2. Quartal 2025. Unternehmen nutzen bereits durchschnittlich 12 Agenten, und diese Zahl soll innerhalb von zwei Jahren um 67 % steigen.

Doch 40 % der Multi-Agenten-Piloten scheitern innerhalb von sechs Monaten nach der Produktivsetzung. Das Muster zeigt nicht, dass Multi-Agenten-Systeme nicht funktionieren. Es liegt vielmehr daran, dass Teams das falsche Orchestrierungsmuster für ihr Problem wählen oder sich für das richtige entscheiden, ohne zu verstehen, an welchen Stellen es fehleranfällig ist.

Hier sind sechs Muster, die sich in der Praxis bewähren, zusammen mit den spezifischen Gründen, warum sie im Ernstfall scheitern.

1. Orchestrator-Worker

Ein Agent empfängt die Aufgabe, zerlegt sie in Teilaufgaben, delegiert diese an spezialisierte Worker und führt die Ergebnisse zusammen. Der Orchestrator nutzt ein leistungsstarkes Modell, während die Worker günstigere, aufgabenspezifische Modelle verwenden, was die Kosten um 40–60 % senkt.

Wann es sich eignet: Bereichsübergreifende Workflows mit klarer Aufgabenaufteilung. Routing im Kundenservice zwischen Rechnungsstellung, technischem Support und Produktspezialisten. Jede Aufgabe, bei der eine einzige verantwortliche Instanz benötigt wird.

Wells Fargo nutzt dieses Muster, um 35.000 Bankangestellten in 30 Sekunden statt in 10 Minuten Zugriff auf 1.700 Verfahren zu ermöglichen. Agentforce 2.0 von Salesforce implementiert es über seine Atlas Reasoning Engine.

Gründe für das Scheitern

Der Orchestrator ist eine einzige Fehlerquelle (Single Point of Failure). Wenn er eine Aufgabe falsch klassifiziert, erhält der falsche Worker den Auftrag, und die Fehlklassifizierungsraten summieren sich bei steigender Skalierung.

Der Überlauf des Kontextfensters ist das subtilere Problem. Der Orchestrator sammelt den Kontext von jedem Worker an. Bei vier oder mehr Workern überschreitet der Kontext häufig die Grenzwerte des Fensters. Workflows, die in der Testphase 0,50 $ kosten, können bei 100.000 Ausführungen 50.000 $/Monat erreichen, da der Orchestrator zusätzlich zu jedem Worker-Aufruf mehrere LLM-Aufrufe für die Aufteilung und Aggregation durchführt.

2. Sequenzielle Pipeline

Agenten arbeiten in einer vordefinierten linearen Kette. Jeder verarbeitet die Ausgabe des vorherigen Agenten über einen gemeinsamen Status. Die Reihenfolge ist deterministisch und wird zum Zeitpunkt des Designs festgelegt.

Wann es sich eignet: Dokumentenverarbeitung (Analysieren, Extrahieren, Validieren, Zusammenfassen). Vertragserstellung. Inhaltsmoderation. Jeder mehrstufige Prozess mit klaren linearen Abhängigkeiten.

Das Azure Architecture Center von Microsoft dokumentiert eine Anwaltskanzlei, die dieses Prinzip für die Vertragserstellung nutzt: Vorlagenauswahl, Anpassung von Klauseln, Compliance-Prüfung und Risikobewertung – jeweils bearbeitet von einem separaten AI-Agenten.

Gründe für das Scheitern

Fehlerfortpflanzung. Eine fehlerhafte Ausgabe in Phase 1 zieht sich durch alle nachgelagerten Phasen, ohne dass ein Zurückgehen möglich ist.

Das weniger offensichtliche Problem ist der Overhead. Eine Pipeline mit vier Agenten verursacht etwa 950 ms Koordinations-Overhead, während die eigentliche Verarbeitung 500 ms dauert. Eine Pipeline mit drei Agenten verbraucht 29.000 Token im Vergleich zu 10.000 bei einem equivalenten Einzelagenten-Ansatz. Wenn Ihre Pipeline die Spezialisierung nicht benötigt, zahlen Sie das Dreifache für dasselbe Ergebnis.

3. Fan-out / Fan-in

Mehrere Agenten arbeiten gleichzeitig an derselben Eingabe oder an unabhängigen Teilaufgaben. Ein Dispatcher verteilt die Arbeit, ein Collector führt die Ergebnisse mittels Abstimmung, gewichtetem Zusammenführen oder LLM-basierter Synthese zusammen.

Wann es sich eignet: Analysen aus verschiedenen Perspektiven (Finanzanalyse mit parallel laufenden Agenten für fundamentale, technische, Sentiment- und ESG-Analysen). Gleichzeitige Code-Überprüfung in den Bereichen Sicherheit, Stil und Leistung. Jedes Szenario mit vier oder mehr unabhängigen Aufgaben, bei dem Sie die reale Durchlaufzeit um 75 % verkürzen müssen.

Gründe für das Scheitern

API-Ratenbegrenzungen. Fünfzehn gleichzeitige Agenten verbrauchen 150 Anfragen pro Sekunde, wenn Ihr Limit bei 100 liegt. Jeder Agent für sich bleibt innerhalb der Grenzwerte, aber die Gesamtlast überschreitet die Kapazität.

Race Conditions im gemeinsamen Status 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 bereits 45.

Der Aggregationsschritt selbst birgt Fehlerquellen. Eine LLM-basierte Synthese kann einen Konsens halluzinieren, der in den zugrunde liegenden Ergebnissen gar nicht existiert. Wenn Ihre parallelen Agenten uneins sind (Sentiment sagt Kaufen, Fundamentalanalyse sagt Verkaufen), benötigen Sie eine explizite Strategie zur Konfliktlösung und nicht bloß eine „Zusammenfassung der Ergebnisse“.

4. Multi-Agenten-Debatte

Mehrere Agenten nehmen an einer gemeinsamen Konversation teil, bringen Perspektiven ein, fordern sich gegenseitig heraus und verfeinern ihre Positionen über mehrere Runden hinweg. Dies umfasst auch Maker-Checker-Schleifen, bei denen ein Agent etwas generiert und ein anderer es bis zur Freigabe validiert.

Wann es sich eignet: Compliance-Prüfungen, die mehrere Expertenperspektiven erfordern. Qualitätssicherung mit strukturierter Überprüfung. Untersuchungen zeigen, dass Debatten Halluzinationen im Vergleich zu Abfragen mit nur einem Modell reduzieren, da die Agenten die Fehler der anderen korrigieren.

Eine praktische Variante: Nutzen Sie ein günstiges, schnelles Modell für den Maker und ein leistungsstarkes Modell für den Checker. Sie erhalten die Qualitätsverbesserung einer Debatte zu 40–60 % geringeren Kosten, als wenn Sie beide Rollen auf leistungsstarken Modellen ausführen würden.

Gründe für das Scheitern

Konversationsschleifen. Die Agenten debattieren weiter, ohne zu einer Einigung zu gelangen. Microsoft empfiehlt aus diesem Grund, Gruppenchats auf maximal drei Agenten zu beschränken.

Kriecherisches Folgeverhalten (Sycophancy Cascading) ist das schwierigere Problem. Agenten neigen dazu, sich der Mehrheitsmeinung anzuschließen, selbst wenn diese falsch ist, was zu einem falschen Konsens führt. Fünf Runden mit drei Agenten bedeuten 15 LLM-Aufrufe pro Aufgabe, und das Ergebnis kann dennoch überzeugend falsch sein, da die Agenten die Fehler der anderen gegenseitig bestärkt haben.

5. Dynamische Übergabe (Dynamic Handoff)

Jeder Agent bewertet die aktuelle Aufgabe und entscheidet selbstständig, ob er sie bearbeitet oder die Kontrolle an einen besser geeigneten Spezialisten übergibt. Im Gegensatz zum Orchestrator-Worker-Modell gibt es keinen zentralen Koordinator. Die Agenten delegieren basierend auf dem Laufzeitkontext untereinander. Es ist immer nur ein Agent aktiv.

Wann es sich eignet: Kundenservice, bei dem sich der richtige Spezialist erst im Laufe des Gesprächs herauskristallisiert (ein Abrechnungsproblem entpuppt sich als technisches Problem). Aufgaben, bei denen die Anforderungen an das Fachwissen vorab nicht bekannt sind.

HCLTech berichtete von einer um 40 % schnelleren Falllösung durch die dynamische Übergabe zwischen Agenten. Das Muster funktioniert hervorragend, wenn sich zu Beginn absolut nicht vorhersagen lässt, welcher Spezialist für eine Interaktion benötigt wird.

Gründe für das Scheitern

Endlose Übergabeschleifen. Agent A übergibt an B, B an C und C wieder zurück an A. Dies ist die Fehlerquelle Nummer eins. Jeder Agent plant ständig neu, weil niemand die Verantwortung für die Aufgabe übernimmt.

Der Verlust von Kontext summiert sich mit jeder Übergabe. Entweder übergeben Sie den vollständigen Kontext (teuer und überschreitet irgendwann die Limits) oder Sie fassen ihn zusammen (verlustbehaftet, und kumulierte Zusammenfassungsfehler mindern die Qualität). Da das Routing zudem nicht-deterministisch ist, kann dieselbe Eingabe völlig unterschiedliche Agentenketten erzeugen, was das Debugging nahezu unmöglich macht.

6. Adaptive Planung (Adaptive Planning)

Ein Manager-Agent erstellt, verfeinert und führt einen Aufgabenplan dynamisch aus, indem er Spezialisten konsultiert. Im Gegensatz zum Orchestrator-Worker-Modell, bei dem der Plan im Vorfeld feststeht, wird der Plan hier erst durch die Zusammenarbeit entwickelt. Der Manager iteriert, geht Schritte zurück und delegiert je nach Bedarf, während er fortlaufend prüft, ob das ursprüngliche Ziel erreicht wird.

Wann es sich eignet: Offene Probleme ohne vorgegebenen Lösungsweg. Incident Response, bei dem sich die Schritte zur Behebung erst aus der Diagnose ergeben. Komplexe Migrationen, bei denen sich der Projektumfang während der Ausführung ändert.

Microsoft dokumentiert ein SRE-Beispiel: Der Manager erstellt einen ersten Plan, konsultiert Diagnose- und Infrastruktur-Agenten, und sobald die Diagnose ein Datenbankproblem anstelle eines Bereitstellungsproblems aufdeckt, passt sich der gesamte Plan in Echtzeit an.

Gründe für das Scheitern

Langsame Konvergenz. Dieses Muster ist auf Korrektheit statt auf Schnelligkeit optimiert. Für zeitkritische Aufgaben ist es kaum geeignet.

Zielabweichung (Goal Drift) ist das größte Problem im Produktivbetrieb. Über mehrere Iterationen hinweg kann der verfeinerte Plan des Managers erheblich von der ursprünglichen Absicht abweichen. Das Zurückgehen (Backtracking) verschlimmert dies noch: Wenn der Manager eine Sackgasse entdeckt, war die gesamte Arbeit in diesem Zweig umsonst – und die Kosten lassen sich im Vorfeld nicht kalkulieren. Wenn die ursprüngliche Anfrage vage ist, kann sich der Manager in Endlosschleifen verlieren, während er versucht, einen „vollständigen“ Plan für ein unzureichend definiertes Ziel zu erstellen.

So wählen Sie das richtige Muster

Beginnen Sie mit dem einfachsten Muster, das zu Ihrem Problem passt. Die meisten Teams neigen zu Over-Engineering.

Bekannte Aufgabenaufteilung? Orchestrator-Worker. Sie kennen die Teilaufgaben bereits beim Design und wünschen sich eine einzige verantwortliche Instanz.

Feste lineare Schritte? Sequenzielle Pipeline. Die Reihenfolge ändert sich nie und jeder Schritt baut auf der vorherigen Ausgabe auf.

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

Qualitätsprüfung erforderlich? Multi-Agenten-Debatte. Insbesondere Maker-Checker-Schleifen, bei denen Genauigkeit wichtiger ist als Geschwindigkeit.

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

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

Princeton NLP fand heraus, dass ein einzelner Agent bei 64 % der getesteten Aufgaben mit Multi-Agenten-Systemen gleichzog oder diese übertraf, wenn ihm dieselben Werkzeuge und derselbe Kontext zur Verfügung standen. Multi-Agenten-Systeme bringen ein Plus von 2,1 Prozentpunkten an Genauigkeit bei etwa doppelten Kosten. Dieser Kompromiss lohnt sich für komplexe, bereichsübergreifende Aufgaben. Für alles andere ist ein gut strukturierter, einzelner AI-Agent einfacher, schneller und günstiger.

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