Supervisor-Pattern: Einen Agenten zum Boss machen

Das Supervisor-Pattern ist eine Multi-Agent-Architektur, bei der ein zentraler Supervisor-Agent entscheidet, welcher spezialisierte Sub-Agent als Nächstes handelt. Der Supervisor empfängt die Anfrage, routet sie an passende Worker-Agents, sammelt deren Ergebnisse und steuert den Ablauf, bis die Aufgabe gelöst ist. Er denkt nicht selbst fachlich, sondern delegiert und koordiniert. Damit wird ein Agent buchstäblich zum Boss über ein Team aus Spezialisten.

Schnellantworten:

• Was tut der Supervisor? Er routet zwischen Sub-Agents und entscheidet nach jedem Schritt, wer dran ist. Die Sub-Agents reden nicht direkt miteinander.
• Womit baut man es? Stand 2026 mit LangGraph 1.0 (Open Source), auf AWS mit eigenem Framework-Code in der Runtime von Amazon Bedrock AgentCore; A2A für Cross-Vendor, MCP für Tools.
• Wann passt es? Bei parallelisierbaren, gering gekoppelten Aufgaben mit klarer fachlicher Zerlegung, nicht bei eng gekoppelten Schreib-Workflows wie Code-Generierung.

Wie das Supervisor-Pattern funktioniert

Der Grundgedanke ist eine sternförmige Topologie (Hub-and-Spoke): In der Mitte sitzt der Supervisor, außen die spezialisierten Worker-Agents. Jeder Worker hat seinen eigenen Prompt, sein eigenes Tool-Set und oft sein eigenes Kontextfenster. Der entscheidende Punkt: Die Worker kommunizieren nicht untereinander, sondern ausschließlich über den Supervisor. Dieser entscheidet nach jedem Zwischenergebnis erneut, welcher Agent als Nächstes handeln soll, oder ob die Aufgabe abgeschlossen ist.

Ein typischer Lauf folgt diesem Muster:

1. Der Supervisor empfängt die Nutzeranfrage und klassifiziert, um welche Art von Aufgabe es sich handelt.
2. Er wählt einen passenden Spezialagenten und übergibt ihm einen klar umrissenen Auftrag.
3. Der Worker erledigt seine Teilaufgabe und gibt ein, idealerweise komprimiertes, Ergebnis zurück.
4. Der Supervisor bewertet das Ergebnis und entscheidet: nächster Worker, Wiederholung oder finale Synthese.

Diese zentrale Routing-Logik unterscheidet das Supervisor-Pattern von einem Swarm (gleichrangige Agents ohne festen Koordinator) und von einer Pipeline (feste, deterministische Reihenfolge). Der Supervisor bringt Steuerung und, wichtig für DACH-B2B, eine klare Verantwortlichkeitslinie für die Frage "Wer hat was entschieden?".

Abgrenzung: Supervisor vs. Orchestrator-Worker

In der Praxis werden die Begriffe oft synonym verwendet, und das ist nicht falsch, aber es gibt einen Akzentunterschied, der für die Architekturentscheidung zählt.

Beim Orchestrator-Worker-Pattern (kanonisches Multi-Agent-Muster nach Anthropics Taxonomie) zerlegt ein Lead-Agent die Aufgabe und spawnt dynamisch Sub-Agents, also so viele, wie der Plan gerade erfordert. Referenzfall ist der Anthropic Research Agent (Juni 2025): Ein Lead Claude Opus 4 läuft im Extended-Thinking-Modus, zerlegt die Anfrage und startet parallel mehrere Sonnet-4-Sub-Agents, laut Anthropic typischerweise drei bis fünf. Jeder Sub-Agent besitzt sein eigenes Kontextfenster (rund 200k Token), recherchiert eigenständig und liefert eine komprimierte Zusammenfassung, nicht das volle Transkript, zurück. In Anthropics interner Recherche-Evaluierung schnitt das System um 90,2 % besser ab als ein Single-Agent-Opus-4. Der Preis: Multi-Agent-Systeme verbrauchen laut Anthropic rund 15-mal so viele Token wie ein Chat, ein einzelner Agent rund 4-mal so viele.

Das Supervisor-Pattern betont stärker das Routing-Element: Der Supervisor entscheidet, welcher aus einer Menge feststehender Spezialagenten als Nächstes handelt. AWS nutzt für sein Supervisor-Modell das Label "Multi-Agent Collaboration". Im Kern ist das ein Hub-and-Spoke-Supervisor-Muster, nicht mehr und nicht weniger. Bei dreistufigen Varianten (Supervisor → Planner → Worker) spricht man von hierarchischem Multi-Agent: Der Supervisor entscheidet, welche Art Job das ist, ein Planner baut den Sub-Task-Graphen, die Worker führen aus.

