Mehragenten-Orchestrierung: Sub-Agenten, Teams und selbstgebaute Workflows

Wann sich Aufteilung überhaupt lohnt

Ob ein Sprachmodell ein Werkzeug aufruft, mehrschrittig plant und sich selbst korrigiert, klärt der Artikel zu den Agenten-Grundlagen. Dort steht auch die wichtigste Regel: erst den einfachsten Weg ausreizen – oft genügt ein einzelner, gut gebauter Modellaufruf. Dieser Artikel setzt eine Ebene höher an. Angenommen, ein Agent reicht nicht: Wie verteilt man die Arbeit auf mehrere?

Die ehrliche Antwort zuerst, weil sie das ganze Thema rahmt: Mehr Agenten sind nicht automatisch besser. Jeder zusätzliche Agent kostet Tokens, Latenz und – das ist der unterschätzte Posten – Koordination. Aufteilung zahlt sich dort aus, wo eine Aufgabe echt parallele, voneinander unabhängige Teile hat: breit angelegte Recherche, mehrdimensionales Review, das Durchprobieren mehrerer Lösungsansätze. Sie schlägt zurück, wo Teilschritte eng gekoppelt sind und aufeinander aufbauen – klassisch beim Code-Schreiben, wo ein Helfer Annahmen trifft, die ein anderer nicht kennt.

Diese Trennlinie – breit-parallel und explorativ versus eng-gekoppelt und schreibend – zieht sich durch den ganzen Artikel. Sie ist der Schlüssel, um die scheinbar widersprüchlichen Ratschläge der Branche aufzulösen. Behalte sie im Hinterkopf, während wir die drei Bauformen durchgehen: lose Sub-Agenten, koordinierte Teams und Workflows, die das Modell sich selbst schreibt.

MerksatzAufteilen lohnt sich für breit-parallele, unabhängige Teilaufgaben (Recherche, Review). Bei eng gekoppelter Arbeit wie Code-Schreiben ist ein einzelner, linearer Agent meist verlässlicher.

Agenten-Grundlagen: Tool-Use, MCP & Orchestrierung →

Sub-Agenten: Arbeitsteilung mit sauberem Kontext

Die schlankeste Form der Aufteilung ist der . Ein Leit-Agent koordiniert den Plan, delegiert eine abgegrenzte Teilaufgabe an einen spezialisierten Helfer und bekommt von ihm nur ein verdichtetes Ergebnis zurück – oft ein paar tausend Tokens statt des gesamten Suchverlaufs. Der Clou liegt im eigenen Kontextfenster: Der Sub-Agent durchwühlt zehn Dateien oder zwanzig Suchtreffer, ohne dass dieser Lärm den Hauptkontext zumüllt. Diese Kontext-Hygiene – Sub-Agenten als Werkzeug gegen – ist im Detail im Artikel Das Modell verstärken beschrieben; hier interessiert die strukturelle Seite.

Entscheidend ist eine Eigenschaft, die oft missverstanden wird: Sub-Agenten reden nicht miteinander. Sie laufen innerhalb einer Sitzung, jeder bekommt sein isoliertes, fokussiertes Ziel, und ihr einziger Kommunikationskanal ist die Zusammenfassung, die sie an den Haupt-Agenten zurückgeben. Es gibt keinen Seitenkanal, über den sich zwei Sub-Agenten abstimmen. Das ist kein Mangel, sondern Absicht: Genau diese Isolation verhindert, dass sie sich gegenseitig mit Halb-Ergebnissen verwirren.

Aus genau diesem Grund eignen sich Sub-Agenten für Zuarbeit, nicht für parallele Aktionen. Sie liefern Intelligenz – recherchieren, prüfen, fassen zusammen – während die eigentlichen Entscheidungen und Schreibzugriffe beim koordinierenden Agenten bleiben. So arbeiten die Subagenten von Coding-Assistenten in der Regel: Sie beantworten Fragen und sammeln Material, schreiben aber keinen Code parallel.

MerksatzSub-Agenten haben ein eigenes Kontextfenster, liefern nur eine Zusammenfassung zurück und reden nicht miteinander – ideal für Zuarbeit (Recherche, Review), nicht für parallele Schreibzugriffe.

Das Modell verstärken: Kontext, Gedächtnis & Skills →

Agent-Teams: wenn die Helfer doch miteinander reden

