Multi-Agent-Orchestrierung: was wir von Claudes Agent Teams gelernt haben

Anthropic hat Agent Teams in Claude Code ausgeliefert, um mehrere Claude-Instanzen gleichzeitig an verschiedenen Teilen eines Problems arbeiten zu lassen, koordiniert von einem Lead-Agenten, der Teilaufgaben verteilt und Ergebnisse zusammenführt. Das Muster wurde gemischt aufgenommen: brillant für manche Workloads, langsamer als ein einzelner Agent für andere, gelegentlich das Schlechteste beider Welten. Das Signal der ersten Monate echter Nutzung: Multi-Agent-Orchestrierung ist wirklich nützlich — für eine bestimmte Problemform, mit einer bestimmten Disziplin. Dieser Beitrag zeigt die tragende Form.

Die Problemform, die profitiert

Multi-Agent-Orchestrierung hilft, wenn das Problem in Chunks zerfällt, die:

• Unabhängig sind. Subagenten arbeiten an verschiedenen Dateien, Modulen, Themen, ohne in Echtzeit koordinieren zu müssen.
• Vergleichbar in Größe sind. Drei Teilaufgaben grob gleicher Komplexität schlagen eine winzige und eine riesige.
• Mergebar sind. Ihre Outputs kombinieren am Ende sauber, ohne subtile Wechselwirkungen, die Neuverhandlung erfordern.

Klassische Passungen: Tests für mehrere unabhängige Module schreiben, Dokumentation für mehrere Services generieren, eine Funktion über Dateien refaktorieren, wenn die Änderungen mechanisch sind, parallele Recherchefragen, deren Antworten in eine finale Synthese münden.

Klassische Anti-Passungen: alles, wo Schritt zwei vom Ergebnis von Schritt eins abhängt, alles, wo die Agenten eine gemeinsame Designentscheidung aushandeln müssen, alles, wo die natürliche Arbeitseinheit klein genug ist, dass der Koordinationsaufwand den Parallelitätsgewinn übersteigt.

Die Lead-und-Subagenten-Architektur

Die herstellerübergreifend tragende Architektur ist konsistent. Ein Lead-Agent:

1. Liest die Anfrage und entscheidet, wie zu zerlegen ist.
2. Schreibt eine strukturierte Task-Spec für jeden Subagenten — Inputs, erwartete Outputs, Constraints.
3. Dispatcht Subagenten parallel.
4. Empfängt deren Outputs.
5. Mergt, reconciled und synthetisiert die finale Antwort.

Der Lead ist nicht nur ein Router. Er ist die einzige Komponente mit vollem Kontext, mit der Merge-Logik und mit der Verantwortung für Output-Qualität. Subagenten reden nicht miteinander. Jeder bekommt einen in sich abgeschlossenen Brief, erledigt seine Arbeit, gibt zurück.

Warum die Zerlegung der Ort des Scheiterns ist

Die Versuchung: den Lead-Agenten "teile das auf, wie es Sinn macht" zu fragen. Manchmal funktioniert das. Oft wählt der Lead eine technisch verteidigbare, aber operativ schlechte Zerlegung — Chunks, die sich mittendrin als abhängig erweisen, oder Chunks, die überlappenden Output produzieren, den der Merge nicht sauber auflösen kann.

Das tragende Muster: Der Entwickler spezifiziert die Zerlegung explizit, oder zumindest die Zerlegungsstrategie. "Nach Datei aufteilen" funktioniert für manche Aufgaben. "Nach Feature aufteilen" für andere. "Nach Recherchefrage aufteilen" für wieder andere. Die Zerlegungsstrategie ist eine Designentscheidung des Entwicklers; die Aufgabe des Agenten ist, sie auszuführen, nicht zu erfinden.

Der Lead-Agent ist exzellent darin, eine von Ihnen spezifizierte Zerlegung auszuführen. Er ist viel schlechter darin, die Zerlegungsstrategie zu wählen, die Sie nicht spezifiziert haben.

Der Merge-Schritt ist der Engpass

Drei Subagenten parallel klingen dreimal so schnell wie einer. In der Praxis liegt der Speedup oft näher bei 1,5×, weil der Merge-Schritt die Gesamtzeit dominiert. Der Lead muss drei Outputs lesen, Inkonsistenzen identifizieren, auflösen und ein kohärentes Endergebnis produzieren. Diese Arbeit ist single-threaded und proportional zum gesamten Subagent-Output.

