Orchestrator-Agent

Was ist Orchestrator-Agent?

Ein Orchestrator-Agent ist der Lead-Agent in einem Multi-Agenten-System. Er erhält das Gesamtziel, zerlegt es in Teilaufgaben, delegiert jede an Worker-Agenten mit dem Kontext, den sie brauchen, bewertet, was zurückkommt, und setzt die Teile zu einem finalen Ergebnis zusammen. Er trifft Koordinationsentscheidungen, statt die fachliche Arbeit selbst zu erledigen.

Die wichtigsten Punkte

• Die eigentliche Aufgabe des Orchestrators ist Zerlegung und Kontext-Verpackung. Wie gut er jede Teilaufgabe abgrenzt und briefft, bestimmt die Qualität von allem stromabwärts.
• Er sollte selten selbst fachliche Arbeit erledigen. Seinen Kontext für Koordinationsentscheidungen sauber zu halten, ist der Sinn der Rolle.
• Der Orchestrator ist der natürliche Kontrollpunkt: Budgets, Schritt-Limits und menschliche Freigabe-Gates docken alle am günstigsten genau hier an.
• Er ist meist der teuerste Sitzplatz im System, da er den am längsten laufenden Kontext hält, weshalb Teams oft Worker auf günstigeren Modellen laufen lassen, während der Orchestrator das stärkste nutzt.

So funktioniert es

Die Schleife beginnt, wenn der Orchestrator ein Ziel erhält. Er plant eine Zerlegung und versendet dann Teilaufgaben durch Agent-Orchestrierungs-Maschinerie, typischerweise indem er pro Aufgabe einen Subagenten mit einem schriftlichen Briefing erzeugt: das Ziel, den relevanten Kontext, die erlaubten Tools und das erwartete Output-Format. Worker laufen in ihren eigenen Context Windows und liefern Ergebnisse zurück, nicht Transkripte, was verhindert, dass der Kontext des Orchestrators mit Zwischenrauschen überflutet wird. Anthropics Forschungssystem funktioniert so, wobei der Lead-Agent 3 bis 5 Subagenten parallel erzeugt, und das Parallelisieren von Subagenten plus Tool-Aufrufen senkte die Rechercheit um bis zu 90 % bei komplexen Anfragen [1].

Während Ergebnisse eintreffen, beurteilt der Orchestrator sie. Ist die Recherche vollständig? Erfüllt der Entwurf die Spezifikation? Er kann Arbeit mit Feedback zurücksenden, eine neue Teilaufgabe versenden, um eine Lücke zu füllen, oder entscheiden, dass das Ziel erreicht ist, und alles in das Liefergut zusammenführen. Gut gebaute Orchestratoren wissen auch, wann sie stoppen sollen: Schritt-Obergrenzen, Token-Budgets und Eskalationsregeln verhindern die endlosen Retry-Schleifen, die naive Implementierungen plagen. Budgets verdienen echte Aufmerksamkeit, weil Tokens die Qualität eng verfolgen: In Anthropics BrowseComp-Evaluation erklärte Token-Nutzung allein 80 % der Leistungsvarianz, und das Hinzufügen von Tool-Aufruf-Anzahl und Modellwahl trieb das auf 95 % [2]. Weil jede Entscheidung durch diesen einen Agenten läuft, ist er der Ort, an dem Teams Human-in-the-Loop-Review für irreversible Aktionen ansetzen.

Der Fehlermodus, gegen den man engineeren muss, ist das verlustbehaftete Briefing. Ein Worker weiß nur, was der Orchestrator weitergibt, sodass ein vages Briefing selbstbewusste Arbeit am falschen Problem produziert. Ausgereifte Systeme machen Briefings strukturiert und explizit, näher an einer kurzen Spezifikation als an einer Chat-Nachricht.

Beispiel

Eine Beratung betreibt einen Due-Diligence-Assistenten zur Bewertung von Akquisitionszielen. Gegeben einen Firmennamen und einen Datenraum-Ordner, plant der Orchestrator vier Arbeitsströme: Finanzen, Verträge, Technologie und Marktposition. Er erzeugt einen Worker für jeden, brieft den Vertrags-Agenten mit der Dokumentenliste und einer Checkliste zu markierender Klauseln, und den Markt-Agenten mit dem Sektor und den Wettbewerbern des Unternehmens. Der Vertrags-Worker kehrt mit zwei markierten Change-of-Control-Klauseln zurück, merkt aber an, dass er ein gescanntes PDF nicht parsen konnte; der Orchestrator versendet eine Folgeaufgabe mit einem OCR-Tool und faltet dann das Ergebnis ein. Schließlich führt er die vier Berichte zusammen, löst eine Uneinigkeit zwischen der Finanz- und der Marktanalyse auf, indem er beide Worker eine klärende Frage stellt, und produziert ein einziges Memo mit einem Anhang offener Risiken für das menschliche Deal-Team.

