Claude Code Agent Teams: wann parallele Agenten sich lohnen und wie du sie prüfst

Kurz gesagt

Claude Code Agent Teams lassen mehrere Claude-Code-Sitzungen gleichzeitig an einer Codebasis arbeiten: eine Leitung, mehrere Teammitglieder, eine gemeinsame Aufgabenliste. Das lohnt sich bei Arbeit, die sich sauber trennen lässt, und nur, wenn eine eigene Prüfung das Ergebnis kontrolliert.

  • Die Kosten wachsen mit der Teamgröße: fünf Teammitglieder kosten etwa fünf Sitzungen.
  • Gut geeignet: paralleles Review, konkurrierende Fehlertheorien, Funktionen in getrennten Modulen.
  • Es bricht, wenn zwei Teammitglieder dieselbe Datei ändern.
  • Stand November 2026 ist die Funktion experimentell und standardmäßig aus.

Agent Teams kamen am 5. Februar 2026 in Claude Code, zusammen mit Claude Opus 4.6 (heise online). Neun Monate später nennt die offizielle Dokumentation die Funktion immer noch experimentell. Einschalten ist eine Einstellung. Schwieriger sind zwei andere Entscheidungen: wann ein Team das Fünffache an Tokens wert ist, und wie du herausfindest, ob seine Arbeit stimmt.

Was Claude Code Agent Teams sind

Eine normale Claude-Code-Sitzung ist ein Agent mit einem Kontextfenster. Ein Claude Code Agent Team besteht aus mehreren vollständigen Sitzungen, die gleichzeitig am selben Projekt arbeiten. Die Dokumentation nennt vier Teile:

  • Die Leitung: deine Hauptsitzung. Sie legt Aufgaben an, startet Teammitglieder und führt die Ergebnisse zusammen.
  • Die Teammitglieder: eigene Claude-Code-Instanzen, jede mit eigenem Kontextfenster.
  • Die Aufgabenliste: gemeinsame Arbeitspakete, offen, in Arbeit oder erledigt. Eine Aufgabe kann auf eine andere warten.
  • Das Postfach: jeder Agent kann jedem anderen eine Nachricht schicken.

Der Unterschied zu Subagenten liegt darin, wer mit wem spricht. Ein Subagent erledigt einen Auftrag und meldet sich bei der Sitzung zurück, die ihn gestartet hat. Teammitglieder schreiben einander, widersprechen sich und holen sich selbst die nächste offene Aufgabe. Jedes lädt den Projektkontext (CLAUDE.md, MCP-Server, Skills), aber nicht das Gespräch der Leitung. Es kennt also nur das Projekt und den Auftrag, den die Leitung ihm gibt.

Claude Code hat heute drei Wege, Agenten parallel laufen zu lassen, und die Wahl entscheidet über die Kosten:

Subagenten Agent Teams Dynamic Workflows
Wer koordiniert Die Hauptsitzung Ein leitender Agent Ein Skript, das Claude schreibt
Sprechen die Agenten miteinander Nein, sie melden zurück Ja Nein
Typische Größe Einige pro Runde 3 bis 5 Dutzende bis Hunderte
Tokenkosten Am niedrigsten Eine volle Sitzung pro Mitglied Am höchsten pro Lauf

Wann parallele Agenten sich lohnen

Die Dokumentation nennt vier starke Fälle.

Paralleles Review: Ein einzelner Prüfer rutscht in eine Sorte Fehler. Drei Teammitglieder mit getrennten Blickwinkeln, Sicherheit, Geschwindigkeit und Testabdeckung, lesen dieselbe Änderung gleichzeitig, und die Leitung führt die Befunde zusammen.

Konkurrierende Hypothesen: Ist die Ursache eines Fehlers unklar, findet ein Agent eine plausible Erklärung und hört auf zu suchen. Die Dokumentation nennt das Ankern. Drei bis fünf Teammitglieder mit je einer Theorie und dem Auftrag, sich gegenseitig zu widerlegen, halten die Suche offen.

Funktionen in Modulen: Backend, Frontend und Tests, jedes Teil gehört einem Teammitglied. Das klappt nur, wenn die Teile wirklich getrennt sind.

Recherche vor Code: Ein Vergleich von Bibliotheken oder eine Fehlersuche schreibt keinen Code, also kann nichts kollidieren. Die Dokumentation empfiehlt, dort anzufangen.

Für Arbeit in fester Reihenfolge, mit vielen Abhängigkeiten oder mit Änderungen, die sich in einer Datei ballen, rät die Dokumentation zu einer einzelnen Sitzung.

Was Agent Teams kosten