Praktisch gilt: Jeder Orchestrator ist ein Supervisor, aber nicht jeder Supervisor spawnt dynamisch. Für die meisten Enterprise-Workflows mit bekannten Domänen ist die statische Supervisor-Variante leichter zu evaluieren und zu auditieren.

Umsetzung: LangGraph und AWS Bedrock

Stand 2026 gibt es zwei Referenzwege: LangGraph für eigene Stacks und Amazon Bedrock für AWS-Umgebungen. Bei AWS hat sich der empfohlene Weg 2026 verschoben.

LangGraph (LangChain). Die graphbasierte Orchestrierungs-Runtime erreichte mit LangGraph 1.0 am 22. Oktober 2025 die erste stabile Major-Version im Bereich durabler Agent-Frameworks. Sie bietet ein Hierarchical-Supervisor-Template, durable State mit Checkpointing (ein unterbrochener Lauf nimmt nach Server-Neustart am letzten Checkpoint wieder auf), Human-in-the-Loop-Pause/Resume und Streamable-HTTP-Support für entfernte MCP-Server. Lizenz: MIT. LangGraph ist 2026 die häufigste Open-Source-Orchestrierungs-Runtime in DACH-AI-Engineering-Teams.

Vereinfachter Pseudocode für einen LangGraph-Supervisor:

```
supervisor = create_supervisor(
agents=[recherche_agent, vertrags_agent, freigabe_agent],
model="reasoning-model",
prompt="Route die Anfrage an den passenden Spezialisten. "
"Klarer Auftrag pro Agent: Ziel, Output-Format, Grenzen. "
"Beende, wenn die Aufgabe vollständig gelöst ist."
)

Zustand fließt als typisiertes State-Objekt durch die Knoten,

wird gecheckpointet und ist nach Neustart wiederherstellbar.

```

Amazon Bedrock Agents: Multi-Agent Collaboration. AWS hat die Funktion im März 2025 allgemein verfügbar gemacht. Ein Supervisor-Agent arbeitet mit Collaborator-Agents in einem von zwei Modi: Als Supervisor sammelt er die Antworten der Collaborators und formuliert das Ergebnis, als Supervisor with Routing leitet er die Anfrage nur an den passenden Collaborator weiter und spart so Latenz. Dazu kommen Inline Agents sowie Trace und Debugging in der Konsole. Seit dem 30. Juli 2026 heißt der Dienst Amazon Bedrock Agents Classic und läuft im Wartungsmodus: Neue Konten können ihn nicht mehr nutzen, Konten mit Nutzung in den letzten zwölf Monaten arbeiten ohne geplantes Ende weiter. Neue Funktionen kommen keine dazu.

Amazon Bedrock AgentCore. Das ist ein eigenes Produkt, allgemein verfügbar seit 13. Oktober 2025. AgentCore liefert Runtime, Gateway, Memory, Identity und Observability, das Gateway bindet bestehende MCP-Server an. AWS rät, neue Agenten auf AgentCore zu entwickeln. Die Multi-Agent-Unterstützung stuft AWS dort aber selbst als eingeschränkt ein: Das Supervisor-Pattern geht über Agents, die als MCP-Tools eingebunden sind (Agent-as-Tool); einen Routing-Modus wie in Bedrock Agents gibt es dort nicht direkt. Für volle Multi-Agent-Zusammenarbeit brauchst du eigenen Framework-Code, etwa LangGraph auf der AgentCore Runtime.

Für die agentenübergreifende Kommunikation, besonders über Vendor-Grenzen, nutzt man das A2A-Protokoll (Linux Foundation seit Juni 2025). A2A definiert einen Task-Lebenszyklus (submitted → working → input-required → completed | failed | canceled), bei dem die interne Logik des entfernten Agenten opak bleibt. Der Supervisor sieht nur Auftrag und Ergebnis. Für den Tool-Zugriff der einzelnen Agents ist MCP der Standard. Die Faustregel der Anbieter lautet: MCP für Agent-zu-Tool, A2A für Agent-zu-Agent.

Wann es passt und wann nicht

Das Supervisor-Pattern spielt seine Stärken bei parallelisierbaren Problemen mit geringer Zustandskopplung zwischen den Teilaufgaben aus und wenn der Schreibpfad single-threaded oder trivial zusammenführbar ist. Gute Kandidaten: Recherche, breite Suche, Dokument-Fan-out, Multi-Dokument-Review, Schadens-Triage, Betrugsprüfung mit unabhängigen Checks.

