Kern des Patterns
Orchestrator Agent ist ein Pattern, bei dem ein Agent die Arbeit mehrerer Ausfuehrer koordiniert: Aufgabe aufteilen, Teilaufgaben delegieren, Status verfolgen und Ergebnisse zusammenfuehren.
Wann sinnvoll: wenn eine grosse Aufgabe auf mehrere Ausfuehrer verteilt und zu einem Ergebnis zusammengefuehrt werden muss.
Statt dass ein Agent alles allein macht, uebernimmt der Orchestrator:
- Analyse des Gesamtziels
- Aufteilung in Teilaufgaben
- Weitergabe der Teilaufgaben an passende Agenten
- Zusammenfuehrung der Antworten zu einem Ergebnis
Problem
Stell dir vor, es soll ein Go-to-Market-Launch vorbereitet werden.
Das ist keine einzelne Aktion, sondern mehrere parallele Arbeitsstroeme:
- Content und Positionierung
- Analytics und Forecast
- juristische Pruefung
- finaler Release-Plan
Wenn ein Agent alles sequenziell bearbeitet, wird das System "an einer Stelle eng".
Ohne Orchestrierung verliert eine mehrstufige Aufgabe an Geschwindigkeit und wird anfaellig fuer lokale Ausfaelle.
Als Ergebnis:
- der Prozess wird durch serielle Ausfuehrung langsamer
- die Kosten steigen durch zusaetzliche Last auf die Execution-Runtime
- ein Ausfall eines Schritts blockiert die gesamte Aufgabe
- Timeouts, Retries und Deadlines sind schwer stabil zu halten
Genau darin liegt das Problem: ohne Koordination mehrerer Ausfuehrer wird eine komplexe Aufgabe langsam, teuer und schwer steuerbar.
Loesung
Orchestrator fuegt eine Koordinationsschicht (coordination layer) fuer die Steuerung mehrerer Ausfuehrer hinzu.
Analogie: Das ist wie ein Projektleiter. Er erledigt nicht alle Aufgaben selbst, sondern koordiniert Team, Reihenfolge und Abhaengigkeiten. So werden Verzoegerungen und Konflikte zwischen Schritten reduziert.
Schluesselprinzip: zuerst Koordination von Teilaufgaben und Abhaengigkeiten, danach Ausfuehrung.
Einzelne Agenten erledigen Teilaufgaben, waehrend orchestrator-policy die Regeln festlegt:
- was parallel gestartet wird
- was sequentiell abgewartet wird
- wie
timeout/retry/fallbackbehandelt wird - wann ein Ergebnis als fertig gilt
Gesteuerter Prozess:
- Planung (Plan): Goal in Teilaufgaben und Abhaengigkeiten aufteilen
- Zuweisung (Dispatch): Ausfuehrer und Limits zuweisen
- Parallele Ausfuehrung (Parallel Execute): unabhaengige Schritte gleichzeitig starten
- Aggregation (Aggregate): Ergebnisse von Ausfuehrern sammeln
- Pruefung und Finale (Validate/Done): finales Output pruefen und abschliessen
Monitoring (retries, timeouts, Status) laeuft waehrend der Ausfuehrung.
Das bringt:
- geringere Gesamtausfuehrungszeit
- Kontrolle partieller Ausfaelle (partial failures)
- zentrale Limits und Regeln
- konsistentes finales Ergebnis
Funktioniert gut, wenn:
- der Plan explizite Abhaengigkeiten hat
- fuer Ausfuehrer timeout/budget Grenzen gesetzt sind
- es eine Policy fuer
retry/fallback/partial resultgibt - die Aggregation Vollstaendigkeit und Konsistenz prueft
Das Modell kann "wollen", alles auf einmal oder alles nacheinander zu starten, aber orchestrator-policy legt die korrekte Reihenfolge und Grenzen fest.
Wie es funktioniert
Orchestrator fuehrt Teilaufgaben nicht selbst aus.
Er steuert den Prozess:
- wem jede Teilaufgabe zugewiesen wird
- welche Zeit- oder Budgetlimits gelten
- wann ein fehlgeschlagener Schritt neu gestartet wird
- wann der Gesamtprozess abgeschlossen ist
Beschreibung des gesamten Ablaufs: Plan → Dispatch → Parallel Execute → Aggregate
Planung (Plan)
Der Agent erstellt einen Plan: welche Teilaufgaben benoetigt werden, welche Abhaengigkeiten bestehen und was parallel laufen kann.
Zuweisung (Dispatch)
Das System uebergibt Teilaufgaben an passende Agenten oder Services.
Parallele Ausfuehrung (Parallel Execute)
Jeder Ausfuehrer bearbeitet seinen Teil ueber den eigenen Zyklus Think → Act → Observe.
Aggregation (Aggregate)
Orchestrator sammelt Ergebnisse, prueft Vollstaendigkeit und bildet die finale Antwort.
Im Code sieht das so aus
plan = plan_tasks(goal)
jobs = [dispatch_async(worker, task) for worker, task in plan] # parallele Teilaufgaben starten
results = await gather_with_limits(jobs, timeout_sec=30) # mit timeout/limit Policies sammeln
results = retry_timeouts_once(results) # einfaches Beispiel: ein Retry bei Timeout
final = aggregate(results)
return final
Orchestrator startet Teilaufgaben parallel und wartet mit Timeouts und Limits auf Ergebnisse.
So sieht das waehrend der Ausfuehrung aus
Goal: Go-to-Market-Plan vorbereiten
Plan:
- Agent A: Markt und Wettbewerber
- Agent B: Finanzmodell
- Agent C: Risiken und Compliance
Dispatch: alle drei Teilaufgaben starten parallel
Observe:
- Agent A: fertig in 6 s
- Agent B: fertig in 9 s
- Agent C: timeout, Neustart
- Agent C: fertig in 5 s nach Retry
- Zwischen Schritten: Ergebnisse nach Retry gehen zurueck in den gemeinsamen Satz fuer aggregate
Aggregate:
- A + B + C gesammelt (C nach Retry)
- Fehler-Policy angewendet
- ein einheitliches Dokument erzeugt
Vollstaendiges Orchestrator-Agent-Beispiel
Wann es passt - und wann nicht
Passt
| Situation | Warum Orchestrator passt | |
|---|---|---|
| ✅ | Die Aufgabe laesst sich in mehrere unabhaengige Teile zerlegen | Orchestrator verteilt Teilaufgaben auf Ausfuehrer und koordiniert sie parallel. |
| ✅ | Es ist wichtig, Zeit durch parallele Ausfuehrung zu sparen | Gleichzeitiger Start von Teilaufgaben reduziert die gesamte Wartezeit auf das Ergebnis. |
| ✅ | Unterschiedliche spezialisierte Agenten werden benoetigt | Jeder Agent bekommt seine Rolle, und Orchestrator synchronisiert ihre Arbeit. |
| ✅ | Kontrolle von Timeouts, Retries und Aggregation ist erforderlich | Das Pattern fuegt Ausfuehrungssteuerung und einen zentralen Sammelpunkt fuer das finale Ergebnis hinzu. |
Passt nicht
| Situation | Warum Orchestrator nicht passt | |
|---|---|---|
| ❌ | Die Aufgabe ist klein und einstufig | Die Koordinationsschicht verursacht Overhead, wo ein Ausfuehrer ausreicht. |
| ❌ | Alle Schritte sind strikt sequenziell | Wenn Parallelitaet unmoeglich ist, bringt Orchestrierung kaum Gewinn. |
| ❌ | Die Infrastruktur unterstuetzt keine stabile Parallelitaet | Ohne stabile Ausfuehrung, Retries und Zustandskontrolle wird Orchestrierung fragil. |
Denn Orchestrator fuegt zusaetzliche Koordination hinzu: Aufgabenqueues, Warten auf Ergebnisse und Zusammenfuehren von Antworten.
Unterschied zu Routing
| Routing | Orchestrator | |
|---|---|---|
| Was es entscheidet | Wem die Aufgabe gegeben wird | Wie mehrere Ausfuehrer gesteuert werden |
| Aktive Agenten | Meist einer | Mehrere gleichzeitig |
| Fokus | Klassifikation und Uebergabe | Koordination, Timing und Ergebniszusammenfuehrung |
| Output | Aufgabe an Ausfuehrer uebergeben | Finales zusammengefuehrtes Ergebnis |
Routing beantwortet: "wem die Aufgabe geben".
Orchestrator beantwortet: "wie mehrere Aufgaben synchronisiert und Ergebnisse zusammengefuehrt werden".
Wann Orchestrator verwenden (vs andere Patterns)
Verwende Orchestrator, wenn mehrere abhaengige Schritte existieren und die richtige Reihenfolge wichtig ist.
Kurzer Test:
- wenn du "eine Aufgabe durch eine klare Schrittkette fuehren" musst -> Orchestrator
- wenn du "nur den Ausfuehrer fuer eine Anfrage waehlen" musst -> Routing Agent
Vergleich mit anderen Patterns und Beispiele
Schnelluebersicht:
| Wenn die Aufgabe so aussieht... | Verwende |
|---|---|
| Es muss ein einzelner bester Ausfuehrer gewaehlt werden | Routing Agent |
| Es gibt eine Schrittfolge, und die Reihenfolge ist wichtig | Orchestrator Agent |
| Es wird ein Policy-Check vor dem Ergebnis gebraucht | Supervisor Agent |
| Mehrere Agenten muessen zu einem gemeinsamen Ergebnis kommen | Multi-Agent Collaboration |
Beispiele:
Routing: "Kunde will eine Rueckerstattung - an Billing schicken, nicht an Sales".
Orchestrator: "Bereite ein Release vor: zuerst Changelog, dann QA, dann Deploy".
Supervisor: "Vor dem Senden einer E-Mail Policies, Compliance und verbotene Versprechen pruefen".
Multi-Agent Collaboration: "Marketing, Legal und Product muessen einen finalen Kampagnentext abstimmen".
Wie man es mit anderen Patterns kombiniert
- Orchestrator + Routing — Routing waehlt den Ausfuehrer fuer die Teilaufgabe, waehrend Orchestrator den Gesamtfluss ueberwacht.
- Orchestrator + ReAct — jeder Agent bearbeitet seinen Teil Schritt fuer Schritt, waehrend Orchestrator alles in einen Plan zusammenfuehrt.
- Orchestrator + Supervisor — vor kritischen Aktionen werden Policies, Risiken und Ausfuehrungsbudget geprueft.
Kurz gesagt
Orchestrator Agent:
- plant Teilaufgaben
- delegiert sie an Ausfuehrer
- steuert parallele Ausfuehrung
- sammelt das finale Ergebnis
Vorteile und Nachteile
Vorteile
steuert den gesamten Prozess zentral
verteilt Aufgaben klar auf Ausfuehrer
kontrolliert Reihenfolge und Prioritaeten besser
Fortschritt ist gut ueberwachbar
Nachteile
wird zum kritischen Punkt des Systems
Routing-Konfiguration kann komplex sein
ein Fehler im Orchestrator betrifft den gesamten Ablauf
FAQ
Q: Startet Orchestrator Teilaufgaben immer parallel?
A: Nein. Manche Schritte koennen sequenziell laufen, wenn Abhaengigkeiten dazwischen bestehen.
Q: Was tun, wenn ein Agent kein Ergebnis zurueckgibt?
A: Es wird eine Fehler-Policy gesetzt: retry, timeout, fallback oder partial result. Orchestrator wendet diese Policy vor der finalen Aggregation an.
Q: Braucht man Orchestrator, wenn Routing schon da ist?
A: Routing waehlt einen Ausfuehrer. Orchestrator koordiniert viele Ausfuehrer und nutzt Routing oft innerhalb einzelner Teilaufgaben.
Was als Naechstes
Orchestrator koordiniert die Arbeit mehrerer Agenten gleichzeitig.
Aber wer stellt sicher, dass dabei Policies, Budget und Sicherheitsregeln eingehalten werden?