Ein Agent plant. Zwei implementieren. Einer schreibt Tests. Ein weiterer sucht Sicherheitsprobleme. Nach wenigen Minuten liegen fünf Ergebnisse vor – und im schlechtesten Fall widersprechen sie sich. Aus einem Entwickler wird plötzlich ein Teamleiter. Genau darin liegt das Versprechen von Agent Teams in Claude Code. Und genau dort beginnt auch ihr Risiko.
Die entscheidende Frage ist nicht, wie viele Agenten ich starten kann. Sie lautet: Welche Teile der Arbeit können wirklich unabhängig voneinander vorankommen? Agent Teams sind kein automatischer Produktivitätsmultiplikator. Wenn Schnittstellen fehlen, mehrere Agenten dieselben Dateien untersuchen oder der Koordinator jede Entscheidung erneut erklären muss, wird ein schwacher Plan lediglich parallel ausgeführt – schneller, aber deutlich teurer.
Meine Leitthese: Nicht nach Aufgabenmenge parallelisieren, sondern nach Unabhängigkeit. Erst wenn mehrere Stränge ohne gegenseitiges Warten ein überprüfbares Ergebnis liefern können, ist ein Agent Team die richtige Wahl.
Was Agent Teams in Claude Code sind
Anthropic beschreibt Agent Teams als mehrere koordinierte Claude-Code-Instanzen. Eine Session übernimmt die Rolle des Team Leads, startet Teammates, verteilt Aufgaben und führt Ergebnisse zusammen. Die Teammates arbeiten jeweils in einem eigenen Kontextfenster. Eine gemeinsame Aufgabenliste und ein Nachrichtensystem erlauben ihnen, Arbeit zu übernehmen, Abhängigkeiten zu erkennen und direkt miteinander zu kommunizieren.
Das ist mehr als eine einzelne Session mit mehreren Prompts. Jeder Teammate besitzt einen eigenen Arbeitsverlauf und kann mit einer wiederverwendbaren Rollenbeschreibung, einem Modell sowie eingeschränkten Werkzeugen und Berechtigungen gestartet werden. Typische Rollen sind Architektur, Backend, Frontend, Test Engineering, Security Review, Code Review oder Dokumentation.
Wichtig für die Einordnung: Agent Teams sind laut aktueller Claude-Code-Dokumentation experimentell und standardmäßig deaktiviert. Sie werden über CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS aktiviert. Das ist kein Gegenargument für ihren Einsatz, aber ein klares Signal: Teams sollten kontrolliert erprobt und nicht ungeprüft zum Standard für jede Änderung gemacht werden.
Session, Subagents und Agent Teams unterscheiden
| Ansatz | Zusammenarbeit | Geeignet für | Aufwand |
|---|---|---|---|
| Eine Session | Planung und Ausführung bleiben im selben Kontext. | Kleine, lineare und klar abgegrenzte Aufgaben. | Am geringsten. |
| Subagents | Isolierte Helfer arbeiten in eigenem Kontext und liefern eine Zusammenfassung an die Hauptsession. | Recherche, Tests, Reviews und Analyse großer Verzeichnisse. | Mehr Kontext, aber wenig Abstimmung untereinander. |
| Agent Teams | Eigenständige Sessions teilen Aufgaben und können direkt miteinander kommunizieren. | Mehrere unabhängige Stränge mit gemeinsamem Gesamtziel. | Höchste Kosten und Koordination. |
Subagents sind sinnvoll, wenn nur das Ergebnis einer Nebenaufgabe zählt. Sie halten lange Rechercheergebnisse oder Testprotokolle aus dem Hauptkontext heraus. Agent Teams gehen weiter: Teammates können Erkenntnisse austauschen, einander widersprechen und ihre Arbeit über eine gemeinsame Aufgabenliste koordinieren. Genau diese Zusammenarbeit ist wertvoll – und erzeugt zusätzlichen Nachrichten-, Kontext- und Bewertungsaufwand.
Das Versprechen: reale Wartezeit verkürzen
Softwareentwicklung wird nicht schneller, weil mehr Text generiert wird. Sie wird schneller, wenn voneinander unabhängige Ergebnisse gleichzeitig entstehen. Ein Agent kann eine Komponente implementieren, während andere Tests ergänzen, Sicherheitsrisiken untersuchen, Dokumentation aktualisieren oder eine konkurrierende Lösung bewerten.
Besonders attraktiv ist das bei großen, modularen Codebasen. Security, Performance und Testabdeckung lassen sich als getrennte Review-Perspektiven parallel untersuchen. Mehrere unabhängige Module können gleichzeitig migriert werden. Unterschiedliche Hypothesen für einen schwer reproduzierbaren Fehler können bewusst gegeneinander antreten. Der Mensch verschiebt sich dabei vom Ausführenden zum Koordinator und Entscheider.
Ein sinnvoller Praxistest
Ein belastbares Experiment braucht eine Aufgabe, die groß genug für Arbeitsteilung ist, aber klare Grenzen besitzt. Ein geeignetes Beispiel wäre: Eine bestehende Anwendung erhält Authentifizierung, Rollen und Audit-Logging. Frontend, Backend, Security, Tests und Dokumentation sind beteiligt, zugleich lassen sich Schnittstellen und Abnahmekriterien vorab definieren.
Der Architekt sollte nicht tagelang planen, während alle anderen warten. Er muss zuerst einen kleinen, belastbaren Vertrag liefern: Datenmodell, API, Zuständigkeiten, betroffene Komponenten und offene Risiken. Danach können Backend und Frontend parallel arbeiten. Tests und Security Review können früh vorbereitet werden, ihre vollständige Ausführung hängt aber weiterhin von der Implementierung ab.
Welche Werte wirklich gemessen werden müssen
Ein schneller erster Diff ist noch kein Produktivitätssprung. Gemessen werden sollten die Gesamtdauer bis zu einem lauffähigen Ergebnis, die Zeit bis zum ersten funktionierenden Zwischenstand, Tokenverbrauch und Kosten, erfolgreiche und fehlgeschlagene Tests sowie die Zahl der Korrekturschleifen.
Dazu kommen die typischen Mehragenten-Kosten: Merge-Konflikte, doppelt ausgeführte Arbeit, menschliche Eingriffe und Zeit für das Zusammenführen. Am Ende zählt das Verhältnis zwischen eingesparter Kalenderzeit und zusätzlichen Kosten – bei mindestens gleicher Qualität und Sicherheit. Ohne eine Ein-Agent-Baseline bleibt jede Aussage über den Produktivitätsgewinn Bauchgefühl.
Wo der Produktivitätssprung entsteht
Agent Teams funktionieren am besten, wenn Schnittstellen vor dem Start klar sind, jede Rolle ein eindeutiges Ergebnis besitzt und automatisierte Tests schnelles Feedback liefern. Ein modularer Bestand verstärkt den Effekt: Wer getrennte Komponenten bearbeitet, muss seltener dieselben Dateien anfassen und blockiert andere nicht mit einer ausstehenden Entscheidung.
Gute Aufgaben benennen Ziel, betroffene Dateien oder Komponenten, erwartetes Ergebnis, Abhängigkeiten, erlaubte Werkzeuge und Abnahmekriterien. „Verbessere die Authentifizierung“ ist zu vage. „Implementiere die serverseitige Rollenprüfung für die drei vorhandenen API-Routen, ändere keine Frontend-Dateien und erhalte alle bestehenden Tests“ ist delegierbar.
Geeignet sind deshalb parallele Code-Reviews, unabhängige Security-, Performance- und Testanalysen, die Migration klar getrennter Module, konkurrierende Lösungsskizzen sowie Tests und Dokumentation, die parallel zur Implementierung entstehen können.
Wo die Tokenverbrennung beginnt
Jeder Teammate ist eine eigene Claude-Instanz mit eigenem Kontextfenster. Anthropic weist ausdrücklich darauf hin, dass Agent Teams deutlich mehr Tokens als eine einzelne Session verbrauchen und die Nutzung mit der Zahl aktiver Teammates steigt. Gleichzeitig wachsen Koordinationsaufwand und Konfliktrisiko; zusätzliche Agenten beschleunigen die Arbeit ab einem Punkt nicht mehr proportional.
Warnsignale sind leicht zu erkennen: Drei Agenten ändern dieselbe Datei. Aufgaben werden doppelt übernommen. Teammates lesen identische Verzeichnisse ein. Der Lead verbringt mehr Zeit mit Statusmeldungen als mit Entscheidungen. Agenten warten auf dieselbe Architekturentscheidung oder eine einfache Änderung wird künstlich in fünf Pakete zerlegt.
Auch der Koordinator ist nicht kostenlos. Er muss Ergebnisse lesen, Annahmen prüfen, Konflikte lösen und neue Prompts formulieren. Fünf Antworten sind nur dann besser als eine, wenn sie fünf unterschiedliche Risiken reduzieren oder fünf unabhängige Liefergegenstände erzeugen. Ansonsten bezahlen Teams mehrfach für dieselbe Orientierung.
Tokenverbrauch kontrollieren
Die wichtigste Maßnahme ist unspektakulär: erst planen, dann Agenten starten. Nicht vorsorglich fünf Teammates erzeugen, wenn zwei ausreichen. Recherche und Umsetzung sollten getrennt, Verantwortungen klein und Rückgaben strukturiert sein: geänderte Dateien, getroffene Entscheidungen, offene Risiken, Testergebnisse und nächste Schritte.
CLAUDE.md sollte kurze, dauerhaft relevante Projektregeln enthalten. Umfangreiche Verfahren und Referenzen passen besser in Skills, deren vollständiger Inhalt erst bei Nutzung geladen wird. Kleine isolierte Prüfungen gehören zu Subagents. Agent Teams sind für Aufgaben reserviert, in denen direkte Zusammenarbeit oder eine gemeinsame Aufgabenliste tatsächlich benötigt werden.
Auch spezialisierte Kontextwerkzeuge können Orientierungskosten senken. Das Open-Source-Projekt Graft berichtet in einem eigenen kontrollierten Benchmark mit 162 Läufen von 42 Prozent weniger Tokens, wenn Claude Code vorab einen strukturierten Codebasis-Kontext erhielt. Das ist ein Herstellerwert aus einem begrenzten Versuchsaufbau, keine allgemeine Garantie. Er illustriert aber einen wichtigen Punkt: Wiederholtes Einlesen derselben Codebasis ist messbarer Overhead.
Hooks, Skills und MCP als Qualitätsfilter
Hooks führen Aktionen an definierten Punkten im Claude-Code-Lebenszyklus aus. Sie können nach Änderungen formatieren und testen, vor gefährlichen Befehlen blockieren oder bei abgeschlossenen Aufgaben benachrichtigen. Für zwingende, deterministische Kontrollen sind sie verlässlicher als die Hoffnung, dass ein Agent freiwillig immer denselben Prüfschritt auswählt.
Skills kapseln wiederverwendbare Anweisungen und Arbeitsabläufe, beispielsweise für Security Reviews, Deployment, API-Konventionen oder Teststrategien. Der Vorteil für Teams: Rollen müssen umfangreiche Regeln nicht jedes Mal neu im Prompt erhalten; relevante Verfahren werden gezielt geladen.
MCP verbindet Claude Code mit externen Werkzeugen und Datenquellen wie GitHub, Datenbanken, Ticketsystemen oder Observability. MCP stellt Fähigkeiten bereit, erzwingt aber nicht automatisch deren Nutzung. Berechtigungen sollten deshalb pro Rolle begrenzt werden. Ein Test-Agent braucht selten Produktionszugriff, ein Reviewer nicht automatisch Schreibrechte.
Die praktische Entscheidungsregel
Ein Agent Team ist eine gute Wahl, wenn mehrere klar trennbare Stränge gleichzeitig vorankommen können, Zeit wichtiger als minimale Kosten ist und ein Mensch Architekturentscheidungen oder Konflikte schnell klären kann. Ein einzelner Agent bleibt besser für kleine Änderungen, eng gekoppelte Dateien, sequenzielle Arbeit, unklare Anforderungen oder Projekte ohne automatisierte Tests.
Risiken jenseits der Kosten
Mehr parallele Schreibzugriffe erhöhen das Konfliktrisiko. Eigenständige Agenten können widersprüchliche Architekturentscheidungen treffen. Externe Werkzeuge erweitern die Angriffsfläche, und zu breite Berechtigungen können sensible Daten oder produktive Systeme unnötig exponieren.
Deshalb benötigt auch agentisch erzeugter Code Tests, menschliches Review, eine Sicherheitsprüfung und nachvollziehbare Änderungen. Rollen sollten nach dem Least-Privilege-Prinzip nur die Werkzeuge und Daten sehen, die sie wirklich benötigen. Autonomie verteilt Arbeit – Verantwortung bleibt beim Menschen.
Fazit: Geschwindigkeit braucht Grenzen
Agent Teams können die reale Entwicklungszeit deutlich verkürzen. Der größte Gewinn entsteht bei unabhängigen, überprüfbaren Aufgaben mit stabilen Schnittstellen. Genau dort können Architektur, Implementierung, Tests und Reviews wirklich gleichzeitig vorankommen.
Die Tokenkosten steigen dabei nicht nur durch mehr Ausführung, sondern auch durch mehrfach geladenen Kontext, Kommunikation und die Arbeit des Koordinators. Schlechte Planung wird durch Parallelität nicht besser, sondern nur schneller und teurer. Für viele Alltagsaufgaben reicht deshalb ein Hauptagent mit gezielten Subagents.
Mein Fazit: Agent Teams sind ein Produktivitätssprung, wenn die Arbeit parallelisierbar ist. Ohne klare Rollen, Schnittstellen und Abnahmekriterien werden sie zur Tokenverbrennung.
Kurz erklärt
Weiterführende Quellen
- Anthropic: Agent Teams in Claude Code
- Anthropic: Subagents, Agent Teams und parallele Arbeit vergleichen
- Anthropic: Eigene Subagents erstellen
- Anthropic: Workflows mit Hooks automatisieren
- Anthropic: CLAUDE.md, Skills, MCP, Subagents und Hooks einordnen
- NanoNets: Graft und der veröffentlichte Token-Benchmark
- Mein früherer Artikel: Wann sich KI-Agenten rechnen
- Mein früherer Artikel: Git Worktrees – Der Parallelmodus für Coding-Agenten