Multi-Agent-Orchestrierung: Planner-Worker-DAG statt Endlosschleife

Der Reflex ist verständlich: Ein Agent soll eine Aufgabe lösen, also bekommt er alle Werkzeuge, die er dafür theoretisch brauchen könnte — Datenbankzugriff, Mail-Versand, CRM-Update, Rechnungsstellung, Ticketsystem, Kalender, Dateisystem. Am Ende stehen 40 Tools in seiner Toolbox, und die Trefferquote bei der Werkzeugauswahl sinkt spürbar, sobald ein einzelner agentischer Kontext mehr als etwa acht davon gleichzeitig abwägen muss. Das Modell verwechselt ähnlich benannte Funktionen, ruft Tools mit falschen Parametern auf oder bricht Ketten ab, weil der Kontext mit Beschreibungen von Werkzeugen vollläuft, die es in neun von zehn Fällen nicht braucht.

Die Alternative ist unspektakulär und in der Softwarearchitektur seit Jahrzehnten bekannt: Aufgaben zerlegen, Rollen trennen, Verantwortlichkeiten begrenzen. Auf Agenten übertragen heißt das Multi-Agent-Orchestrierung — ein Planner verteilt Teilaufgaben an spezialisierte Worker mit jeweils wenigen, passenden Werkzeugen. Wie das konkret aussieht, welche Muster tatsächlich tragen und wo sie nur Latenz und Tokens kosten, zeigt dieser Artikel anhand eines durchgerechneten Beispiels aus unserer Orchestrierungs-Schicht.

Warum ein Agent mit 40 Werkzeugen schlechter arbeitet als drei mit acht

Jedes zusätzliche Tool in der Toolbox eines Agenten ist nicht nur eine weitere Option, sondern zusätzlicher Kontext, den das Modell bei jeder Entscheidung mitverarbeitet. Bei drei bis fünf Werkzeugen ist die Auswahl fast trivial. Bei 15 beginnt das Modell, semantisch ähnliche Funktionen zu verwechseln — etwa crm.update_contact und crm.update_lead. Bei 40 wird die Auswahl selbst zur Fehlerquelle: Ein Agent verbringt einen Teil seines Denkens damit, überhaupt das richtige Werkzeug zu finden, bevor er die eigentliche Aufgabe löst.

Dazu kommt ein Sicherheitsproblem, das mit der Werkzeugzahl linear wächst: Ein Agent mit 40 Tools braucht in der Praxis auch die Rechte für 40 Tools — Lesezugriff auf Bestellungen, Schreibzugriff auf das CRM, Auslösen von Rückerstattungen, Versand von E-Mails. Ein einziger fehlgeleiteter Lauf, etwa durch Prompt Injection in einem verarbeiteten Dokument, hat dann Zugriff auf deutlich mehr, als die konkrete Anfrage erfordert hätte. Spezialisierte Worker mit engem Tool-Set und eigener, kurzlebiger Agent Identity begrenzen diesen Blast-Radius von vornherein.

Die Kehrseite ehrlich benannt: Mehr Agenten bedeuten mehr Übergabepunkte, und an jedem Übergabepunkt kann Kontext verloren gehen. Multi-Agent-Orchestrierung ist kein Freifahrtschein — sie tauscht ein Problem (Tool-Überladung) gegen ein anderes (Koordinationsaufwand). Die Kunst liegt darin, nur so viele Agenten einzusetzen, wie die Aufgabe tatsächlich an Rollen hergibt.

Vier Muster, die tragen — und wann sie nur Latenz kosten

In der Praxis reichen vier wiederkehrende Muster für die allermeisten Multi-Agent-Prozesse aus. Jedes davon lässt sich auf demselben Ausführungsgraphen abbilden — sie unterscheiden sich in Kontrollfluss, Kosten und Fehlerbild.

Planner-Worker

Ein Planner-Agent zerlegt die Aufgabe in Teilschritte und verteilt sie an spezialisierte Worker — etwa einen für Datenabruf, einen für fachliche Bewertung, einen für die ausführende Aktion. Der Planner führt die Ergebnisse anschließend wieder zusammen. Das Muster trägt, wenn die Teilschritte unterschiedliche Werkzeuge, unterschiedliche Rechte oder unterschiedlich große Modelle brauchen. Es kostet nur zusätzliche Latenz, wenn die Aufgabe eigentlich linear und einstufig ist — dann reicht ein einzelner Agent mit wenigen Tools.