Jedes Teammitglied ist eine vollständige Claude-Instanz. Die Kostenseite von Anthropic sagt: Der Tokenverbrauch wächst ungefähr mit der Teamgröße und mit der Laufzeit jedes Mitglieds. Über die API ist das die Rechnung. Auf einem Team- oder Enterprise-Platz ist es dein Nutzungslimit, das entsprechend schneller aufgebraucht ist.

Vier Einstellungen entscheiden den größten Teil der Rechnung:

  • Modell pro Teammitglied: nenne es im Auftrag („nutze Sonnet für jedes Teammitglied“). Die Kostenseite empfiehlt Sonnet für die Mitglieder und das stärkere Modell für die Leitung.
  • Teamgröße: fang mit 3 bis 5 Mitgliedern und 5 bis 6 Aufgaben pro Mitglied an. Drei gezielte Mitglieder schlagen fünf verstreute.
  • Beenden: Ein untätiges Mitglied hält seinen Kontext, bis es beendet wird. Stopp es, wenn seine Arbeit fertig ist.
  • Zwischenspeicher: Der Prompt-Cache eines Mitglieds hält standardmäßig fünf Minuten. Wartet es länger, zahlt es für den Neuaufbau. subagentPromptCacheTtl auf 1h hält ihn länger, über die API zu einem höheren Schreibpreis.

Unsere Regel: Ein Team lohnt sich, wenn die Arbeit sonst in einer Warteschlange liegen würde. Schafft eine Sitzung sie an einem Nachmittag, macht ein Team sie nur teurer. Was Tokens in einem Betrieb kosten, mit gerechneten Beispielen, steht in Was kostet Claude im Betrieb.

Wie du prüfst, was ein Team gebaut hat

Ein größeres Team erzeugt mehr Ergebnis, und nichts im Aufbau macht dieses Ergebnis richtiger. Die Leitung fasst zusammen, und eine Zusammenfassung ist die Meinung des Schreibers darüber, was wichtig war. Über die Qualität entscheidet, wer das Ergebnis prüft, und woran.

Die erste Prüfung ist ein Prüfer, der die Arbeit nicht gemacht hat. Wenn das Team fertig ist, bewertet ein eigener Agent mit frischem Kontext und reinem Lesezugriff die Änderung gegen eine kurze Liste: Die Tests laufen durch, der Auftrag ist erfüllt, keine Datei außerhalb des vereinbarten Bereichs wurde geändert. Er kann dasselbe Modell mit denselben Prompts nutzen. Nützlich ist er, weil er keine eigene Arbeit zu verteidigen hat. Ich nenne das Loop Engineering, und so betreiben wir Agenten in den Systemen unserer Kunden.

Die zweite sind Hooks. Claude Code löst TaskCreated, TaskCompleted und TeammateIdle aus. Ein Hook, der mit Exit-Code 2 endet, stoppt die Aufgabe und schickt eine Rückmeldung. Dort gehören ein Testlauf, eine Stilprüfung oder die Kontrolle hin, dass das Mitglied nur seine eigenen Dateien angefasst hat. Der Planmodus ersetzt das nicht: Claude Code genehmigt den Plan eines Mitglieds automatisch, solange du seinen Berechtigungsmodus nicht änderst. Der Plan bringt das Mitglied zum Nachdenken, geprüft wird er von niemandem.

Die dritte sind Berechtigungen. Teammitglieder übernehmen den Berechtigungsmodus der Leitung. Läuft die Leitung ohne Rückfragen, laufen alle Mitglieder ohne Rückfragen. Leg die erlaubten Befehle fest, bevor das Team startet, nicht während fünf Agenten auf eine Freigabe warten.

Wo Agent Teams brechen

Zwei Agenten, eine Datei. Die Aufgabenliste ist gesperrt, damit zwei Mitglieder nicht dieselbe Aufgabe nehmen. Deine Quelldateien sind es nicht. Ändern zwei Mitglieder eine Datei, gewinnt der spätere Schreibvorgang. Eigene Git-Arbeitskopien bekommen die Mitglieder auch nicht. Die Abhilfe ist Planung: Jedes Mitglied besitzt eine Gruppe von Dateien, und eine zweite Änderung an derselben Datei wartet auf die erste.

Fortsetzen. /resume und /rewind holen Teammitglieder im Terminal nicht zurück. Nach dem Fortsetzen schreibt die Leitung womöglich an Mitglieder, die es nicht mehr gibt. Sag ihr, sie soll neue starten.

Veralteter Aufgabenstatus. Mitglieder vergessen manchmal, eine Aufgabe als erledigt zu markieren, und alles, was darauf wartet, bleibt blockiert. Prüf die Arbeit und setz den Status, oder lass die Leitung nachhaken.

