Orchestrator-Worker: Das robusteste Multi-Agent-Pattern

Das Orchestrator-Worker-Pattern ist ein Multi-Agent-Aufbau, bei dem ein Lead-Agent (Orchestrator) eine Aufgabe in Teilaufgaben zerlegt, diese an spezialisierte Worker-Agents mit jeweils eigenem Kontextfenster delegiert und deren komprimierte Ergebnisse zu einer finalen Antwort zusammenführt. Anthropic beschreibt es in "Building effective agents" als einen von fünf Workflows und nutzt es als Architektur seines Multi-Agent-Research-Systems. Unter den Multi-Agent-Mustern gilt es als das robusteste, weil es die häufigste Fehlerquelle verteilter Agenten umgeht.

• Was passiert: Orchestrator plant und zerlegt, Worker arbeiten parallel und unabhängig, Orchestrator aggregiert und schreibt als Einziger.
• Wofür geeignet: parallelisierbare Aufgaben mit geringer Kopplung zwischen den Teilaufgaben, etwa Research, Marktbeobachtung, Multi-Dokument-Review, breite Triage.
• Wofür ungeeignet: eng gekoppelte, sequenzielle Schreib-Aufgaben wie Code-Generierung über mehrere Dateien oder komplexe Transaktions-Workflows.

Wie das Pattern funktioniert

Der Orchestrator läuft in einem Planungs- oder Extended-Thinking-Modus. Er nimmt die Anfrage entgegen, zerlegt sie in diskrete, voneinander unabhängige Teilaufgaben und spawnt für jede einen Worker-Agent über ein Task- oder Subagent-Tool. Entscheidend ist die strikte Isolation: Jeder Worker hat seinen eigenen Prompt, sein eigenes Toolset und vor allem sein eigenes Kontextfenster. Die Worker recherchieren, rufen Tools auf und reasonieren unabhängig voneinander. Statt ihrer vollständigen Transkripte liefern sie nur ein komprimiertes Ergebnis an den Orchestrator zurück, der daraus die finale Antwort synthetisiert.

Diese Architektur ist das exakte Gegenteil eines undisziplinierten Agenten-Schwarms. Die Worker-Kontexte sind getrennt, damit Parallelität überhaupt möglich wird. Der Schreibpfad bleibt aber einsträngig: Nur der Orchestrator führt die Fragmente zusammen. Genau diese Kombination, isolierte Lese-Worker plus single-threaded Synthese, macht das Muster belastbar.

Warum es als robustestes Multi-Agent-Pattern gilt

Die Robustheit ergibt sich aus dem Engineering-Diskurs des Jahres 2025. Cognition argumentierte in "Don't Build Multi-Agents" (12. Juni 2025), dass parallele Sub-Agenten standardmäßig fragil sind, weil sie ihren Kontext fragmentieren. Mehrere Agenten, die gleichzeitig schreiben, treffen widersprüchliche implizite Entscheidungen, etwa zu Stil oder Edge Cases, und produzieren Ergebnisse, die niemand mehr zusammenführen kann. Cognitions zentrale These: Handlungen tragen implizite Entscheidungen, und widersprüchliche Entscheidungen führen zu schlechten Ergebnissen ("Actions carry implicit decisions, and conflicting decisions carry bad results"). Die Ursache solcher Konflikte ist Context-Fragmentierung.

Genau hier setzt das Orchestrator-Worker-Muster an. Es vermeidet konkurrierende Schreibvorgänge vollständig. Die Worker steuern Intelligenz bei, indem sie lesen, sammeln und vorschlagen, aber nur der Orchestrator reconcilet und schreibt. In seinem Update "Multi-Agents: What's Actually Working" (22. April 2026) bestätigte Cognition diese Position: Das Unternehmen setzt selbst Multi-Agent-Systeme ein, allerdings genau jene Variante, "in der mehrere Agenten Intelligenz zu einer Aufgabe beitragen, während die Schreibvorgänge einsträngig bleiben". Orchestrator-Worker ist die saubere Implementierung dieses Prinzips. Es ist nicht das mächtigste Muster für jeden Fall, aber es ist das verlässlichste für die Klasse von Aufgaben, für die Multi-Agent überhaupt sinnvoll ist.