Fan-out/Fan-in

Mehrere identische oder unterschiedliche Worker laufen parallel auf Teilmengen derselben Aufgabe — zum Beispiel eine Analyse über zehn Dokumente gleichzeitig statt nacheinander —, ein Join-Schritt führt die Ergebnisse zusammen. Das Muster trägt bei echter Parallelisierbarkeit und wenn die Gesamtlaufzeit zählt. Es kostet nur unnötig Tokens, wenn die Teilaufgaben voneinander abhängen — dann verursacht Fan-out doppelte Arbeit, weil jeder Zweig ohne die Ergebnisse der anderen startet.

Router

Ein leichtgewichtiger Router-Agent trifft genau eine Entscheidung — welcher von mehreren spezialisierten Agenten die Anfrage übernimmt — und reicht dann vollständig weiter, ohne selbst im Lauf zu bleiben. Das Muster trägt bei klar unterscheidbaren Anfrageklassen, etwa Support-Kategorien mit jeweils eigenem Fachagenten. Es kostet nur einen zusätzlichen Hop, wenn die Klassifikation genauso gut über einen einfachen Regel- oder Klassifikations-Layer vor dem Agenten laufen könnte — nicht jede Weiche braucht ein eigenes LLM.

Reflexion

Ein Agent oder ein zweiter, unabhängiger Prüf-Agent bewertet das eigene Zwischenergebnis, bevor es weiterläuft oder ausgeführt wird — etwa: Ist die vorgeschlagene Rückerstattung durch die Bestelldaten gedeckt? Das Muster trägt bei irreversiblen oder teuren Aktionen, wo ein zusätzlicher Prüfschritt güngstiger ist als ein Fehler danach. Es kostet reine Latenz und Tokens, wenn es auf jeden noch so trivialen Schritt angewendet wird — Reflexion gehört vor die Aktion, nicht vor jeden Zwischenschritt.

Die interaktive Systemkarte unserer Agentic-AI-Plattform zeigt, wie diese vier Muster mit Runtime, Tool-Gateway und Observability zusammenspielen — statt als isolierte Diagramme, sondern als eine durchgängige Ausführungsschicht.

Der Graph statt der Schleife

Viele frühe Agenten-Implementierungen laufen als freie Schleife: Der Agent denkt, ruft ein Tool auf, denkt weiter, ruft das nächste Tool auf — ohne definiertes Ende außer einem pauschalen Iterationslimit. Das Ergebnis sind Läufe, die sich festfahren, sich selbst wiederholen oder erst nach Dutzenden Schritten und entsprechenden Tokenkosten abbrechen.

Ein Directed Acyclic Graph (DAG) löst das strukturell: Er kennt per Definition keine Rückkante zu einem bereits durchlaufenen Knoten. Ein Lauf kann sich verzweigen, parallelisieren und an definierten Stellen auf menschliche Freigabe warten — er kann sich aber nicht endlos im Kreis drehen, weil die Struktur das gar nicht zulässt. Drei Kontrollen je Graph machen daraus einen produktionstauglichen Prozess statt einer Wette auf gutes Modellverhalten:

• Abbruchbedingungen: Jeder Knoten definiert, wann sein Ergebnis als „fertig", „fehlgeschlagen" oder „braucht Freigabe" gilt — statt dass ein übergeordnetes Zeitlimit den Lauf irgendwann einfach beendet.
• Maximale Tiefe: Die Anzahl der Knoten, die ein Lauf durchlaufen darf, ist begrenzt. Wird sie erreicht, greift ein definierter Fallback statt eines stillen Abbruchs.
• Budget je Knoten: Jeder Knoten bekommt ein eigenes Token- und Kostenbudget, nicht nur der Lauf als Ganzes. So verursacht ein einzelner ausufernder Analyse-Schritt keinen unbemerkten Kostenschub im Gesamtprozess.

So sieht ein solcher Graph als Code aus — versioniert im Repository, nicht als Diagramm in einer Oberfläche:

graph = Graph(name="streitfall", budget_eur=0.50, max_depth=6)