Zwei praktische Abhilfen: Subagent-Outputs strukturiert und begrenzt halten (ein JSON-förmiger Report schlägt einen Aufsatz) und dem Lead eine klare Merge-Regel für vorhersehbare Konflikttypen geben (welcher Subagent gewinnt, wenn sie sich über einen gemeinsamen Begriff uneinig sind).

Wo das einen einzelnen Agenten schlägt

Konkrete Beispiele, in denen Multi-Agent-Orchestrierung konsistent den Single-Agent-Baseline schlägt:

• Testgenerierung für eine modulare Codebase. Fünf Subagenten, jeder mit einem Modul, produzieren umfassende Tests in grob der Wall-Clock-Zeit eines Agenten auf einem Modul.
• Dokumentenübergreifende Recherche. Drei Subagenten, jeder in einer Quelle grabend, produzieren breitere Abdeckung als ein Agent, der sequenziell liest.
• Mehrsprachige Dokumentation. Subagenten pro Zielsprache arbeiten parallel, wo ein einzelner Agent serialisieren würde.
• Unabhängige Refactors über eine große Codebase. Wenn die Änderungen nicht interagieren, liefert eine Aufteilung nach Verzeichnis nahezu linearen Speedup.

Wo es gegen einen einzelnen Agenten verliert

Ehrliche Gegenbeispiele:

• Eng gekoppelte Designarbeit. Ein einzelner Agent mit vollem Kontext produziert ein kohärenteres Design als zwei Agenten, die zwei Hälften produzieren, die der Lead zusammenflicken muss.
• Kurze Aufgaben. Der Koordinationsaufwand übersteigt den Parallelitätsnutzen für alles, was bequem in den Kontext eines einzelnen Agenten passt.
• Aufgaben mit gemeinsamem mutablen State. Wenn Subagenten beim Arbeiten den Fortschritt der anderen lesen müssen, bricht die Orchestrierung. Diese Problemklasse will eine andere Architektur (langlaufende Kollaboration, nicht parallele Zerlegung).

Governance-Betrachtungen

Dieselben Hook- und Audit-Muster, die Single-Agent-Arbeit governen, gelten für Multi-Agent-Setups, mit einer Ergänzung: die Orchestrierungstopologie selbst ist Teil der Audit-Geschichte. Erfassen Sie nicht nur, was jeder Agent tat, sondern wie die Arbeit zerlegt und wie die Outputs gemergt wurden. Beim ersten Mal, wenn Sie einem Compliance-Reviewer ein Multi-Agent-Ergebnis erklären müssen, ist dieser Topologie-Log das Artefakt, mit dem Sie antworten.

Ein praktisches Start-Playbook

1. Wählen Sie eine Aufgabe, die offensichtlich in unabhängige Chunks vergleichbarer Größe zerfällt.
2. Spezifizieren Sie die Zerlegungsstrategie in Ihrem Prompt an den Lead-Agenten — lassen Sie sie nicht offen.
3. Begrenzen Sie den Scope jedes Subagenten eng. In sich abgeschlossener Brief, strukturiertes Output-Format, klare Akzeptanzkriterien.
4. Geben Sie dem Lead eine Merge-Regel für vorhersehbare Konflikttypen.
5. Lassen Sie eine Single-Agent-Baseline auf derselben Aufgabe laufen und vergleichen Sie. Der Vergleich ist der einzige ehrliche Weg, zu wissen, ob Multi-Agent geholfen hat.
6. Iterieren Sie an der Zerlegungsstrategie basierend auf dem, was Sie beobachten, nicht auf dem, was sich richtig anfühlt.

Die breitere Lektion

Die interessante Wahrheit über Multi-Agent-Orchestrierung 2026: die Architektur ist schneller gereift als die Disziplin, sie zu nutzen. Die Werkzeuge — Claudes Agent Teams, OpenCodes Plan/Build-Split, eigene Orchestrierung über MCP — sind glaubwürdig. Die Teams, die Wert aus ihnen ziehen, behandeln Multi-Agent-Setups als bewusste Engineering-Entscheidung mit eigener Designdisziplin, nicht als magischen Beschleuniger.

Für DACH-Enterprise-Teams mappt diese Disziplin natürlich auf das, wie ernsthaftes Engineering ohnehin arbeitet. Die Struktur spezifizieren, den Scope begrenzen, das Ergebnis messen, ehrlich iterieren. Multi-Agent-Orchestrierung ist kein neues mentales Modell; es ist das alte mentale Modell, angewandt auf eine neue Art Arbeiter. Die Teams, die so vorgehen, sind die, deren KI-Arbeit sich über Quartale aufzinst.