Das Referenz-Beispiel: Anthropic Research Agent

Die kanonische Fallstudie ist das Multi-Agent-Research-System von Anthropic, dokumentiert in "How we built our multi-agent research system" (13. Juni 2025) und produktiv in Claudes Research-Funktion. Der Aufbau:

• Lead-Orchestrator: Claude Opus 4 im Extended-Thinking-Modus, zerlegt die Nutzeranfrage und delegiert. Seinen Plan sichert er in einem Memory, weil sein Kontext ab 200.000 Token gekürzt wird.
• Worker: N parallele Claude-Sonnet-4-Sub-Agenten, die der Lead über ein Tool erzeugt. Jeder Worker besitzt sein eigenes Kontextfenster und nutzt Such- und Fetch-Tools unabhängig.
• Rückgabe: Jeder Worker liefert eine komprimierte Zusammenfassung, kein vollständiges Transkript. Der Orchestrator synthetisiert daraus die Antwort.

Die meistzitierten Zahlen aus Anthropics Fallstudie:

Laut Anthropic rechnet sich dieser Token-Aufwand nur, wenn der Wert der Aufgabe die Mehrkosten trägt, etwa bei stark parallelisierbaren, breitenorientierten Recherchen. Für eng gekoppelte Coding-Workflows passt das Muster nach Anthropics Einschätzung derzeit schlecht, weil die meisten Coding-Aufgaben weniger echt parallelisierbare Teilaufgaben haben als Research (alle Angaben Stand Juni 2025).

Rollen im Orchestrator-Worker-Pattern

Wann das Pattern passt, und wann nicht

Passt für breitenorientierte, parallelisierbare Probleme, deren Teilaufgaben unabhängig sind: Research, Marktintelligenz, Multi-Dokument-Review, breite Triage, Auffinden vergleichbarer Dokumente. Diese Aufgaben haben geringe State-Kopplung zwischen den Teilproblemen, und der Schreibpfad lässt sich trivial einsträngig halten.

Passt nicht für eng gekoppelte Schreib-Aufgaben (Code-Generierung über mehrere Dateien, komplexe Transaktions-Workflows) sowie für Hochdeterminismus-Workflows mit Reproduzierbarkeitspflicht. Dort ist eine deterministische Pipeline die bessere Wahl.

Für die Pattern-Auswahl lässt sich Orchestrator-Worker so einordnen: hohe Parallelisierbarkeit, geringe bis mittlere tolerierte State-Kopplung, mittlere Latenztoleranz, mittlere Evaluierbarkeit (benötigt Trace-Tooling), produktionsreif heute bei Anthropic, AWS Bedrock und Agentforce (Stand 2026).

Vor- und Nachteile, Kosten

Vorteile: drastischer Qualitätsgewinn bei Breiten-Aufgaben, echte Parallelität durch isolierte Worker-Kontexte, vermeidet Context-Fragmentierung durch single-threaded Synthese, produktionsreif in mehreren Stacks.

Nachteile und Kosten: Der Token-Verbrauch ist der zentrale Einwand. Anthropic misst für Multi-Agent-Systeme rund das 15-Fache einer Chat-Interaktion, für einen einzelnen Agenten rund das 4-Fache. Der Aufpreis gegenüber dem Single-Agent liegt damit etwa beim Faktor 3 bis 4. Hinzu kommen typische Fehlerquellen:

• Vage Delegationen. Unpräzise Aufgaben-Briefings führten in Anthropics frühen Experimenten zu Doppelarbeit und Abdeckungslücken. Der Orchestrator muss explizit lernen, wie er delegiert.
• Orchestrator-Drift. Über lange Läufe verliert der Lead seinen Plan und spawnt Worker für bereits erledigte Aufgaben erneut.
• Prompt-Injection-Amplifikation. Jedes neue Worker-Kontextfenster ist eine neue Angriffsfläche. Wenn Worker nicht vertrauenswürdige Inhalte aufnehmen, skaliert die Injection-Gefahr mit der Zahl der Agenten.