Eine Leitung, die selbst programmiert statt zu leiten. Die Abhilfe aus der Dokumentation ist ein Satz im Auftrag: „Warte, bis deine Teammitglieder ihre Aufgaben erledigt haben, bevor du weitermachst.“

Feste Form. Eine Sitzung hat ein Team, Mitglieder können keine eigenen Teams starten, und die Leitung bleibt bis zum Ende der Sitzung die Leitung.

Schwärme, und wann ein Agent gewinnt

Jenseits von Teams kommen Schwärme. Seit Mai 2026 kann Claude Code Dynamic Workflows ausführen: Claude schreibt ein Skript, und eine Laufzeit startet daraus viele Subagenten. Das Schlüsselwort ultracode in einem Prompt startet einen solchen Lauf. Die Grenzen standardmäßig: 16 Agenten gleichzeitig, 1.000 pro Lauf, mit einer Warnung ab 25 Agenten oder rund 1,5 Millionen Tokens.

Ich habe einen Lauf mit rund 200 Subagenten gemacht, jeder mit einer eigenen Idee, wie sich das Ergebnis eines Agenten in einer Bewertung verbessern lässt. Zwei Dinge habe ich daraus mitgenommen. Erstens: Prüf das Modell. Einige Subagenten liefen auf Haiku statt auf Opus, ohne Fehlermeldung, nur mit schwächerer Arbeit. Nenn das Modell im Prompt. Zweitens zählt der Auftrag mehr als die Anzahl. Ein vager Prompt brachte 200 Fassungen derselben Idee, eine scharfe Rolle und eine These pro Agent brachten Ergebnisse, die sich zu lesen lohnten. Ein genauer Lauf mit 20 Agenten schlägt einen vagen mit 200.

Jede Übergabe zwischen Agenten ist eine Zusammenfassung, und eine Zusammenfassung lässt weg, was ihr Schreiber für unwichtig hielt. Ein Agent, der stornierte Bestellungen herausfiltert, bevor er die Daten weitergibt, macht den nächsten Agenten blind dafür. Die Antwort am Ende sieht richtig aus und ist falsch. Wo Details zusammenhängen, schlägt ein Agent, der Rohdaten, Regeln und Frage zugleich sieht, ein Team, das sich Notizen zuschiebt.

Einrichtung in zwei Minuten

Agent Teams bleiben verborgen, bis eine Umgebungsvariable gesetzt ist, am besten in settings.json:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Dann beschreibst du die Rollen in normaler Sprache:

Erstelle ein Agent Team für den Umbau der Anmeldung: ein Teammitglied
für die JWT-Logik im Backend, eines für die Sitzungen im Frontend,
eines schreibt Integrationstests. Nutze Sonnet für jedes Teammitglied.

Zwei Details überraschen viele. Solange Teams an sind, startet ein Subagent, dem Claude einen Namen gibt, als Teammitglied. Ein Team kann also entstehen, ohne dass du darum bittest; die Variable auf 0 schaltet zurück. Und Teams brauchen eine interaktive Sitzung: claude -p und Sitzungen über das Agent SDK starten keine Mitglieder. Die Mitglieder erscheinen in einer Leiste unter der Eingabe. Die Pfeiltasten wählen eines aus, x stoppt es, Strg+T zeigt die Aufgabenliste. Geteilte Fenster brauchen tmux oder iTerm2.

Was das für einen Betrieb heißt

Agent Teams sind eine Funktion für Entwickler. Sie machen eine bestimmte Art Arbeit schneller: ein Review aus drei Blickwinkeln, eine Fehlersuche, eine Funktion in sauberen Teilen. Eine unklare Aufgabe bleibt unklar, und ein Team mit vagem Auftrag verbraucht dafür das Fünffache an Tokens.

Bevor jemand ein Team auf deinen Code ansetzt, sollten drei Antworten klar sein. Welcher Agent besitzt welche Dateien? Was prüft das Ergebnis, ohne es selbst erzeugt zu haben? Wer entscheidet, wann das Team aufhört? Mit diesen Antworten spart ein Team bei der richtigen Aufgabe Tage. Ohne sie ist eine gut instruierte Sitzung billiger und sicherer.

Genau diesen Aufbau, Agenten mit klaren Grenzen, einer eigenen Prüfung und einer Abbruchbedingung, bauen wir bei KI-Agenten entwickeln. Wenn du zuerst wissen willst, welche deiner Abläufe sich sauber genug für parallele Agenten trennen lassen, fang mit der KI-Beratung an.