Was Sub-Agenten ausdrücklich nicht tun – direkt kommunizieren –, ist genau die Idee hinter Agent-Teams. Ein besteht aus mehreren Claude-Code-Sitzungen, von denen jede ihr eigenes Kontextfenster hat, die sich aber eine gemeinsame Aufgabenliste teilen und direkt miteinander reden können. Statt dass alles über einen Engpass-Koordinator läuft, koordinieren sich die Teammitglieder teilweise selbst.

Der Status ist wichtig: Agent-Teams sind in Claude Code ein experimentelles Feature und standardmäßig abgeschaltet. Man schaltet sie über ein Flag in der Konfiguration frei (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS in der settings.json). „Experimentell, default aus“ ist hier kein Beiwerk, sondern eine Reifegrad-Warnung – mehr dazu im Abschnitt zu Hierarchie und Emergenz, denn die Forschung ist beim Thema „Agenten, die sich selbst koordinieren“ deutlich skeptischer als die Marketing-Erzählung.

Der praktische Unterschied lässt sich auf eine Frage verdichten: Reden die Helfer miteinander? Bei Sub-Agenten nein – jeder berichtet nur nach oben. Bei Agent-Teams ja – sie teilen eine Task-Liste und stimmen sich direkt ab. Mehr Kommunikation klingt nach mehr Fähigkeit, bringt aber mehr Wege mit, auf denen Koordination schiefgehen kann. Welche Form besser ist, hängt also weniger am Feature als an der Aufgabe.

MerksatzSub-Agenten sind isoliert und berichten nur nach oben; Agent-Teams teilen eine Aufgabenliste und kommunizieren direkt – Letzteres ist in Claude Code experimentell und per settings.json-Flag ein- bzw. auszuschalten.

Dynamic Workflows: der Harness, den Claude sich selbst baut

Die bisherigen Bauformen setzen voraus, dass ein Mensch die Aufteilung vorgibt. Mit Dynamic Workflows dreht Anthropic das um: Claude schreibt zur Laufzeit selbst einen aufgabenspezifischen – konkret ein kleines JavaScript-Programm –, das Sub-Agenten spawnt, ihre Arbeit koordiniert und die Ergebnisse einsammelt. Ein ist also kein festes Skript, das ein Entwickler hinterlegt hat, sondern Orchestrierungs-Code, den das Modell für genau diese eine Aufgabe schreibt und ausführt. Auslösen lässt sich das per einfacher Bitte oder über das Triggerwort .

Der Sinn dahinter ist nüchtern: Lange Agentenläufe haben drei wiederkehrende Versagensmuster. Anthropic benennt sie als „agentic laziness“ (der Agent hört zu früh auf), „self-preferential bias“ (er bevorzugt seine eigenen Funde) und „goal drift“ (er verliert über viele Schritte das eigentliche Ziel aus dem Blick). Ein Harness mit separaten Sub-Agenten dämpft alle drei: Jeder Helfer hat ein eigenes Kontextfenster und ein isoliertes, fokussiertes Ziel, sodass kein einzelner Lauf lang genug wird, um abzudriften oder sich in seine eigenen Zwischenergebnisse zu verlieben. Das knüpft direkt an den Kanon-Merksatz an, dass man oft besser den Harness und den Loop enger zieht, als auf ein noch klügeres Modell zu warten.

Zwei Stellschrauben machen den Harness flexibel. Erstens Modell-Routing: Jede Stufe kann ein anderes Modell wählen – ein günstiges für stupide Vorarbeit, ein stärkeres für tiefes Reasoning. Zweitens Isolations-Routing: Der Workflow entscheidet, ob ein Sub-Agent in einem eigenen Git-Worktree laufen soll, also in einem komplett getrennten Arbeitsverzeichnis. Die unabhängige Tech-Presse beschreibt beide Mechanismen übereinstimmend mit der Anbieter-Quelle. Ein vielbeachteter YouTube-Kanal demonstrierte das Modell-Routing an einem Framework, das vier parallele Recherche-Subagenten in der Planung einsetzt und die Synthese bewusst mit einem günstigeren Modell statt dem teuersten erledigt, um Kosten zu sparen – eine Einzelbeobachtung (n=1), die das Prinzip aber gut illustriert.

MerksatzDynamic Workflows – Claude schreibt sich zur Laufzeit einen JavaScript-Harness, der Sub-Agenten spawnt, mit eigener Modell- und Worktree-Wahl je Stufe. Ziel: lange Läufe gegen Faulheit, Selbstbevorzugung und Zielverlust absichern.

Die sechs Workflow-Muster im Überblick

Der Harness ist kein Freistil – er setzt sich aus sechs komponierbaren Mustern zusammen, die Anthropic benennt. Sie lassen sich kombinieren und schachteln, decken aber jeweils einen klar umrissenen Bedarf ab:

Erstens classify-and-act: eine Eingabe einordnen und je nach Klasse einen passenden Pfad nehmen – das vertraute Routing, nur dynamisch erzeugt. Zweitens : eine Frage auffächern, mehrere Sub-Agenten gleichzeitig Teilaspekte bearbeiten lassen und ihre Ergebnisse anschließend zu einer Antwort zusammenführen – das Arbeitspferd der parallelen Recherche. Drittens : ein zweiter Agent prüft die Arbeit des ersten gezielt gegen, sucht also aktiv nach Fehlern statt nur zuzustimmen.

Viertens generate-and-filter: viele Kandidaten erzeugen und die schlechten herausfiltern. Fünftens tournament: Lösungen paarweise gegeneinander antreten lassen und die jeweils bessere weiterreichen, bis eine Siegerin übrig bleibt. Sechstens loop-until-done: einen Schritt so lange wiederholen, bis ein Abbruchkriterium erfüllt ist – das Gegenmittel gegen vorzeitiges Aufhören. Wer die Orchestrierungs-Muster im Agenten-Artikel kennt (Routing, Parallelisierung, Orchestrator-Worker, Evaluator-Optimizer), erkennt die Familie wieder: Diese sechs sind die zur Laufzeit zusammengesetzten, konkreten Spielarten derselben Idee.

MerksatzSechs komponierbare Muster – classify-and-act, fan-out-and-synthesize, adversarial verification, generate-and-filter, tournament, loop-until-done. Es sind die dynamisch erzeugten Spielarten der bekannten Orchestrierungs-Muster.

Orchestrierungs-Muster im Agenten-Artikel →

Git-Worktrees: parallele Agenten ohne Kollision

Wenn mehrere Agenten gleichzeitig an Code arbeiten, entsteht ein handfestes Problem: Sie editieren dieselben Dateien und treten sich gegenseitig auf die Füße. Praktiker beschreiben das anschaulich als „drei Leute am selben Notizblock“. Die saubere Lösung dafür sind Git-Worktrees. Ein gibt jeder Sitzung ein komplett eigenes Arbeitsverzeichnis mit eigenem Branch, während sie sich die gemeinsame Versionsgeschichte teilen. Edits laufen damit in getrennten Spuren und kollidieren nicht.

In Claude Code lässt sich das pro Sub-Agent dauerhaft setzen – über isolation: worktree im Frontmatter der Agent-Definition. Ein temporär angelegter Worktree wird automatisch wieder entfernt, wenn der Agent ohne Änderungen fertig ist; bleibt etwas Brauchbares übrig, bleibt der Branch erhalten und kann zusammengeführt werden. Das ist genau die Stellschraube, die ein Dynamic Workflow beim Isolations-Routing zieht.

Worktrees lösen damit einen scheinbaren Widerspruch zum Agenten-Kanon auf. Dort heißt es vorsichtig, Code-Schreiben lasse sich kaum parallelisieren, weil sich Agenten ohne geteilten Zustand in die Quere kommen. Das stimmt – solange sie sich denselben Arbeitsbereich teilen. Isoliert man jeden Fix in einem eigenen Branch, verschwindet der geteilte Zustand und damit der Konflikt. Anthropic zeigt das an einem Migrations-Beispiel, bei dem mehrere unabhängige Fixes je in ihrem eigenen Worktree entstehen. Die Aussagen sind also konsistent: Nicht das Code-Schreiben an sich ist unparallelisierbar, sondern das Teilen eines Arbeitsbereichs.

MerksatzGit-Worktrees geben jedem Agenten ein eigenes Arbeitsverzeichnis mit eigenem Branch (geteilte History). Damit lassen sich auch Code-Aufgaben parallelisieren – nicht das Schreiben ist das Problem, sondern der geteilte Zustand.

Wie viele Agenten? Diversität schlägt Anzahl

„Mehr Agenten = besser?“ ist die Frage, bei der die meisten Bauchgefühle danebenliegen. Praktiker berichten von einer harten Grenze: Jenseits von zwei bis drei parallelen Terminals sei alles Weitere „productivity theater“ – Beschäftigung, die nach Produktivität aussieht. Die Stoßrichtung deckt sich mit der Forschung, die konkrete Zahl ist aber eine attribuierte Praktiker-Heuristik, kein Naturgesetz.

