Multi-Agent-Systeme

Was ist ein Multi-Agent-System?

Ein Multi-Agent-System bezeichnet eine Architektur, in der mehrere LLM-basierte Agenten zusammenarbeiten, um eine Aufgabe zu lösen, die ein einzelner Agent nicht bewältigt. Anthropics eigene Definition bringt es auf den Punkt: „A multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together." Entscheidend ist die Abgrenzung: Jeder Agent hat einen eigenen Prompt, eine eigene Rolle, ein eigenes Tool-Set und – im strengen Fall – ein eigenes Context-Window.

Diese Unterscheidung ist 2026 nicht akademisch. Anbieter-Decks haben den Begriff verwässert. Ein einzelner Agent mit vielen Tool-Integrationen, der als „Multi-Agent" vermarktet wird, weil die Tools selbst „Agenten" heißen, ist das, was man Marketing-Multi-Agent nennt. Das prominent zitierte Klarna-Beispiel („KI erledigt die Arbeit von 700 Mitarbeitern") ist ein Single-Agent-Deflection-System im Kundenservice – kein Multi-Agent-System, auch wenn es oft fälschlich so zitiert wird.

Echter Multi-Agent weist mindestens eine strukturelle Eigenschaft auf: einen Lead-/Orchestrator-Agenten, der dynamisch Sub-Agenten mit eigenem Context-Window erzeugt; Inter-Agent-Nachrichten, die Trust-Boundaries überqueren (etwa Agentforce zu SAP Joule über A2A); oder eine eigenständige Prozess-/Rollen-/Modell-Zerlegung mit nicht-trivialem State-Sharing. Allianz Project Nemo mit seinen sieben spezialisierten Agenten ist ein Lehrbuchbeispiel.

Die ehrliche Lektüre 2026: Die meisten produktiven „Agenten" sind weiterhin ein einzelnes, sorgfältig konstruiertes LLM mit Tools und Schleife. Das ist kein Defekt – Anthropic selbst betont, dass das einfachste Muster gewinnen sollte, das das Problem löst. Die Architekturfrage lautet daher selten „Multi-Agent ja/nein", sondern „welches Muster passt, und wo liegt unsere State-Kopplung?".

Das Orchestrator-Worker-Muster

Das Orchestrator-Worker-Muster (Lead-Sub-Agent) ist der kanonische Multi-Agent-Fall. Ein Lead-Agent läuft im Extended-Thinking- oder Planungsmodus, zerlegt die Nutzeranfrage in diskrete Teilaufgaben und erzeugt Sub-Agenten dynamisch über ein Task-Tool. Jeder Sub-Agent besitzt eigenen Prompt, eigenes Tool-Set und – entscheidend – ein eigenes Context-Window. Die Sub-Agenten liefern komprimierte Ergebnisse zurück, die der Lead synthetisiert.

Der Referenzfall ist der Anthropic Research Agent (Claude-Research-Feature, Juni 2025): ein Lead aus Claude Opus 4, Sub-Agenten aus Claude Sonnet 4. Anthropics veröffentlichte interne Evaluierung zeigte +90,2 % bei Research-Breite gegenüber dem Single-Agent Opus 4 – bei rund 15× höheren Token-Kosten (Quelle: Anthropic, „How we built our multi-agent research system", 13.06.2025). Anthropic war explizit: Dieser Token-Aufwand rechnet sich nur für hochwertige, parallelisierbare, breit angelegte Research-Aufgaben.

Eingesetzt wird das Muster bei breit angelegten, parallelisierbaren Problemen mit unabhängigen Teilaufgaben (Research, Markt-Intelligence, Multi-Dokument-Review, breite Triage). Vermieden werden sollte es bei eng gekoppelten Schreibaufgaben (Codegenerierung über Dateien hinweg) und bei hochdeterministischen Workflows, die Reproduzierbarkeit erfordern – dort gehört eine Pipeline hin.

Ein zentraler Praxis-Hinweis aus Anthropics Experimenten: Der Lead muss explizit lernen, wie er delegiert. Jeder Sub-Agent braucht Ziel, Output-Format, Quellen-/Tool-Leitlinien und klare Aufgabengrenzen. „Vage" Delegationen führten zu Doppelarbeit und Lücken in der Abdeckung.

Rollen, Handoffs und Koordination

Multi-Agent-Systeme leben von klar definierten Rollen und sauberen Übergaben. Über die reine Orchestrator-Worker-Struktur hinaus existieren mehrere Koordinationsmuster, die produktive Systeme häufig kombinieren:

Die Handoff-Semantik unterscheidet sich je Stack. Beim OpenAI Agents SDK enden explizite Handoffs den Zug eines Agenten und starten den nächsten, wobei die Konversationshistorie weitergereicht wird. AutoGen nutzt Group-Chat mit Turn-Taking. LangGraph reicht ein typisiertes State-Objekt durch Knoten und checkpointet es durabel. Beim Anthropic Claude Agent SDK erzeugt der Lead Sub-Agenten über das Task-Tool, die komprimierte, strukturierte Outputs zurückgeben.

Im Hub-and-Spoke-Modell über A2A delegiert ein zentraler Agent an spezialisierte Peer-Agenten – potenziell vendor-übergreifend. Das A2A-Protokoll definiert dafür einen Task-Lebenszyklus (submitted → working → input-required → completed | failed | canceled), eine Capability-Discovery über die AgentCard (ein JSON-Dokument mit Endpoint, Fähigkeiten, Skills, Modalitäten, Auth-Schemata) sowie Multipart-Nachrichten mit Artefakten als Ergebnis. Die interne Logik des Remote-Agenten bleibt dabei opak – das erlaubt einem Salesforce-Agenten, einen SAP-Agenten aufzurufen, ohne dass einer dem anderen Prompts, Memory oder Modelle offenlegt.

Die Koordinationsregel, die sich 2026 herauskristallisiert hat, betrifft den Write-Pfad: Viele Agenten lesen, sammeln, schließen, schlagen vor – aber nur ein Agent (oder eine Pipeline-Stufe) committet. Multi-Agent-Fan-out fürs Lesen ist robust; Fan-out fürs Schreiben ist fragil; gleichzeitige Schreibzugriffe auf gemeinsamen State sind die Todesspirale.

Fehler und Compounding Errors

Multi-Agent-Systeme haben Fehlermodi, die ein Single-Agent-System nicht kennt. Jeder der folgenden ist von Anthropic, Cognition, Sierra, Salesforce oder Microsoft in Produktion dokumentiert worden – die Kenntnis dieses Katalogs ist für jeden Architekten nicht verhandelbar:

1. Cascading-Failures. Ein Sub-Agent halluziniert ein Faktum; der Lead synthetisiert es in die Antwort; nachgelagerte Agenten handeln auf der falschen Tatsache. Gegenmittel: Verifier-Judge-Agent, geerdetes Retrieval, verpflichtende Zitate.
2. Echo-Chamber. Sub-Agenten verstärken eine falsche Prämisse des Leads. Gegenmittel: Modelle/Prompts der Sub-Agenten diversifizieren (MoA-Stil), eine Critic-Rolle einziehen.
3. Authority-Confusion. Ein Sub-Agent überschreibt Lead-Anweisungen, oder der Lead verliert die Autorität über die Konversation. Gegenmittel: klare Rollenhierarchien, A2A-Task-Verträge mit starken AgentCards.
4. Resource-Deadlock. Agenten warten aufeinander (A wartet auf Bs Ergebnis; B auf As Klärung). Gegenmittel: Timeouts auf jeden Task, expliziter input-required-State in A2A.
5. Prompt-Injection-Amplification. Jedes Sub-Agent-Context-Window ist eine neue Angriffsfläche. EchoLeak (CVE-2025-32711, Aim Labs, Juni 2025) war die erste bekannte Zero-Click-Prompt-Injection mit konkreter Datenexfiltration in einem produktiven LLM-System (Microsoft 365 Copilot). Dieselbe Risikoklasse skaliert linear mit der Zahl der Agenten, die nicht vertrauenswürdige Inhalte aufnehmen.
6. Context-Fragmentation (Cognitions Kernkritik). Sub-Agenten treffen unverträgliche implizite Entscheidungen. Gegenmittel: volle Traces teilen, wo die Kopplung hoch ist; single-threaded Writes; explizite Entscheidungs-Verträge.
7. Cost-Explosion. Das Orchestrator-Worker-Muster verbraucht beim Anthropic Research Agent rund 15× mehr Tokens; das rechnet sich nur für hochwertige Aufgaben. Gegenmittel: Token-Caps pro Sub-Agent, QoS-Stufen, Routing nach Komplexitätsschwelle.
8. Debuggability-Collapse. Kein einzelner Trace deckt den Lauf ab. Gegenmittel: verteiltes Tracing über das A2A-Mesh, durchgereichte Correlation-IDs in jedem A2A-Task und MCP-Call.

Der konzeptionelle Kern hinter Compounding Errors stammt aus Cognition.ais Analyse „Don't Build Multi-Agents" (Walden Yan, 12.06.2025): Aktionen tragen implizite Entscheidungen, und widersprüchliche Entscheidungen erzeugen schlechte Ergebnisse. „Scheinbare Meinungsverschiedenheiten" zwischen Agenten sind meist Symptome von Context-Fragmentierung, nicht echter Dissens. Im April-2026-Update („Multi-Agents: What's Actually Working", 22.04.2026) präzisierte Cognition: Multi-Agent funktioniert, wenn mehrere Agenten Intelligenz beitragen, die Writes aber single-threaded bleiben.

Synthese für die Architekturentscheidung

Stellt man Anthropic und Cognition nebeneinander und ignoriert die Rhetorik, ist die Synthese eindeutig:

• Multi-Agent funktioniert bei Problemen, die parallelisierbar sind, niedrige State-Kopplung zwischen den Teilproblemen aufweisen und deren Write-Pfad single-threaded oder trivial rekonzilierbar ist. Research, breite Suche, Dokument-Fan-out, Claims-Triage, Fraud-Screening mit unabhängigen Checks profitieren.
• Multi-Agent versagt bei hochgekoppelten, sequenziellen Problemen, in denen jede „implizite Entscheidung" jeden späteren Schritt prägt. Das saubere Beispiel bleibt Coding: Ein Writer-Swarm paralleler Coder-Agenten produziert ein Diff, das niemand mergen kann.
• Für die meisten Enterprise-Workflows liegt die Antwort dazwischen – und die Musterwahl zählt mehr als die binäre Frage.

Die vier Sätze, die man gegen jeden Multi-Agent-Pitch halten kann: Teile Context, wo die Kopplung hoch ist; isoliere Context, wo Parallelität dominiert; lass nie zwei Agenten gleichzeitig in denselben State schreiben; zahle 15× Tokens nur, wenn die Aufgabe research-förmig ist.

DACH-Bezug und Compliance-Hinweise

Im DACH-Raum kommen strukturelle Variablen hinzu, die US-Cloud-Referenzarchitekturen selten offen ansprechen. Die folgenden Hinweise sind informational und keine Rechtsberatung.

Datensouveränität. Wenn unterschiedliche Agenten auf unterschiedlichen Compute-Providern laufen – etwa ein Salesforce-Agent, der einen SAP-Joule-Agenten aufruft, der einen Anthropic-Claude-Reasoning-Schritt über A2A nutzt – überquert der Datenfluss auf jedem Task mehrere Daten-Residenz- und Auftragsverarbeiter-Grenzen. Unter der DSGVO ist potenziell jeder Agent-Provider ein Auftragsverarbeiter (Art. 28); Multi-Agent verlängert damit die AVV-Kette. Bei grenzüberschreitenden US-EU-Schritten greifen Art. 44–49 (Standardvertragsklauseln, Transfer Impact Assessment) auf jedem Agent-Hop, der eine Grenze überquert. Souveräne-Cloud-Optionen wie STACKIT (Schwarz-Gruppe), Open Telekom Cloud, IONOS oder plusserver sind für regulierte Multi-Agent-Workloads nicht optional. Der A2A-Handshake zu einem nicht-souveränen Agenten ist die am häufigsten übersehene Compliance-Exposition im DACH-Multi-Agent-Design.

Audit-Trail. Jede Agent-zu-Agent-Nachricht ist potenziell audit-relevant. Reproduzierbarkeit von Multi-Agent-Entscheidungen ist wegen der Nicht-Determinismus härter als bei Single-Agent-Systemen: Modellversionen pinnen, alle Sub-Agent-Prompts, Tool-Calls, abgerufenen Kontexte und genutzten AgentCards aufzeichnen, über eine einzige Trace-ID korrelieren. Das Allianz-Nemo-Design mit dediziertem Audit-Agenten, der eine vollständige Zusammenfassung aller Agent-Entscheidungen erzeugt, ist hier das DACH-relevante Muster – Auditierbarkeit gehört in die Agent-Topologie, nicht nur in die Logging-Pipeline.

EU AI Act (hochrangig, informational, keine Rechtsberatung). Offene Fragen sind 2026 nicht abschließend geklärt: Jeder Agent ist plausibel ein eigenes „KI-System" (Art. 3(1)), und auch die Komposition ist ein KI-System – mit potenziell höherer Risikoklassifizierung als die Teile. In einer Salesforce-SAP-Anthropic-A2A-Komposition ist typischerweise jeder Vendor Provider seines eigenen Agenten, während die integrierende Organisation Deployer des zusammengesetzten Systems ist. Art.-50-Transparenzpflichten multiplizieren sich über Agent-Calls hinweg.

Mitbestimmung. Multi-Agent-Workflows in HR, Kundenservice oder operativem Monitoring können nach BetrVG § 87 Abs. 1 Nr. 6 (Deutschland) bzw. ArbVG (Österreich) mitbestimmungspflichtig sein – auf Workflow-Ebene, nicht je Einzel-Agent. Der Trend 2026 sind explizite KI-Betriebsvereinbarungen, die Multi-Agent-Kompositionen abdecken (informational, keine Rechtsberatung).

Sprachliche Konsistenz. Multi-Agent-Systeme für DACH-Kunden brauchen einen einheitlichen Tone-of-Voice und ein konsistentes Sie/Du-Register über alle Agenten. Ein Salesforce-Agent, der „Du" nutzt und einen SAP-Agenten mit „Sie" aufruft, erzeugt eine Customer Experience, die „kaputt" liest. Style-Guides gehören auf AgentCard-/Prompt-Template-Ebene durchgesetzt.

Ausblick und Praxis-Hinweis

Für DACH-Projekte 2026 sind die rationalen Defaults klar: Single-Agent + Tools als Standard, Beförderung zu Multi-Agent nur, wenn die Aufgabe parallelisierbar, lese-lastig oder write-rekonzilierbar ist und der Kostenfaktor aufgeht. MCP für Tools, A2A für Agenten – alles andere ist 2026 ein bewusster Abweich vom konvergenten Stack. Jedes Sub-Agent-Context-Window als neue Angriffsfläche behandeln. Auditierbarkeit in die Topologie backen (Allianz-Audit-Agent als Blueprint). Eine Orchestrierungs-Schicht plus eine plattform-native wählen – drei oder mehr Frameworks in Produktion sind nicht beherrschbare Engineering-Oberfläche. Und AgentCards veröffentlichen, denn sie sind der systemübergreifende Vertrag, der entscheidet, ob ein Agent am Enterprise-Ökosystem teilnimmt.

Die Frage in der nächsten Architektur-Review lautet nicht mehr „Sollen wir ein Multi-Agent-System bauen?", sondern: „Welches der Anthropic-Muster passt zu unserem Workload, wie hoch ist unsere State-Kopplungs-Toleranz, welche Vendor-Estates betreiben wir bereits, und wo treten MCP und A2A in unseren Governance-Perimeter ein?"