Multi-Agent-Orchestrierung ist das Architekturmuster, das mehrere spezialisierte KI-Agenten koordiniert, um Aufgaben zu erledigen, die ein einzelner Agent nicht bewältigen kann. Konkret bedeutet das: Eine Steuerungsschicht entscheidet, welcher Agent wann läuft, welche Daten er bekommt und was mit seiner Ausgabe passiert.
Deloittes TMT Predictions 2026 zeigt die Lücke deutlich: 80 % der Unternehmenslenker halten ihre Basis-Automatisierung für ausgereift, aber nur 28 % sagen dasselbe, sobald KI-Agenten ins Spiel kommen. Das Koordinationsproblem ist der Grund. Einzelne Agenten funktionieren isoliert. Drei, fünf oder zwanzig davon so zusammenzubringen, dass sie sich nicht gegenseitig blockieren, Arbeit doppelt erledigen oder Kontext verlieren: Das ist die eigentliche Herausforderung.
Dieser Leitfaden behandelt die fünf Orchestrierungsmuster, die Produktionssysteme tatsächlich einsetzen, wann welches passt und welche Stolpersteine Microsoft, Databricks und Deloitte in ihren Referenzarchitekturen benennen.
Die fünf Muster der Multi-Agent-Orchestrierung
Microsofts Azure Architecture Center dokumentiert fünf Orchestrierungsmuster für Multi-Agent-Systeme. Jedes löst ein anderes Koordinationsproblem. Das falsche Muster zu wählen ist teurer als das falsche Framework, denn das Muster bestimmt den gesamten Datenfluss, die Fehlerbehandlung und die Skalierbarkeit des Systems.
1. Sequenzielle Pipeline
Das einfachste Muster. Agenten verarbeiten Aufgaben in einer festen Reihenfolge, wobei die Ausgabe eines Agenten direkt in den nächsten fließt.
Funktionsweise: Eingabe geht an Agent A, dessen Ausgabe an Agent B, dessen Ausgabe an Agent C. Kein Branching, keine Parallelisierung, kein Backtracking.
Praxisbeispiel: Eine Vertragserstellungs-Pipeline bei einer Rechtsabteilung: Ein Vorlagen-Agent wählt den richtigen Vertragstyp, ein Klausel-Agent passt die Bedingungen an, ein Compliance-Agent prüft regulatorische Anforderungen, und ein Risikobewertungs-Agent bewertet das Endergebnis. Jeder Schritt braucht die Ausgabe des vorherigen.
Passt, wenn: Datentransformations-Pipelines mit klaren Abhängigkeiten vorliegen. Entwurf, Prüfung, Feinschliff. Jeder Prozess, bei dem Schritte nicht außer der Reihe laufen dürfen.
Scheitert, wenn: Aufgaben parallel laufen könnten. Dann verschwendet eine sequenzielle Pipeline Zeit. Dynamisches Routing auf Basis von Zwischenergebnissen ist hier nicht möglich. Und ein langsamer Agent blockiert alles, was danach kommt.
2. Paralleles Fan-Out
Mehrere Agenten verarbeiten dieselbe Eingabe gleichzeitig. Ihre unabhängigen Ergebnisse werden am Ende zusammengeführt.
Funktionsweise: Ein Initiator sendet dieselbe Eingabe parallel an die Agenten A, B und C. Jeder analysiert aus seiner spezialisierten Perspektive. Ein Aggregator kombiniert die Ergebnisse.
Praxisbeispiel: Finanzanalyse in deutschen Banken. Ein Fundamentalanalyse-Agent, ein technischer Analyse-Agent, ein Sentiment-Agent und ein ESG-Agent bewerten dieselbe Aktie gleichzeitig. Kein Agent hängt von der Ausgabe eines anderen ab. Der Aggregator löst widersprüchliche Empfehlungen auf.
Passt, wenn: Zeitkritische Szenarien vorliegen, die mehrere unabhängige Perspektiven brauchen. Ensemble-Reasoning und Abstimmungssysteme. Aufgaben, bei denen verschiedene Spezialisierungen zur selben Entscheidung beitragen.
Scheitert, wenn: Agenten auf der Arbeit der anderen aufbauen müssen. Bei Modell-Rate-Limits (vier parallele Agenten bedeuten vier gleichzeitige API-Aufrufe). Wenn es keine klare Strategie gibt, widersprüchliche Ergebnisse aufzulösen.
3. Supervisor-Hierarchie
Ein Agent fungiert als Manager, delegiert Aufgaben an Worker-Agenten und fasst deren Ergebnisse zusammen.
Funktionsweise: Der Supervisor empfängt eine komplexe Anfrage, zerlegt sie in Teilaufgaben, weist jede einem spezialisierten Worker-Agenten zu, überwacht den Fortschritt und stellt das Endergebnis zusammen. Databricks dokumentiert dieses Muster als “Supervisor of Supervisors” für Konzerne mit mehreren Geschäftsbereichen.
Praxisbeispiel: Ein Kundenservice-System bei einem DACH-Telekommunikationsanbieter, bei dem der Supervisor-Agent eingehende Anfragen triagiert. Technische Probleme gehen an einen Infrastruktur-Agenten, Rechnungsfragen an einen Finanz-Agenten und Vertragsänderungen an einen Account-Management-Agenten. Der Supervisor überwacht die Qualität und eskaliert an einen menschlichen Mitarbeiter, wenn der Konfidenzwert unter den Schwellenwert fällt.
Passt, wenn: Komplexe Aufgaben eine Zerlegung erfordern. Zentrale Koordination und Qualitätskontrolle nötig sind. Das System eine einzige Stelle für Monitoring und Steuerung braucht.
Scheitert, wenn: Worker-Agenten direkt miteinander kommunizieren müssen. Dann wird der Supervisor zum Flaschenhals, weil jede Nachricht über ihn läuft. Bei sehr großen Agent-Pools ist eine mehrstufige Hierarchie die bessere Wahl.
4. Dynamischer Handoff
Agenten übertragen die Kontrolle an besser geeignete Spezialisten, basierend auf dem Laufzeitkontext. Nur ein Agent arbeitet zur selben Zeit.
Funktionsweise: Ein Triage-Agent empfängt die Anfrage, bewertet, welche Art von Expertise benötigt wird, und gibt an den richtigen Spezialisten ab. Der Spezialist kann erneut weiterleiten, wenn sich das Problem in eine andere Domäne verschiebt. Das OpenAI Agents SDK wurde um genau dieses Muster herum gebaut.
Praxisbeispiel: Ein Support-System bei einem Telekommunikationsanbieter. Der Triage-Agent leitet Netzwerkprobleme an einen Infrastruktur-Agenten weiter. Stellt dieser fest, dass es eigentlich ein Abrechnungsproblem ist, gibt er an einen Finanz-Agenten ab. Kann der es nicht lösen, übergibt er an einen menschlichen Mitarbeiter. Bei jeder Übergabe wird der vollständige Kontext mitgegeben.
Passt, wenn: Der richtige Agent vorab nicht bekannt ist und sich Anforderungen erst während der Verarbeitung zeigen. Multi-Domänen-Probleme, die nacheinander verschiedene Spezialisten brauchen.
Scheitert, wenn: Routing-Entscheidungen deterministisch sind (dann besser codebasiertes Routing). Bei Aufgaben, die parallele Verarbeitung brauchen. Und Vorsicht vor Endlos-Schleifen: Agent A gibt an Agent B ab, der zurück an Agent A.
5. Kollaborativer Gruppenchat
Mehrere Agenten nehmen an einem verwalteten Konversations-Thread teil, koordiniert durch einen Chat-Manager.
Funktionsweise: Ein Chat-Manager steuert den Gesprächsfluss und bestimmt, welcher Agent als nächstes spricht. Agenten tragen aus ihrer Spezialisierung bei, können die Beiträge anderer hinterfragen oder darauf aufbauen. Die Konversation sammelt sich in einem gemeinsamen Thread.
Praxisbeispiel: Eine Stadtplanungs-Evaluation, bei der ein Bürgerbeteiligungs-Agent, ein Umweltplanungs-Agent und ein Budget-Agent einen Bebauungsplan diskutieren. Jeder trägt seine Fachanalyse bei, hinterfragt Annahmen der anderen, und die Gruppe konvergiert auf eine Empfehlung. Ein menschlicher Stadtplaner beteiligt sich am Thread neben den Agenten.
Passt, wenn: Kollaboratives Brainstorming mit Debatte und Konsensbildung gefragt ist. Maker-Checker-Schleifen, bei denen ein Agent vorschlägt und ein anderer prüft.
Scheitert, wenn: Mehr als drei Agenten beteiligt sind. Der Chat-Manager hat dann Schwierigkeiten, kohärente Redezuordnung aufrechtzuerhalten. Der Diskussions-Overhead tötet die Performance bei deterministischen Workflows.
Orchestrierung vs. Choreographie: Der Unterschied, der zählt
Die meisten Teams verwechseln diese beiden Konzepte und bauen dann das Falsche.
Orchestrierung nutzt einen zentralen Koordinator. Eine Komponente (der Orchestrator, Supervisor oder Chat-Manager) kennt den vollständigen Workflow, entscheidet, was als nächstes passiert, und routet Daten zwischen Agenten. Genau das implementieren LangGraphs State-Graphen, CrewAIs Flows und das Supervisor-Muster.
Choreographie hat keinen zentralen Koordinator. Agenten reagieren eigenständig auf Events. Wenn Agent A fertig ist, publiziert er ein Event. Agent B hat diesen Event-Typ abonniert und verarbeitet ihn. Keine einzelne Komponente kennt den gesamten Workflow. Das ist es, was A2A auf Protokollebene ermöglicht: Agenten, die sich gegenseitig finden und ohne zentralen Orchestrator zusammenarbeiten.
Der praktische Unterschied: Orchestrierung gibt Kontrolle und Observability, schafft aber einen Single Point of Failure. Choreographie gibt Resilienz und Skalierbarkeit, macht Debugging aber zum Albtraum, weil keine einzelne Komponente den Gesamtzustand des Systems kennen kann.
Für die meisten Unternehmensteams in 2026 ist Orchestrierung die richtige Standardwahl. Deloittes Forschung zeigt, dass mehr als 40 % der Agentic-AI-Projekte bis 2027 eingestellt werden könnten, weil Skalierungskomplexität und unerwartete Risiken unterschätzt werden. Orchestrierung gibt die Observability, um Probleme zu erkennen, bevor sie projektgefährdend werden. Choreographie ist richtig, wenn Agenten verschiedener Organisationen über Vertrauensgrenzen hinweg zusammenarbeiten müssen, genau das Problem, das MCP und A2A auf Protokollebene lösen.
Den Orchestrierungs-Stack aufbauen
Ein produktives Multi-Agent-System hat drei Schichten. Die meisten Teams konzentrieren sich auf die erste und ignorieren die anderen beiden.
Die Framework-Schicht
Hier wird das Orchestrierungsmuster implementiert. LangGraph bietet die meiste Kontrolle: explizite State-Graphen mit Checkpointing, bedingten Kanten und persistentem Speicher. CrewAI tauscht Kontrolle gegen Geschwindigkeit: rollenbasierte Agenten mit zwei Koordinationsmodi (Crews für dynamische Zusammenarbeit, Flows für deterministische Pipelines). Microsofts Agent Framework vereint AutoGen und Semantic Kernel zu einem einheitlichen SDK mit Unterstützung für sequenzielle, parallele, Handoff- und Magentic-Muster.
Die Framework-Wahl ist weniger wichtig als die Muster-Wahl. Eine Supervisor-Hierarchie in LangGraph und eine Supervisor-Hierarchie in CrewAI lösen dasselbe Koordinationsproblem. Der Unterschied liegt im Boilerplate-Code und dem Grad an Kontrolle.
Die Protokoll-Schicht
MCP verbindet Agenten mit Tools und Daten. A2A verbindet Agenten untereinander über Organisationsgrenzen hinweg. In orchestrierten Systemen ermöglicht MCP den Zugriff auf externe Ressourcen (Datenbanken, APIs, Dateisysteme). A2A ermöglicht die Interoperabilität zwischen dem eigenen Multi-Agent-System und dem eines anderen Unternehmens.
Salesforces Connectivity Report 2026 zeigt: Unternehmen nutzen durchschnittlich 12 Agenten, wobei 50 % in isolierten Silos arbeiten. Die Protokollschicht durchbricht diese Silos, aber nur, wenn sie eingeführt wird, bevor die Silos sich verfestigen.
Die Observability-Schicht
Hier scheitern die meisten Teams. Die Supervisor-Hierarchie steht. Drei Agenten laufen parallel. Der vierte Agent bekommt fehlerhafte Eingaben. Welcher Agent hat sie produziert? Wann? Mit welchem Kontext?
Ohne Observability sind Multi-Agent-Systeme Blackboxen. OpenTelemetrys GenAI Semantic Conventions bieten einen Standard für das Tracing von Agent-Interaktionen. Tools wie LangSmith, Arize Phoenix und Langfuse liefern die Dashboards. Die eigentliche Arbeit besteht darin, Agenten von Anfang an beobachtbar zu gestalten.
Häufige Fehler (und wie man sie vermeidet)
Agenten ohne klare Spezialisierung hinzufügen. Wenn zwei Agenten überlappende Domänen bedienen, entsteht doppelte Arbeit und widersprüchliche Ergebnisse. Jeder Agent braucht eine eindeutige, nicht überlappende Zuständigkeit.
Latenz ignorieren. Eine sequenzielle Pipeline mit fünf Agenten, die jeweils einen LLM-Aufruf machen, bedeutet fünf Roundtrips Latenz. Für kundenorientierte Anwendungen sind parallele Muster oder Vorausberechnung die bessere Wahl.
Veränderlichen State zwischen parallelen Agenten teilen. Zwei Agenten, die gleichzeitig denselben Datenspeicher beschreiben, produzieren Race Conditions. Unveränderliches Message-Passing oder ordentliches Locking einsetzen.
Das falsche Muster für den Workflow wählen. Eine sequenzielle Pipeline für parallelisierbare Aufgaben verschwendet Zeit. Ein paralleles Fan-Out für Aufgaben mit Abhängigkeiten liefert falsche Ergebnisse. Das Muster muss zur Aufgabenstruktur passen, nicht zum Standard des Frameworks.
Human-in-the-Loop bei kritischen Entscheidungen überspringen. Deloitte empfiehlt ein progressives Autonomie-Spektrum: Menschen im Loop für kritische Entscheidungen, Menschen am Loop für Routineaufgaben mit Monitoring, Menschen außerhalb des Loops nur für vollständig validierte, risikoarme Prozesse. Gerade im DACH-Raum sind die regulatorischen Anforderungen durch den EU AI Act strenger als anderswo.
Häufig gestellte Fragen
Was ist Multi-Agent-Orchestrierung?
Multi-Agent-Orchestrierung ist das Architekturmuster, das mehrere spezialisierte KI-Agenten koordiniert, um komplexe Aufgaben zu erledigen. Ein zentraler Orchestrator entscheidet, welcher Agent wann läuft, welche Daten er bekommt und wie die Ergebnisse zusammengeführt werden. Die fünf Hauptmuster sind sequenzielle Pipeline, paralleles Fan-Out, Supervisor-Hierarchie, dynamischer Handoff und kollaborativer Gruppenchat.
Was ist der Unterschied zwischen Orchestrierung und Choreographie bei Multi-Agent-Systemen?
Orchestrierung nutzt einen zentralen Koordinator, der den gesamten Workflow kennt und Agenten steuert. Choreographie hat keinen zentralen Koordinator: Agenten reagieren eigenständig auf Events und finden sich dynamisch. Orchestrierung bietet bessere Observability und Kontrolle, schafft aber einen Single Point of Failure. Choreographie bietet Resilienz und Skalierbarkeit, macht Debugging aber schwieriger.
Welches Multi-Agent-Orchestrierungsmuster soll ich verwenden?
Sequenzielle Pipelines für Aufgaben mit klaren schrittweisen Abhängigkeiten. Paralleles Fan-Out, wenn mehrere unabhängige Analysen parallel laufen müssen. Supervisor-Hierarchie für komplexe Aufgaben, die zentrale Koordination und Qualitätskontrolle brauchen. Dynamischer Handoff, wenn der richtige Spezialist vorab nicht bekannt ist. Gruppenchat für kollaborative Entscheidungsfindung mit Debatte und Konsens.
Wie viele Agenten sollte ein Multi-Agent-System haben?
So wenige wie nötig. Microsofts Azure Architecture Center empfiehlt, zuerst einen einzelnen Agenten mit mehreren Tools zu probieren. Bei Gruppenchat-Mustern maximal drei Agenten. Salesforce berichtet, dass Unternehmen 2026 durchschnittlich 12 Agenten nutzen, aber 50 % davon in isolierten Silos arbeiten, statt als koordinierte Multi-Agent-Systeme.
Welche Frameworks unterstützen Multi-Agent-Orchestrierung?
LangGraph unterstützt alle fünf Orchestrierungsmuster über explizite State-Graphen. CrewAI bietet rollenbasierte Orchestrierung mit Crews (dynamisch) und Flows (deterministisch). Microsofts Agent Framework vereint AutoGen und Semantic Kernel für unternehmenstaugliche Orchestrierung. Das OpenAI Agents SDK konzentriert sich auf Handoff-Muster.