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) oder AWS Bedrock AgentCore (Supervisor + Collaborator); 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 N parallele Sonnet-4-Sub-Agents über das Task-Tool. Jeder Sub-Agent besitzt sein eigenes Kontextfenster (rund 200k Token), recherchiert eigenständig und liefert eine komprimierte Zusammenfassung – nicht das volle Transkript – zurück. Anthropics interne Evaluierung: +90,2 % auf Recherche-Breitenmetriken gegenüber einem Single-Agent-Opus-4, allerdings bei rund 15-fachem Token-Verbrauch.

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 produktionsreife Referenzwege.

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 vollstaendig geloest ist."
)

Zustand fliesst als typisiertes State-Objekt durch die Knoten,

wird gecheckpointet und ist nach Neustart wiederherstellbar.

```

AWS Bedrock AgentCore Multi-Agent Collaboration. GA seit März 2025. Das Modell besteht aus einem Supervisor-Agenten plus Collaborator-Agents, mit Inline-Agent-Runtime, einem optimierten "Supervisor-with-Routing"-Modus (schnelleres reines Routing) versus vollem Orchestrierungs-Modus sowie integrierter Trace- und Debug-Konsole. AgentCore liefert Runtime, Gateway, Memory, Identity und Observability und unterstützt MCP.

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

Die am besten dokumentierte DACH-Referenz ist Allianz Project Nemo – ein hierarchisches Supervisor-System für Lebensmittelverderb-Schäden nach Naturkatastrophen. Sieben spezialisierte Agents arbeiten zusammen: Planner, Cyber, Coverage, Weather, Fraud, Payout und Audit. Der vollständige Sieben-Agenten-Workflow läuft in unter fünf Minuten durch; 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 deployt, mit 80 % Reduktion der Bearbeitungs- und Regulierungszeit für berechtigte Schäden unter AUD 500. Allianz ist ein deutscher Versicherer und prüft die Replikation der modularen Architektur über das globale P&C-Portfolio.

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: Beginnen Sie mit einem klar abgegrenzten, parallelisierbaren Use Case, halten Sie den Schreibpfad single-threaded, bauen Sie Human-in-the-Loop an den kritischen Stellen ein und beachten Sie 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.