Häufige Missverständnisse

Menschen nehmen an, der Orchestrator müsse das denkbar klügste Modell sein, das tiefes Reasoning über jede Teilaufgabe betreibt. In der Praxis kommt sein Hebel aus disziplinierter Delegation, und ein übergreifender Orchestrator ist eine Belastung: Wenn er anfängt, fachliche Arbeit inline zu erledigen, füllt sich sein Kontext mit Detail, sein Koordinationsurteil verschlechtert sich, und das System kollabiert still zurück zu einem überlasteten Agenten mit zusätzlichem Overhead. Grenzen Sie den Orchestrator auf Planen, Briefen, Beurteilen und Zusammenführen ein, und schieben Sie die eigentliche Arbeit zu den Workern.

Planner-Agenten

Ein Planner-Agent ist die reduzierte Form eines Orchestrators: Er produziert die Aufgabenzerlegung und Reihenfolge, verwaltet aber nicht die Ausführung. Der Plan geht an einen deterministischen Executor oder an die Person, die die Aufgabe gestartet hat, was attraktiv ist, wenn Sie den Plan geprüft haben möchten, bevor irgendetwas läuft. Coding-Tools nutzen diese Form ständig und generieren einen Plan zur Freigabe, bevor Änderungen beginnen, im Geiste der spezifikationsgetriebenen Entwicklung. Die Grenze zwischen den beiden Rollen ist Aufsicht: Ein Planner übergibt einen Plan und ist fertig, während ein Orchestrator in der Schleife bleibt, auf Ergebnisse reagiert und neu plant, während die Realität von der ursprünglichen Zerlegung abweicht. Viele Systeme beginnen mit einem Planner plus skriptgesteuerter Ausführung und wachsen erst dann zu voller Orchestrierung, wenn sich Aufgaben als zu unvorhersehbar für einen statischen Plan erweisen.

FAQ

Braucht jedes Multi-Agenten-System einen Orchestrator-Agenten? Nein. Pipeline- und Choreografie-Designs lassen Agenten Arbeit direkt an die nächste Stufe unter deterministischem Routing übergeben, ganz ohne Lead-Agent. Orchestratoren rechtfertigen ihre Kosten, wenn Zerlegung oder Routing echt Urteilsvermögen zur Laufzeit erfordern.

Können Orchestrator und Worker unterschiedliche Modelle nutzen? Ja, und meist sollten sie es. Ein übliches Setup setzt das stärkste Modell auf den Orchestrator-Platz, wo Urteilsvermögen am meisten zählt, und lässt hochvolumige Worker-Aufgaben auf kleineren, günstigeren, pro Aufgabe gewählten Modellen laufen. Anthropics Version davon, Claude Opus 4 als Lead über Claude-Sonnet-4-Subagenten, übertraf den Einzelagenten Claude Opus 4 2025 in einem internen Forschungs-Eval um 90,2 % [3].

Wie unterscheidet sich ein Orchestrator von einer Workflow-Engine? Eine Workflow-Engine führt Routing aus, das zur Designzeit entschieden wurde. Ein Orchestrator-Agent entscheidet das Routing zur Laufzeit, indem er über das Ziel und Zwischenergebnisse reasont. Viele Produktionssysteme schichten beides: eine Workflow-Engine handhabt das stabile Skelett, ein Orchestrator die mehrdeutige Mitte.

Quellen

1. Anthropic. "Lead-Forschungsagent erzeugt 3-5 parallele Subagenten; Parallelisierung senkte die Rechercheit um bis zu 90 %." https://www.anthropic.com/engineering/built-multi-agent-research-system. Abgerufen im August 2026.
2. Anthropic. "Token-Nutzung erklärt 80 % der Leistungsvarianz bei BrowseComp; mit Tool-Aufrufen und Modellwahl, 95 %." https://www.anthropic.com/engineering/built-multi-agent-research-system. Abgerufen im August 2026.
3. Anthropic. "Claude-Opus-4-Orchestrator mit Claude-Sonnet-4-Subagenten übertraf den Einzelagenten Claude Opus 4 um 90,2 %." https://www.anthropic.com/engineering/built-multi-agent-research-system. Abgerufen im August 2026.