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. In der Anthropic-Taxonomie ist es Baustein Nummer fünf und gilt als das kanonische Multi-Agent-Muster. Gleichzeitig ist es 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.ai 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: "Scheinbare Meinungsverschiedenheiten zwischen Agenten sind meist Symptome von 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 im Research-Feature von Claude.ai. Der Aufbau:

• Lead-Orchestrator: Claude Opus 4 im Extended-Thinking-Modus, zerlegt die Nutzeranfrage und delegiert.
• Worker: N parallele Claude-Sonnet-4-Sub-Agenten, gespawnt über das Task-Tool. Jeder Worker besitzt sein eigenes Kontextfenster von rund 200.000 Token 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 Zahlen aus Anthropics internen Evaluationen sind das meistzitierte Argument für das Muster:

Anthropic war explizit: Dieser Token-Aufwand rechnet sich nur für hochwertige, parallelisierbare, breitenorientierte Research-Aufgaben. Für eng gekoppelte Coding-Workflows empfiehlt Anthropic das Muster ausdrücklich nicht (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.

Die Pattern-Auswahl-Matrix der zugrundeliegenden Research-Quelle ordnet Orchestrator-Worker so ein: hohe Parallelisierbarkeit, geringe bis mittlere tolerierte State-Kopplung, Token-Kostenfaktor 5x bis 15x, 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, rund 15-fach im Anthropic-Fall. 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.

Die praktische Gegenrezeptur aus der Research-Quelle 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. Bei rund 15-fachem Token-Faktor liegt der Gesamtverbrauch bei etwa 3 Millionen Token. Der von Anthropic dokumentierte Qualitätsgewinn bei Breiten-Abdeckung beträgt rund 90 Prozent. Die Entscheidungsregel ist damit klar: Lohnt sich der 15-fache Token-Preis für die nahezu verdoppelte Abdeckungsqualität? 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 der 15-fache Faktor und der Breiten-Gewinn aus Anthropics Research-System.)

Ein produktiver DACH-Beleg 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, in Australien 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. Setzen Sie 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.