retrieval = Agent("retrieval", tools=["orders.query", "policy.search"])
analysis  = Agent("analysis", tools=[], model="gross")   # nur Urteil, kein Tool-Zugriff
action    = Agent("action", tools=["refund.execute", "crm.update"])

graph.edge("start", retrieval)
graph.edge(retrieval, analysis)

# Bis 250 EUR entscheidet der Agent selbst, darüber ein Mensch —
# als Wartezustand, nicht als offene Schleife.
graph.edge(analysis, action, when=lambda s: s.amount <= 250)
graph.edge(analysis, human_approval(queue="finance", ttl_h=24), when=lambda s: s.amount > 250)

Dieses Muster deckt sich mit dem, was wir auch in der Durable-Execution-Runtime beschreiben: Der Lauf existiert als Datensatz, nicht als offener Prozess — ein Neustart des Servers zwischen zwei Knoten ist kein Fehlerfall, sondern ein normaler Zustand, aus dem der Graph genau dort weiterläuft, wo er stand. Wie das im Detail funktioniert, behandelt der Schwester-Artikel zur Durable Execution für KI-Agenten.

A2A: Handoffs an fremde Agenten

Innerhalb der eigenen Organisation ist ein Ausführungsgraph das richtige Werkzeug. Sobald eine Teilaufgabe an einen Agenten außerhalb der eigenen Systemgrenze geht — einen Dienstleister, eine Fachabteilung mit eigener Agenten-Plattform, einen Partnerbetrieb —, braucht es ein Protokoll, das keine gemeinsame interne Architektur voraussetzt. Dafür hat sich A2A (Agent2Agent) etabliert.

A2A ist der horizontale Gegenpart zu MCP: MCP verbindet einen Agenten nach unten mit seinen Werkzeugen, A2A verbindet Agenten untereinander, über Organisationsgrenzen hinweg. Ein Agent beschreibt sich dafür maschinenlesbar über eine Agent Card unter dem standardisierten Pfad /.well-known/agent-card.json — mit Fähigkeiten, Endpunkten und Authentifizierungsverfahren. Signierte Agent Cards sind dabei der Baseline-Schutz gegen gefälschte Registry-Einträge: Sie beweisen die Identität des Betreibers, nicht automatisch die Qualität seines Agenten.

2025 gab es mit A2A und dem konkurrierenden ACP-Protokoll noch eine gewisse Fragmentierung am Markt. Das hat sich inzwischen weitgehend erledigt: A2A steht heute unter neutraler Governance der Linux Foundation, und ACP ist darin aufgegangen. Für Unternehmen bedeutet das weniger Wahlrisiko bei der Protokollentscheidung — mehr dazu in der Architektur-Übersicht unserer Agentic-AI-Plattform.

Human-in-the-Loop als Wartezustand, nicht als Warteschleife

Der häufigste Konstruktionsfehler bei Freigabeprozessen: Der Agent bleibt in einer Schleife stehen und fragt in festen Abständen nach, ob eine Freigabe schon vorliegt. Das kostet Rechenzeit, blockiert eine Prozessinstanz und geht bei jedem Neustart oder Deployment verloren. Im DAG-Modell ist die menschliche Freigabe stattdessen ein eigener Knotentyp: ein Wartezustand mit Frist, kein aktiver Prozess.

Der Lauf existiert in dieser Zeit als Datensatz in der Runtime, nicht als offene Verbindung. Trifft die Freigabe ein, wird genau der wartende Knoten reaktiviert und der Graph läuft weiter. Läuft die Frist — üblicherweise 24 Stunden, je Kante des Graphen konfigurierbar — ohne Reaktion ab, greift ein definierter Fallback, meist eine Eskalation an eine zweite Warteschlange. Praktisch heißt das: Freigaben können Stunden oder Tage dauern, ohne dass in dieser Zeit Rechenzeit oder Tokens verbraucht werden. Wie diese Wartezustände technisch abgesichert sind und welche Eskalationsmuster sich bewährt haben, vertieft der Schwester-Artikel Human-in-the-Loop: Freigaben und Limits.

Praxisbeispiel: Streitfall-Bearbeitung in 2,4 Sekunden

Ein Kunde bestreitet eine Abbuchung über 180 Euro. Statt eines einzelnen Agenten mit Zugriff auf Bestellsystem, Zahlungsdienstleister und CRM gleichzeitig läuft die Anfrage durch einen Planner-Worker-Graphen mit drei spezialisierten Agenten:

• Retrieval-Worker: ruft Bestelldaten und die einschlägige Richtlinie ab — drei Tool-Calls, nur Lesezugriff (read:orders), rund 0,9 Sekunden.
• Analysis-Worker: bewertet den Fall auf einem größeren Modell, ohne eigenen Tool-Zugriff — reines Urteilsvermögen, rund 0,7 Sekunden.
• Action-Worker: löst bei einem Betrag unter dem definierten Schwellenwert von 250 Euro die Rückerstattung aus und aktualisiert den CRM-Datensatz — zwei Tool-Calls mit eigenem Schreibrecht (write:refund), rund 0,5 Sekunden.

Dazu kommen zwei Tool-Calls des Planners für Routing und Zusammenführung sowie rund 0,3 Sekunden Koordinations-Overhead. Macht in Summe sieben Tool-Calls und 2,4 Sekunden Gesamtlaufzeit für einen Fall, der ohne definierten Schwellenwert an einen Menschen gegangen wäre.

Läge der Streitwert über 250 Euro, würde derselbe Graph statt des Action-Workers einen Freigabe-Knoten ansteuern — mit 24 Stunden Frist, ohne dass der Lauf in dieser Zeit etwas kostet. Denselben Aufbau, angewendet auf einen komplexeren operativen Fall mit mehreren Eskalationsstufen, zeigt der Anwendungsfall Incident Response in unserer Plattform, inklusive vollständiger Trace-Auswertung je Knoten.

Vergleich: Einzelagent, Planner-Worker, fest verdrahteter Workflow

Keines der drei Modelle ist grundsätzlich überlegen — die Wahl hängt davon ab, wie variabel die Aufgabe ist und wie viel Kontrolle Sie über den Ablauf brauchen.

Wann sich Multi-Agent-Orchestrierung NICHT lohnt

Ehrlich: Die meisten Mittelständler, die uns nach Multi-Agent-Architekturen fragen, brauchen zunächst gar keine. Ein Agenten-Graph mit Planner, mehreren Workern und Freigabepfaden lohnt sich erst, wenn mindestens einer dieser Punkte zutrifft:

• Echte Parallelität fehlt: Läuft die Aufgabe ohnehin sequenziell ab, bringt Fan-out nichts außer zusätzlicher Komplexität.
• Keine Rollentrennung nötig: Braucht jeder Schritt dieselben Rechte und dieselbe Modellgröße, ist ein einzelner Agent mit wenigen Tools schneller und günstiger zu betreiben.
• Geringes Volumen: Bei wenigen Läufen pro Tag rechtfertigt sich der Betriebsaufwand für Graph, Observability je Knoten und Freigabe-Infrastruktur oft nicht.
• Unklare Erfolgskriterien: Ohne klar definierte Abbruch- und Freigabebedingungen wird aus dem DAG schnell wieder eine freie Schleife mit mehr Beteiligten.

Und selbst wenn Multi-Agent-Orchestrierung angebracht ist: Ab etwa sieben Sub-Agenten haben wir in Projekten regelmäßig erlebt, dass sich Fehler nicht mehr aus einem einzelnen Schritt erklären lassen, sondern erst aus der Übergabe zwischen zweien. Mehr Agenten sind kein Selbstzweck — jeder zusätzliche Knoten muss einen konkreten Grund haben. Eine realistische Einordnung der laufenden Kosten je Sub-Agent liefert außerdem unser Schwester-Artikel zu Preismodellen für Agentic-AI-Betrieb sowie die Betriebspauschalen ab 690 Euro monatlich für den Einstiegsbetrieb.

So planen Sie Ihren ersten Agenten-Graphen

Der Einstieg gelingt am ehesten mit einem eng begrenzten, aber wiederkehrenden Prozess — nicht mit dem komplexesten Fall im Unternehmen. Vier Schritte, die sich in unseren Workshops bewährt haben:

• 1. Rollen statt Werkzeuge zuerst festlegen: Welche Teilschritte brauchen unterschiedliche Daten, unterschiedliche Rechte oder unterschiedliche Modellgrößen? Daraus ergeben sich die Sub-Agenten — nicht umgekehrt.
• 2. Abbruch- und Freigabebedingungen zuerst, Logik danach: Legen Sie fest, wann ein Lauf als erledigt, fehlgeschlagen oder freigabepflichtig gilt, bevor Sie den ersten Prompt schreiben.
• 3. Mit einem Muster starten, nicht mit vieren: Ein einfacher Planner-Worker-Graph mit zwei bis drei Knoten reicht für den ersten Produktivlauf. Fan-out, Router und A2A-Föderation kommen dazu, wenn der Bedarf real entsteht.
• 4. Rechte kurzlebig ausstellen, nicht vererben: Jeder Sub-Agent bekommt beim Start eigene, befristete Credentials mit genau den Scopes seiner Teilaufgabe — Details dazu im On-Premise-Betrieb unter KI On-Premise oder als vollständig verwalteter Stack über KI Full-Stack-Providing.

Wer den gesamten Kontext von der Systemintegration bis zur Absicherung gegen Schatten-KI sucht, findet ihn in den Artikeln zur Agentic-AI-Systemintegration und zu KI-Agenten-Sicherheit. Wie sich die einzelnen Knoten eines Graphen anschließend nachvollziehen lassen — bis auf den einzelnen Tool-Call —, behandelt der Schwester-Artikel Observability für KI-Agenten.

Häufige Fragen zur Multi-Agent-Orchestrierung

Wann lohnt sich ein Multi-Agent-System gegenüber einem einzelnen Agenten?

Wenn Teilaufgaben unterschiedliche Rechte brauchen, unterschiedliche Modellgrößen rechtfertigen oder echt parallel laufen können. Als Faustregel: Erst aufteilen, wenn ein einzelner Agent mehr als acht Werkzeuge bräuchte oder die Aufgabe klar in Rollen zerfällt. Reines Aufteilen ohne diesen Grund kostet nur Latenz und Tokens.

Was ist der Unterschied zwischen einem Router und einem Planner?

Ein Router trifft genau eine Entscheidung — welcher von mehreren spezialisierten Agenten die Anfrage übernimmt — und reicht dann komplett weiter. Ein Planner bleibt im Lauf, zerlegt die Aufgabe in mehrere Schritte und führt die Ergebnisse mehrerer Worker wieder zusammen. Der Router ist ein einzelner Sprung, der Planner koordiniert einen ganzen Graphen.

Wie verhindere ich, dass ein Agenten-Graph endlos weiterläuft?

Über drei harte Grenzen je Lauf: eine maximale Graphtiefe, ein Tokenbudget je Knoten und eine Gesamtabbruchbedingung mit definiertem Fallback. Ein DAG kennt per Definition keine Rückkante zu sich selbst — anders als eine freie Schleife kann er sich nicht endlos wiederholen, nur an klar benannten Stellen verzweigen.

Was passiert, wenn ein A2A-Handoff an einen fremden Agenten fehlschlägt oder nicht antwortet?

Der Handoff bekommt beim Aufsetzen eine Frist. Läuft sie ab, greift der im Graphen definierte Fallback — üblicherweise Bearbeitung im eigenen Haus oder Eskalation an einen Menschen. Der Lauf bleibt in der Zwischenzeit im Wartezustand und verbraucht keine Rechenzeit.

Wie viele Sub-Agenten sind sinnvoll, bevor die Koordination zum Problem wird?

In der Praxis bewähren sich drei bis sieben spezialisierte Sub-Agenten je Prozess. Darüber steigt der Koordinationsaufwand schneller als der Nutzen: Mehr Übergabepunkte bedeuten mehr Stellen, an denen Kontext verloren geht, und Fehler lassen sich oft nicht mehr aus einem einzelnen Schritt erklären, sondern erst aus der Übergabe zwischen zweien.

Lohnt sich Multi-Agent-Orchestrierung schon für kleine Unternehmen?

Nur, wenn der zugrunde liegende Prozess tatsächlich mehrere Rollen mit unterschiedlichen Rechten oder echte Parallelität hat. Für einen einzelnen, klar umrissenen Anwendungsfall reicht meist ein Agent mit wenigen Werkzeugen — der zusätzliche Betrieb eines Graphen lohnt sich erst, wenn dadurch tatsächlich Fehlerquote oder Durchlaufzeit sinken.