Es versagt bei eng gekoppelten, sequenziellen Aufgaben, bei denen jeder Schritt die impliziten Entscheidungen aller folgenden prägt. Cognition.ai zeigte 2025 ("Don't Build Multi-Agents"), dass parallele Writer-Swarms durch Kontext-Fragmentierung unvereinbare Stil- und Edge-Case-Entscheidungen treffen und nicht mergebare Diffs produzieren. Das saubere Gegenbeispiel bleibt Code-Generierung über mehrere Dateien. Das aktualisierte Cognition-Fazit (April 2026) ist pragmatisch: Multi-Agent funktioniert für read-mostly Fan-out, sofern die Schreibvorgänge single-threaded bleiben.

Grenzen: Der Supervisor als Bottleneck

Die zentrale Schwäche steckt im Namen: Alles läuft über den Supervisor.

• Single Point of Failure. Fällt der Supervisor aus oder verirrt sich, steht das ganze System.
• Latenz-Engstelle. Schritte gehen seriell durch den Supervisor; bei drei Hierarchie-Stufen kaskadiert die Latenz und kann den Mehrwert auffressen.
• Plan-Drift. Bei langen Läufen verliert der Supervisor seinen Plan und spawnt Sub-Tasks erneut, die bereits erledigt sind.
• Vage Delegation. Unklare Aufträge führen zu Doppelarbeit und Lücken. Anthropic beobachtete genau das in frühen Experimenten. Gegenmittel: Jeder Worker erhält Ziel, Output-Format, Tool-Hinweise und klare Aufgabengrenzen.
• Prompt-Injection-Verstärkung. Jedes neue Sub-Agent-Kontextfenster ist eine neue Angriffsfläche über nicht vertrauenswürdige Inhalte.

Beispiel: Allianz Project Nemo

Das am besten dokumentierte Praxisbeispiel ist Allianz Project Nemo, ein hierarchisches Supervisor-System, das Allianz in Australien für Lebensmittelverderb-Schäden nach Unwettern einsetzt. Sieben spezialisierte Agents arbeiten zusammen: Planner, Cyber, Coverage, Weather, Fraud, Payout und Audit. Im Beispiel von Allianz dauert der Sieben-Agenten-Workflow vom Einreichen des Schadens bis zur menschlichen Prüfung unter fünf Minuten. Ein menschlicher Sachbearbeiter prüft die Audit-Zusammenfassung und trifft die finale Auszahlungsentscheidung. Human-in-the-Loop ist hier explizite Policy.

Die Zahlen: gestartet in Australien im Juli 2025, in unter 100 Tagen live, laut Allianz mit 80 % kürzerer Bearbeitungs- und Regulierungszeit. Lebensmittelschäden unter AUD 500 sind statt nach mehreren Tagen nach einem Tag erledigt, teils in wenigen Stunden. Allianz ist ein deutscher Versicherer und hält die modulare Architektur für übertragbar auf weitere Produktlinien und Länder.

Architektonisch lehrreich ist der dedizierte Audit-Agent: Er erzeugt eine vollständige Zusammenfassung aller Agenten-Entscheidungen und damit einen lückenlosen Audit-Trail für Compliance und menschliche Prüfung. Die Lehre für DACH: Auditierbarkeit gehört in die Agenten-Topologie eingebaut, nicht nur in die Logging-Pipeline.

Für Agenturen und B2B-Entscheider

Wer ein Multi-Agent-Projekt im DACH-Mittelstand startet, fährt mit LangGraph oder n8n als Orchestrierung, MCP für Tools und A2A für jeden Cross-Platform-Handshake rational. Für Konzerne mit dominanter SaaS-Landschaft ist die plattformeigene Orchestrierung (Agentforce, SAP Joule Studio, Copilot Studio) die naheliegende Basis, mit A2A als Bindeglied. Wichtig für Agenturen, die Kunden beraten: Beginne mit einem klar abgegrenzten, parallelisierbaren Use Case, halte den Schreibpfad single-threaded, baue Human-in-the-Loop an den kritischen Stellen ein und beachte die längere AVV-Kette nach DSGVO Art. 28 sowie Transfer Impact Assessments pro grenzüberschreitendem A2A-Hop. Der Allianz-Nemo-Benchmark (unter 100 Tage bis live) ist für eng gescopte Projekte erreichbar.