Agent Orchestration

Agent Orchestration ist die Regie-Ebene über mehreren KI-Agenten (eigenständig arbeitenden KI-Programmen). Sie legt fest, welcher Agent wann welche Aufgabe übernimmt, in welcher Reihenfolge die Schritte laufen, auf welche gemeinsamen Daten alle zugreifen dürfen und was passiert, wenn ein Schritt fehlschlägt. Damit sitzt sie zwischen einem einzelnen Agenten und einem Verbund mehrerer Agenten (Multi-Agent-System) und wird über vier Bausteine beschrieben: Plan (wer denkt vorher nach), Topologie (wer spricht mit wem), Routing (wer übernimmt als Nächstes) und geteilter Zustand (was wissen alle).

Was ist Agent Orchestration?

Sobald mehr als ein Agent beteiligt ist oder eine Aufgabe in mehreren Schritten mit unterschiedlichen Werkzeugen läuft, entstehen Koordinationsfragen, die weder das Sprachmodell (der Textgenerator wie GPT oder Claude) noch die Programmier-Bibliothek für einen einzelnen Agenten von allein beantwortet. Wer legt die Reihenfolge fest? Welcher Agent übernimmt einen bestimmten Schritt? Wo liegen die gemeinsamen Daten, auf die alle Agenten zugreifen? Was passiert, wenn ein Schritt fehlschlägt? Diese Fragen bündelt Agent Orchestration als eigene Ebene.

Der begriffliche Rahmen stammt aus dem Compound-AI-Systems-Frame, den das Berkeley AI Research Lab 2024 geprägt hat: eine agentische Anwendung ist eine Komposition aus Modellen, Werkzeugen und Programmen, die zusammen ein Ziel verfolgen. Orchestration ist die Regie, die diese Bestandteile zusammenhält.

Vier Bausteine tragen die Orchestrierung:

• Plan-Phase. Legt fest, ob es vor der Ausführung einen Plan gibt und wie er entsteht. Vier Varianten dominieren das Feld: kein Plan (reaktive ReAct-Schleife), statischer Plan (hartverdrahteter Workflow), LLM-generierter Plan (Plan-and-Execute, ReWOO) und iterativer Plan (Plan-Reflect-Replan).
• Topologie. Definiert die Beziehungen zwischen den Agenten. Häufige Formen sind Supervisor/Worker mit einem koordinierenden Agenten und mehreren spezialisierten Ausführern, hierarchische Baumstrukturen, Peer-to-Peer-Netzwerke ohne zentrale Instanz und Broadcast-Muster.
• Routing-Layer. Steuert die Übergabe zwischen Agenten. Die Entscheidung „welcher Agent macht als Nächstes was" kann regelbasiert, als LLM-Klassifikation, über ein kleines dediziertes Router-Modell oder implizit im Supervisor-Prompt fallen.
• State-Modell. Beschreibt den gemeinsamen Zustand: welche Felder alle Agenten lesen, welche nur ein bestimmter Agent schreiben darf, wie der Zustand zwischen Schritten persistiert wird und wie Konflikte bei parallelen Schreibzugriffen aufgelöst werden.

Frameworks wie LangGraph, CrewAI, das Microsoft Agent Framework (AutoGen und Semantic Kernel unter einem Dach, GA April 2026), das OpenAI Agents SDK, das Claude Agent SDK und das Google ADK bringen für diese vier Bausteine eigene Abstraktionen mit. LangGraph macht die Topologie als Graph explizit, CrewAI arbeitet rollenbasiert mit Team-Metaphern, das OpenAI Agents SDK setzt auf Handoffs zwischen Agenten mit gemeinsamer Nachrichtenliste.

Abgrenzung zu Framework, Routing, Workflow und Multi-Agent-System

Der Begriff wird in der Diskussion häufig mit angrenzenden Ebenen des Agenten-Stacks vermischt. Die Unterschiede:

Ein Framework kann Orchestrierungs-Funktionen enthalten, bleibt aber primär die Bau-Ebene für den einzelnen Agenten. Routing ist eine Entscheidung innerhalb der Orchestration, eine ihrer Komponenten. Eine klassische Workflow-Engine steuert deterministische Abläufe; Agent Orchestration muss zusätzlich damit umgehen, dass ein Agent die Schrittanzahl selbst festlegt, Werkzeuge auswählt und den Plan bei Bedarf revidiert.

Zwei weitere Verwechslungen tauchen in der Literatur auf. Agentic Workflows meinen Workflow-Muster, in denen Agenten in vorher definierten Schritten arbeiten (Prompt-Chaining, Router-Pattern, Parallelisierung, Orchestrator-Worker); der Begriff geht auf Anthropic zurück und beschreibt eine Familie, aus der Orchestration schöpft. Agentic Orchestration wird häufig als Marketing-Variante desselben Begriffs verwendet und meint in der Regel dasselbe wie Agent Orchestration, mit stärkerem Fokus auf Autonomie und Prozess-Automatisierung.

Beispiel: Kundenservice-System mit drei Agenten

Ein Kundenservice-System bearbeitet eingehende Tickets über eine Ketten-Architektur aus drei Agenten: einem Klassifikator (Intent-Erkennung, Prioritätsstufe), einem Sachbearbeiter (Bestellstatus, Refund, Reklamation) und einem Eskalations-Agenten (menschliche Übergabe bei unklaren Fällen).

Die vier Orchestrierungs-Entscheidungen sehen so aus:

• Plan-Phase: Plan-and-Execute für Fälle mit klar zerlegbaren Schritten (Bestellstatus abrufen, Rechnung prüfen, Refund auslösen). Für offene Beschwerden ohne klare Struktur läuft der Sachbearbeiter reaktiv (ReAct) mit einem max-Step-Limit.
• Topologie: Supervisor/Worker. Ein Supervisor-Agent ruft nach der Klassifikation den passenden Worker auf und aggregiert Ergebnisse.
• Routing-Layer: eine eigene Komponente mit einem kleinen Klassifikator-Modell außerhalb des Supervisor-Prompts. Prompt-basiertes Routing entgleist bei Volumen und ist im Tracing schwer nachvollziehbar.
• State-Modell: ein geteiltes State-Objekt (Ticket-ID, Kunde, Klassifikations-Ergebnis, bisherige Werkzeug-Aufrufe, Zwischensummen), auf das alle drei Agenten lesen dürfen, aber nur ein Agent pro Feld schreibt.

Tracing pro Schritt (LangSmith, Langfuse, Arize Phoenix) ist ab dem ersten Prototyp verdrahtet, weil das Verhalten des Systems ab dem dritten Schritt sonst intransparent bleibt. Kostenüberwachung ist Teil der Orchestrierung, nicht Add-on: jeder LLM-Aufruf zählt, jede zusätzliche Reflexion kostet Tokens, und eine schlecht abgestimmte Plan-Phase kann die Token-Kosten pro Fall verdrei- oder vervierfachen.