Die belastbarere Antwort aus der aktuellen Forschung ist differenzierter und korrigiert das naive „zwei bis drei und Schluss“. Eine Untersuchung zur Skalierung von Multi-Agenten-Systemen zeigt: Homogenes Hochskalieren – einfach mehr gleichartige Agenten – sättigt schnell, weil ihre Ausgaben stark korreliert sind und sie im Wesentlichen dasselbe noch einmal sagen. Heterogenität dagegen trägt weiter: Schon zwei diverse Agenten (verschiedene Modelle, Prompts oder Werkzeuge) erreichen oder übertreffen sechzehn gleichartige. Der eigentliche Hebel ist also nicht die Anzahl, sondern die Vielfalt – und nach oben begrenzt wird die Leistung ohnehin durch die intrinsische Unsicherheit der Aufgabe, nicht durch zu wenige Agenten.

Die praktische Konsequenz: Statt mehr Klone desselben Agenten zu starten, lohnt es sich, die wenigen Agenten unterschiedlich aufzustellen – das passt exakt zum adversarial-verification-Muster, wo ein bewusst anders gepolter Prüfer den Mehrwert bringt. Größenordnungen wie „drei bis vier Agenten“ kursieren in Sekundär- und Übersichtsquellen; nimm sie als grobe Hausnummer, nicht als feste Obergrenze. Die robustere Faustregel lautet: lieber wenige, aber verschiedene Agenten als viele gleiche.

MerksatzNicht die Zahl der Agenten ist der Hebel, sondern ihre Diversität – zwei verschiedene Agenten schlagen sechzehn gleichartige. Gedeckelt wird die Leistung durch die Unsicherheit der Aufgabe selbst.

Hierarchie schlägt Emergenz

Es gibt eine romantische Vorstellung von Multi-Agenten-Systemen: viele Agenten, die sich selbst organisieren, und aus deren Zusammenspiel entsteht wie von selbst kluges Verhalten – Emergenz. In der Praxis ist diese der Grund, warum solche Systeme scheitern. Eine große Fehleranalyse von Multi-Agenten-LLM-Systemen, die über tausend annotierte Abläufe auswertet, kommt zu einem klaren Ergebnis: Der überwiegende Teil der Fehler stammt nicht aus mangelnder Modellqualität, sondern aus Koordination und Spezifikation – Agenten ignorieren ihre Rolle oder die Aufgabe, missverstehen einander, oder es fehlt schlicht ein Verifikations-Schritt.

Die Konsequenz aus der Analyse: Zentralisierte Orchestrierung mit explizitem Zustands-Management dämpft die Fehlerverstärkung – also eine klare Hierarchie mit einem Koordinator, der den Zustand führt, statt eines Schwarms, der sich selbst überlassen wird. Auf den Punkt gebracht: Emergenz ist faszinierend für die Forschung, aber nicht reif für den Produktiveinsatz. Das ist exakt die Reifegrad-Warnung, die hinter dem „experimentell, default aus“ der Agent-Teams steht.

Damit schließt sich der Kreis zur Diversitäts-Erkenntnis: Beide sagen, dass das Modell selten der Engpass ist. Mal ist es die fehlende Vielfalt, mal die fehlende Koordination – aber fast nie die rohe Fähigkeit des einzelnen Agenten. Wer ein Multi-Agenten-System verlässlich machen will, investiert in Struktur, Rollen und Verifikation, nicht in noch mehr oder noch stärkere Agenten.

MerksatzMulti-Agenten scheitern meist an Koordination und Spezifikation, nicht an der Modellqualität. Eine klare Hierarchie mit explizitem State-Management schlägt selbstorganisierende Emergenz – die ist (noch) nicht produktionsreif.

Anthropic baut Multi-Agenten, Cognition rät ab – und beide haben recht

Hier kollidieren zwei prominente Positionen scheinbar frontal. Anthropic baut mit Dynamic Workflows aktiv einen Multi-Agenten-Harness – fan-out, tournament, viele Sub-Agenten – und legt mit dem Orchestrator-Worker-Research-System sogar offen, dass ein Team aus Leit-Agent und drei bis fünf parallelen Sub-Agenten einen einzelnen Spitzen-Agenten um rund 90 % schlägt. Cognition argumentiert in „Don’t Build Multi-Agents“ genau dagegen: Der Kern von Verlässlichkeit sei Context Engineering, man solle so viel Kontext wie möglich über Entscheidungen teilen und die Entscheidungsfindung nicht so aufsplitten, dass Konflikte entstehen – Schreibzugriffe single-threaded halten, Sub-Agenten nur zuarbeiten lassen. Beide Quellen sind im Kanon ausführlich behandelt; hier geht es darum, den scheinbaren Widerspruch aufzulösen.