Eine praktische Gegenrezeptur für Teams mit begrenztem Budget:

1. Worker-Token-Budget explizit deckeln (Bedrock AgentCore, LangGraph und Claude Agent SDK unterstützen das).
2. Worker-Ausgaben in ein typisiertes Schema zwingen (Pydantic, JSON-Schema oder A2A-Artefakt).
3. Vor der Rückgabe komprimieren, niemals ein volles Worker-Transkript an den Orchestrator zurückreichen.
4. Den Orchestrator präzise briefen: Jeder Worker bekommt Objective, Ausgabeformat, Tool- und Quellen-Hinweise sowie klare Aufgabengrenzen.

Rechenbeispiel mit Zahlen

Angenommen, eine Wettbewerbsanalyse über 30 Marktteilnehmer. Ein Single-Agent verbraucht dafür schätzungsweise 200.000 Token in einem sequenziellen Lauf. Im Orchestrator-Worker-Aufbau zerlegt der Lead die Aufgabe in zehn parallele Worker, jeder bearbeitet drei Wettbewerber. Anthropic misst für Agenten rund das 4-Fache und für Multi-Agent-Systeme rund das 15-Fache des Token-Verbrauchs einer Chat-Interaktion. Gegenüber dem Single-Agent ergibt das etwa den Faktor 3 bis 4, der Gesamtverbrauch liegt also bei rund 600.000 bis 800.000 Token. In Anthropics interner Research-Evaluation übertraf das Multi-Agent-System einen Single-Agent Claude Opus 4 um 90,2 Prozent. Die Entscheidungsregel ist damit klar: Lohnt sich der drei- bis vierfache Token-Preis für ein um rund 90 Prozent besseres Eval-Ergebnis? Bei einer einmaligen, geschäftskritischen Marktstudie ja, bei einem täglichen Routine-Report fast immer nein. (Die Token-Werte des Beispiels sind illustrative Schätzungen. Belegt sind die Faktoren 4 und 15 gegenüber dem Chat sowie die 90,2 Prozent aus Anthropics Research-System, der Faktor 3 bis 4 gegenüber dem Single-Agent ist daraus abgeleitet.)

Ein produktiver Beleg aus Australien für ein eng verwandtes, hierarchisches Setup ist Allianz Project Nemo: sieben spezialisierte Agenten (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) für die Bearbeitung von Schäden durch verdorbene Lebensmittel nach Naturkatastrophen. Der gesamte Workflow läuft in unter fünf Minuten, ein menschlicher Sachbearbeiter prüft die Audit-Zusammenfassung und entscheidet (Human-in-the-Loop als explizite Policy). Dokumentiertes Ergebnis: 80 Prozent kürzere Bearbeitungs- und Regulierungszeit für berechtigte Fälle unter 500 AUD, im Juli 2025 gestartet und in unter 100 Tagen ausgerollt.

Für Agenturen und B2B-Entscheider

Für Marketing-Agenturen ist Orchestrator-Worker das passende Muster überall dort, wo Breite zählt: parallele Recherche zu vielen Wettbewerbern, Content-Audits über große Seitenmengen, Auswertung vieler Quellen für einen Report. Setze es bewusst nicht für die finale Texterstellung mehrerer Agenten parallel ein, hier gilt single-threaded Schreiben. Für B2B-Entscheider lautet die Steering-Committee-taugliche Faustregel: Multi-Agent im Orchestrator-Worker-Stil dann, wenn die Aufgabe parallelisierbar ist, geringe Kopplung zwischen den Teilaufgaben hat und der Schreibpfad einsträngig bleibt. Rationale Defaults für DACH-Projekte sind n8n oder LangGraph als Orchestrierung, MCP für Tools und A2A für plattformübergreifende Handoffs. Wer das robusteste Multi-Agent-Pattern sauber verstehen und umsetzen will, beginnt mit klarer Aufgaben-Zerlegung und harten Token-Caps, nicht mit der Zahl der Agenten.