Die Auflösung ist die Achse vom Anfang dieses Artikels. Anthropics +90 %-Beispiel ist Recherche – breit-parallel und explorativ, mit vielen unabhängigen Pfaden, die nichts voneinander schreiben. Cognitions Warnung zielt aufs Code-Bauen – eng gekoppelt, mit gemeinsamem Zustand, wo widersprüchliche Annahmen zweier Agenten direkt im Ergebnis landen. Beide haben recht, nur über verschiedene Aufgaben. Bezeichnend ist die Einigkeit am Streitpunkt selbst: Auch Anthropic merkt an, dass Coding-Aufgaben weniger echt parallelisierbare Teile haben als Recherche.

Und genau hier schließen die Git-Worktrees die Lücke. Cognitions Einwand – paralleles Schreiben erzeugt geteilten Zustand und damit Konflikte – gilt nur, solange sich die Agenten einen Arbeitsbereich teilen. Isoliert man jeden Fix in einem eigenen Branch, verschwindet der geteilte Zustand, und auch Code-Aufgaben lassen sich vorsichtig aufteilen. So ist die Lehre kein „pro“ oder „contra“ Multi-Agenten, sondern eine Entscheidungsregel: breit-parallel und explorativ entlasten Sub-Agenten, eng-gekoppeltes Schreiben hält man single-threaded – oder man isoliert es sauber, damit es entkoppelt wird.

MerksatzKein echter Widerspruch – Multi-Agenten gewinnen bei breit-paralleler Exploration (Recherche, Review), verlieren bei eng-gekoppeltem Schreiben mit geteiltem Zustand. Worktree-Isolation öffnet auch Code-Aufgaben vorsichtig fürs Parallelisieren.

Multi-Agenten im Maßstab: Anthropic vs. Cognition →

Praxis-Einordnung: weniger ist mehr, Kosten ehrlich rechnen

Zum Schluss die nüchterne Erdung, denn Orchestrierung verführt zum Overengineering. Praktiker berichten übereinstimmend von einer Tendenz „weniger ist mehr“: Native Bordmittel – Sub-Agenten, Worktrees, die eingebauten Workflow-Muster – verdrängen zunehmend aufgesetzte Orchestrierungs-Frameworks; einen zusätzlichen Layer sollte man nur mit gutem Grund einziehen. In einer Eigenmessung eines vielbeachteten Kanals erledigte ein schlanker Standard-Lauf eine Aufgabe in rund 20 Minuten mit etwa 200.000 Tokens, während ein schweres Orchestrierungs-Framework für dasselbe Ergebnis rund 105 Minuten und 1,2 Mio Tokens brauchte – nicht schlechter in der Qualität, aber deutlich teurer in Zeit und Tokens. Das ist eine Einzelmessung (n=1) und kein Benchmark, illustriert aber die Größenordnung.

Die Kostenseite verdient denselben Realismus, den der Kanon dem Research-System gibt: Multi-Agenten-Systeme verbrauchen rund 15× so viele Tokens wie ein normaler Chat, und dieser Token-Verbrauch erklärt schon allein etwa 80 % der Leistungsvarianz. Die Rechnung geht nur auf, wenn der Wert der Aufgabe hoch genug ist, um diese Tokens zu bezahlen. Wie groß die Zahlen werden können, deutet ein Demo-Lauf an, in dem ein einziger Workflow über hundert Agenten und mehrere Millionen Tokens in gut zehn Minuten verfeuerte – eine Praktiker-Anekdote zur Veranschaulichung der Dimension, keine harte Kennzahl.

Die Synthese aller Befunde ist überraschend einig: Strebe nach der einfachsten Orchestrierung, die die Aufgabe löst. Setze Sub-Agenten für Zuarbeit ein, reserviere echte Parallelität für breit-explorative oder sauber isolierte Arbeit, bevorzuge wenige verschiedene Agenten vor vielen gleichen, und gib jedem Multi-Agenten-System eine klare Hierarchie mit Verifikation. Mehr Agenten sind ein Werkzeug, kein Ziel – und das teuerste Werkzeug im Kasten.

MerksatzStrebe nach der einfachsten Orchestrierung, die reicht – native Features vor Add-on-Frameworks, wenige verschiedene Agenten vor vielen gleichen, klare Hierarchie mit Verifikation. Multi-Agenten kosten rund 15× Tokens; nur einsetzen, wenn die Aufgabe es wert ist.

Agenten: wann sich Multi-Agent lohnt →