Kurs
In groß angelegten Anwendungen oder Enterprise-Setups füllt sich der Kontext schneller, als du denkst. Eine wichtige Designentscheidung von vor einer Stunde ist wahrscheinlich schon wieder aus dem Kontext gefallen – also musst du Dinge ständig neu erklären, die das Modell bereits bearbeitet hatte. Du machst im Grunde vieles richtig, aber du verlangst von einem einzelnen Assistenten die Arbeit eines ganzen Teams.
Genau hier setzen Claude Code Agent Teams an. Anstatt eine einzige Sitzung alles der Reihe nach erledigen zu lassen, startest du mehrere spezialisierte Agenten, die sich eine Aufgabenliste teilen, sich direkt Nachrichten schreiben und Arbeit parallel ausführen.
In diesem Artikel zeige ich dir, wie Agent Teams funktionieren, welche Rolle die einzelnen Spezialisierungen spielen und wie du sie in echten Softwareprojekten koordinierst.
Neu bei Claude Code? Lerne die Grundlagen an einem Nachmittag in unserem Claude Code 101 Kurs.
Was sind Claude Code Agent Teams?
Claude Code Agent Teams sind eine Koordinationsschicht, mit der mehrere Claude-Code-Sitzungen gleichzeitig am selben Projekt arbeiten. Eine Sitzung übernimmt die Rolle der Teamleitung und erstellt weitere Sitzungen, sogenannte Teammitglieder, die bestimmte Teile der Arbeit übernehmen.
Jedes Teammitglied läuft als eigene, vollwertige Claude-Code-Instanz mit eigenem Kontextfenster. Alle teilen sich eine Aufgabenliste, beanspruchen Arbeit, sobald sie verfügbar ist, und schreiben sich bei Bedarf direkt an, um sich abzustimmen.
Das ist mehr als nur zwei Terminal-Tabs zu öffnen und Claude in jedem auszuführen. In getrennten Chats sehen die Sitzungen weder die Fortschritte der anderen noch können sie sich auf die Zuständigkeiten einigen. Ein Agent Team dagegen gibt jeder Sitzung eine gemeinsame Sicht auf die Arbeit und einen Kommunikationskanal. Die Leitung hält alle auf Kurs.
In der Praxis heißt das: Du musst nicht länger Informationen zwischen Sitzungen hin- und hertragen. Das Team koordiniert sich selbst, und du greifst nur ein, um die Richtung vorzugeben und Ergebnisse zu prüfen.
Warum es Agent Teams gibt
Eine einzelne Claude-Code-Sitzung funktioniert gut – bis das Projekt zu groß wird.
Jede Claude-Code-Sitzung hat ein Kontextfenster mit einem Limit. Während der Arbeit füllt es sich mit Dateiinhalten, Konsolenausgaben, Design-Diskussionen und deinem eigenen Hin und Her. Irgendwann fehlen ältere Infos im Kontext und das Modell vergisst Entscheidungen, die es zuvor in derselben Aufgabe getroffen hat.
Drei typische Situationen machen das besonders deutlich:
- Große Repositories: Eine Codebasis mit hunderten Dateien passt nicht komplett in den Kontext. Die Sitzung liest dieselben Dateien immer wieder, verbraucht Tokens und baut Verständnis neu auf, das sie schon hatte.
- Komplexe Projekte: Querschnittsfeatures wie Authentifizierung über Backend, Frontend und Tests verlangen, dass das Modell viele Aspekte gleichzeitig berücksichtigt. Jeder neue Aspekt konkurriert um Platz.
- Mehrere parallele Aufgaben: Eine Sitzung gleichzeitig ein Feature implementieren, ein Modul refaktorisieren, Tests schreiben und Dokus aktualisieren zu lassen, ist eine Einladung zu Problemen.
Die Antwort ist dieselbe, auf die menschliche Teams schon vor Jahrzehnten gekommen sind: Teile die Arbeit auf.
Wenn eine Sitzung bei einer Refaktorierung an ihre Grenzen stößt, gib die Backend-Änderungen an ein Teammitglied, das Frontend an ein anderes und die Tests an ein drittes. Jedes lädt nur, was es für seinen Teil braucht.
Dasselbe gilt für Recherche. Eine Aufgabe mit drei konkurrierenden Hypothesen läuft schneller, wenn drei Teammitglieder jeweils eine Theorie parallel untersuchen und sich anschließend austauschen, statt eine Sitzung alles nacheinander durchzugehen.
Spezialisierung bringt Tiefe, Parallelisierung bringt Geschwindigkeit. In Kombination kannst du Arbeit erledigen, an der eine Einzel-Sitzung sich entweder verirrt oder viel zu lange bräuchte.
Wie Claude Code Agent Teams funktionieren
Eine Teamsitzung durchläuft fünf Phasen, die Orchestrierung übernimmt Claude Code selbst.
- Ziel definieren: Beschreibe in klarer Alltagssprache, was du möchtest – so, wie du eine Junior-Entwicklerin briefen würdest. Die Leitung liest mit und entscheidet, wie das Ziel heruntergebrochen wird.
- Arbeit delegieren: Die Leitung erstellt eine gemeinsame Aufgabenliste und startet Teammitglieder, jeweils mit Name, Rolle und Startprompt. Du kannst die Teamstruktur vorgeben oder die Leitung entscheiden lassen.
- Parallel ausführen: Jedes Teammitglied nimmt Aufgaben auf, markiert sie als in Arbeit, schließt sie ab und setzt sie auf erledigt. Abhängigkeiten werden automatisch beachtet; File-Locking verhindert Konflikte. Teammitglieder können sich direkt Nachrichten schreiben — kein Umweg über die Leitung nötig.
- Ergebnisse zusammenführen: Die Leitung sammelt fertige Arbeit, löst Konflikte und erzeugt ein konsolidiertes Ergebnis: einen PR, Bericht, ein refaktoriertes Modul oder was auch immer das Ziel vorsieht.
- Ergebnis prüfen: Du prüfst das Resultat wie jeden Pull Request: Diff lesen, Code ausführen, Tests checken.
Spezialisierte Rollen in Agent Teams
Rollen geben einem Agent Team Struktur. Ohne sie arbeiten generische Sitzungen an überlappenden Aufgaben. Claude Code liefert keine feste Liste — du definierst Rollen in deinem Briefing oder verweist die Leitung auf eine Subagent-Definition unter .claude/agents/.
Planning Agent
Der Planning Agent bricht das Ziel in Aufgaben herunter, bevor Code geschrieben wird. Er erkundet die Codebasis, mappt Abhängigkeiten und erstellt eine Aufgabenliste mit eigenständigen Einheiten, die ein Teammitglied ohne ständiges Nachfragen erledigen kann.
In der Praxis übernimmt oft die Teamleitung diese Rolle. Bei größerem Umfang lohnt sich ein eigenes Planungsmitglied.
Coding Agent
Der Coding Agent schreibt die Implementierung. Die meisten Teammitglieder werden Coding Agents sein, jeweils für einen klar abgegrenzten Bereich — Backend, Frontend, Datenbank, KI-Features. Wichtig ist, Überschneidungen zu vermeiden: Bearbeiten zwei Mitglieder dieselbe Datei, überschreiben sie sich gegenseitig.
Coding Agents funktionieren gut auf günstigeren Modellen. Viele setzen die Leitung auf Opus und die Teammitglieder auf Sonnet, da die Ausführung weniger Tiefgang benötigt als die Koordination.
Testing Agent
Der Testing Agent schreibt und führt Tests aus. Er kann gegen einen abgestimmten API-Vertrag arbeiten, während der Coding Agent den Endpoint noch baut — wenn der Code landet, sind die Tests bereits da.
Du kannst auch einen Testing Agent die ganze Sitzung über laufen lassen, der die Suite jedes Mal erneut ausführt, wenn ein Coding Agent eine Aufgabe abschließt.
Review Agent
Der Review Agent liest Diffs und markiert Bugs, Stilfragen, fehlende Edge-Cases und Sicherheitsprobleme. Besonders effektiv ist es, Reviews auf zwei Teammitglieder mit unterschiedlichen Blickwinkeln aufzuteilen — z. B. Sicherheit und Performance — und die Leitung führt die Ergebnisse zusammen.
Wenn du bereits eine Subagent-Definition für dein Projekt hast, erbt das Teammitglied automatisch dessen Tools und Systemprompt.
Documentation Agent
Der Documentation Agent schreibt Docstrings, README-Updates und längere Dokus wie Architekturnotizen oder API-Referenzen. Er ist ein guter Kandidat als letztes Teammitglied — sobald Coding und Tests fertig sind, ist die endgültige Form klar.
Warum Spezialisierung die Ergebnisse verbessert
Eine Universalsitzung muss Implementierung, Tests, Doku und Review-Feedback gleichzeitig im Kontext halten. Ein spezialisiertes Teammitglied lädt nur, was es braucht – der Kontext bleibt klein, das Denken fokussiert. Debugging wird einfacher: Geht etwas schief, weißt du genau, welche Sitzung du prüfen musst.
Parallele Entwicklung mit Agent Teams
Parallelisierung ist der Kern eines Agent Teams.
Sobald die Leitung die Arbeit in Aufgaben zerlegt und die Teammitglieder gestartet hat, laufen alle gleichzeitig. Jedes Teammitglied ist eine eigene Claude-Code-Sitzung, die Arbeit hängt also nicht an einem einzigen Kontextfenster. Die Gesamtzeit für ein mehrteiliges Feature sinkt von der Summe aller Teile auf die Dauer des langsamsten Teils.
Diese drei Kombinationen funktionieren parallel besonders gut:
- Frontend und Backend parallel: Beim Aufbau eines Features über beide Schichten kann das Backend-Teammitglied den API-Endpoint bauen, während das Frontend-Teammitglied die konsumierende Komponente erstellt. Die Abstimmung läuft per Direktnachrichten. Sobald das Backend- Mitglied die Antwortstruktur festlegt, schickt es sie an das Frontend – beide arbeiten weiter, ohne auf das komplette Ende des anderen zu warten.
- Implementierung und Tests parallel: Der Coding Agent schreibt die Implementierung, während der Testing Agent Tests gegen den vereinbarten Vertrag erstellt. Wenn der Coding Agent fertig ist, sind die Tests bereits startklar. Das ist deutlich schneller als erst Code, dann zum Schluss Tests.
- Dokumentation und Code-Review parallel: Sobald ein Coding Agent einen Teil abschließt, kann der Documentation Agent Docstrings und README-Updates schreiben, während der Review Agent das Diff auf Bugs und Stil prüft. Beides blockiert sich nicht und die Leitung führt die Ergebnisse zusammen.
Die Grenze sind Dateikonflikte. Schreiben zwei Teammitglieder zeitgleich in dieselbe Datei, überschreiben sie sich. Die Leitung muss daher entlang von Datei- oder Modulgrenzen aufteilen. Solange die Schnittstellen sauber sind, kannst du so viele Teammitglieder parallel laufen lassen, wie es die Aufgabenliste hergibt.
Claude Code Agent Teams für große Codebasen
Bei großen Codebasen sind Agent Teams eher Pflicht als Nice-to-have.
Ein Repository mit hunderten oder tausenden Dateien passt nicht in ein einziges Kontextfenster. Eine Einzelsitzung verbrät in großen Codebasen viel Budget damit, den Code immer wieder neu zu entdecken.
Mit Agent Teams lädt jedes Teammitglied nur die Dateien, die für seinen Bereich relevant sind – das Kontextfenster bleibt klein und fokussiert. Das Team als Ganzes kann über das gesamte Repository nachdenken, aber keine einzelne Sitzung muss das allein stemmen.
Am wichtigsten ist das in drei Fällen:
- Querschnittsänderungen: Eine Refaktorierung, die Dutzende Dateien in mehreren Modulen berührt, ist für eine Einzel-Sitzung schwer zu überblicken. Aufteilung nach Modulen und Zuweisung an Teammitglieder hält den Umfang je Mitglied beherrschbar.
- Repository-weite Audits: Sicherheitsreviews oder Performance-Audits in großen Codebasen profitieren von mehreren parallelen Teammitgliedern, die jeweils einen anderen Teil betrachten. Die Leitung fasst anschließend alles in einem Bericht zusammen.
- Langlaufende Projekte: In mehrwöchigen Projekten sammelt sich Kontext an, den eine einzige Sitzung nicht halten kann. Agent Teams ermöglichen Checkpoints, für die jeweils ein Teammitglied zuständig ist – ohne alles Vorherige erinnern zu müssen.
Das hat seinen Preis.
Jedes Teammitglied ist eine vollständige Claude-Code-Sitzung mit eigenem Kontextfenster, daher skaliert der Tokenverbrauch linear mit der Teamgröße. Ein Team aus vier Mitgliedern nutzt etwa viermal so viele Tokens wie eine Einzelsitzung für die gleiche Arbeit – manche Schätzungen liegen höher. Der Trade-off: kürzere Durchlaufzeit und mehr Tiefe pro Thema, was sich bei Arbeit auszahlt, die eine Einzelsitzung realistisch nicht schafft.
Je größer das Projekt, desto mehr gewinnst du mit Agent Teams. Aber nutze sie nicht inflationär – für einen kleinen Bugfix ist eine Einzelsitzung günstiger und genauso effektiv.
Agent Teams und Claude Tag
Agent Teams sind nicht der einzige Ansatz von Anthropic, KI in Team-Workflows neu zu denken.
Claude Tag ist eine separate Funktion, die Claude als gemeinsamen Teilnehmer in Slack bringt. Du taggst @Claude in einem Channel, und Claude übernimmt Aufgaben mit den Tools deiner Organisation und dem Kontext des Channels. Es erinnert sich an Diskussionen, folgt eigenständig nach und agiert unter der Identität deiner Organisation.
Beide Funktionen lösen unterschiedliche Koordinationsprobleme. Agent Teams koordinieren mehrere Claude-Code-Sitzungen auf dem Rechner einer Entwicklerin für eine fokussierte Aufgabe. Claude Tag koordiniert eine Claude-Identität über Tage und Wochen hinweg mit einem Team aus Menschen in Slack. Die Richtung ist jedoch identisch: KI entwickelt sich vom Einzelwerkzeug zur aktiven Teilnehmerin im bestehenden Teamworkflow.
Das verändert, worin KI gut sein muss.
Ein Solo-Assistent muss starker Generalist sein. Ein koordiniertes System muss starke Spezialistinnen vereinen, die planen, übergeben, um Hilfe bitten und mit anderen Agenten und Menschen abgestimmt bleiben. Agent Teams leisten das für Claude-Code-Workflows, und Claude Tag macht es im Slack-Workflow sichtbar.
Best Practices für den Aufbau von Agent Teams
Ein gutes Agent-Team-Setup entscheidet sich vor allem in der Vorbereitung. Das Team selbst ist schnell, aber Zeit verlierst du bei schlecht geschnittenen Aufgaben und unklaren Rollen.
Hier ein paar Best Practices:
-
Rollen klar definieren: Jedes Teammitglied sollte einen Fokus und einen klaren Datei-Bereich besitzen. Sag beim Erstellen genau, wofür es zuständig ist, wofür nicht und mit welchen Dateien/Modulen es arbeiten darf. Vage Rollen erzeugen Überschneidungen – und die führen zu Merge-Konflikten.
-
Aufgaben vor der Parallelisierung zerlegen: Erst planen, dann parallelisieren. Führe eine Planungsrunde durch, um Aufgaben mit klaren Inputs, Outputs und Abhängigkeiten zu definieren, und übergib den Plan anschließend zur Ausführung ans Team. Ein Plan kostet ein paar tausend Tokens, ein Team in die falsche Richtung kostet hunderttausende.
-
Standards über CLAUDE.md teilen: Jedes Teammitglied liest beim Start die Datei
CLAUDE.mdim Arbeitsverzeichnis. Lege dort gemeinsame Konventionen fest: Codestil, Dateistruktur, Testansatz, Format für Commit-Messages. -
Review-Checkpoints einbauen: Prüfe den Fortschritt, lenke fehlgeleitete Teammitglieder um und bewerte die Ergebnisse der Leitung vor dem Akzeptieren. Für riskante Aufgaben setze Planfreigabe voraus, bevor Änderungen erfolgen. Dadurch muss das Teammitglied erst den Plan zeigen und auf Freigabe warten.
-
Teamgröße begrenzen: Für die meisten Workflows mit drei bis fünf Teammitgliedern starten. Darüber hinaus wächst der Koordinationsaufwand schneller als der Parallel-Gewinn.
-
Dateikonflikte vermeiden: Teile entlang von Datei- oder Modulgrenzen auf, damit die Verantwortlichkeiten trennscharf sind. Zwei Teammitglieder in derselben Datei überschreiben sich. Muss eine Aufgabe zwingend dieselbe Datei betreffen, führe sie sequenziell statt parallel aus.
-
Übliche Operationen vorab freigeben: Berechtigungsabfragen der Teammitglieder laufen bei der Leitung zusammen, und vier Teammitglieder bedeuten viermal so viele Prompts. Pflege die Liste
permissions.allowvor dem Start, damit Routineaktionen wie Dateien lesen oder Tests ausführen nicht stören. -
Modell an die Rolle anpassen: Lass die Leitung auf einem stärkeren Modell wie Opus laufen, da Koordination von tieferem Reasoning profitiert, und nutze für die Teammitglieder Sonnet zur Ausführung.
Kurzfassung: Erstelle einen detaillierten Arbeitsplan, briefe das Team wie eine kleine Gruppe Junior Engineers, gib klare Verantwortlichkeiten und gemeinsame Standards vor und prüfe die Ergebnisse am Ende. Je näher dein Setup an echter Teamarbeit ist, desto besser performt das Agent Team.
Claude Code Agent Team in der Praxis
Hier ist der komplette Ablauf von Anfang bis Ende.
Ich zeige ein kleines Beispiel: eine "Hello World"-REST-API in FastAPI, die eine Nachricht aus einer SQLite-Datenbank liest, plus eine minimale HTML-Seite, die die API aufruft und das Ergebnis anzeigt. Die App hat eine Backend-Route, eine Datenbankschicht, ein statisches Frontend und eine README-Dokumentation – ideal für ein Viererteam.
Agent Teams aktivieren
Agent Teams sind experimentell und standardmäßig deaktiviert. Du aktivierst sie mit einer Umgebungsvariable – entweder in deiner Shell oder in den Claude-Code-Einstellungen.
Die Einstellungsdatei liegt unter ~/.claude/settings.json. Öffne sie und füge hinzu:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
Wenn du die Datei nicht bearbeiten möchtest, setze die Variable in deiner Shell, bevor du Claude Code startest:
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Beide Wege funktionieren. Sobald die Variable gesetzt ist, erkennt Claude Code teambezogene Prompts und startet die Koordinationsschicht, wenn du sie anforderst.
Claude Code starten und das Team briefen
Erstelle ein leeres Projektverzeichnis und starte Claude Code darin:
mkdir hello-api && cd hello-api
claude
Jetzt briefst du das Team. Der Prompt ist natürliche Sprache, aber je konkreter Rollen und Grenzen, desto besser performt das Team. Hier der Prompt für die Hello-World-API:
Create an agent team to build a small "hello world" REST API.
The project is a FastAPI service that returns a greeting from a SQLite
database, plus a tiny HTML page that calls the API and shows the result.
- One teammate on the database: create app/db.py with a sqlite3 connection
to a greetings.db file. Define a get_greeting() function that returns
the message column from the first row. On import, create the table if
it doesn't exist and seed it with "Hello, World!" if empty.
- One teammate on the backend: build a FastAPI app in app/main.py with
a GET /greeting endpoint that calls get_greeting() from app/db.py.
Add permissive CORS and mount the static/ directory at the root so
the HTML page is served from the same origin.
- One teammate on the frontend: build static/index.html as a single page
that fetches /greeting on load, shows a spinner while loading, displays
the greeting in a centered card on success, and shows an error message
on failure. Inline the CSS and JavaScript.
- One teammate on docs: write README.md with installation, run, and
open-in-browser steps, plus an API reference table. Also create
requirements.txt with fastapi and uvicorn[standard].
Use Sonnet for each teammate. Require plan approval before any teammate
makes changes.
Drei Dinge sind an diesem Prompt bemerkenswert: Die Datei-Grenzen (app/db.py, app/main.py, static/index.html, README.md, requirements.txt) verhindern Überschneidungen. Die Modellwahl (Sonnet) hält die Tokenkosten im Rahmen. Und die Planfreigabe zwingt jedes Teammitglied, seinen Plan zu zeigen, bevor Code geschrieben wird – dein Checkpoint, um Missverständnisse früh zu korrigieren.
Dem Team beim Arbeiten zusehen
Nach dem Absenden zerlegt die Leitung die Arbeit und startet die Teammitglieder. Unten im Terminal erscheint ein Agent-Panel mit einer Zeile pro Teammitglied.
Erstellte Agenten
Jede Zeile zeigt den Namen und die aktuelle Tätigkeit des Teammitglieds. Die Leitung füllt die gemeinsame Aufgabenliste und weist Aufgaben abhängig von Abhängigkeiten zu oder gibt sie frei. Das Backend wartet auf die Datenbankschicht, weil es get_greeting() daraus importiert. Die Doku wartet, bis genug fertig ist, um korrekt zu beschreiben.
Du kannst dir auch die Aufgabenliste anzeigen lassen. Drücke Strg+T zum Umschalten. Die Liste zeigt jede Aufgabe, ihren Status (ausstehend, in Arbeit, abgeschlossen) und das zuständige Teammitglied.
Zwischen Teammitgliedern wechseln
Jedes Teammitglied ist eine vollwertige Claude-Code-Sitzung, und du kannst mit jedem sprechen.
Wähle im Agent-Panel mit den Pfeiltasten ein Teammitglied aus und drücke Enter, um sein Transkript zu öffnen. Du befindest dich nun in dessen Sitzung – alles, was du tippst, geht an dieses Mitglied, nicht an die Leitung. So gibst du gezielt Kontext oder lenkst um, ohne das restliche Team einzubeziehen.
Mit Esc kehrst du zur Leitung zurück.
Ein abdriftendes Teammitglied umleiten
Manchmal versteht ein Teammitglied das Briefing falsch oder arbeitet an etwas, das nicht in seinen Bereich fällt. Du erkennst das bei der Planfreigabe oder wenn dir im Agent-Panel der Fortschritt auffällt.
Mit Planfreigabe pausiert das Mitglied nach der Planung und zeigt seinen Vorschlag, bevor Dateien geschrieben werden. So sieht das beim Database-Agent aus:

Freigabe für den Database Agent
Du kannst Schema und Vorgehen prüfen und mit Feedback freigeben oder ablehnen. Fehlt etwas, antworte z. B. mit "Use SQLAlchemy instead of raw sqlite3," und das Teammitglied plant neu.
Entdeckst du das Problem erst nach dem Start, wähle das Mitglied im Agent-Panel, drücke Enter, um seine Sitzung zu öffnen, und schreibe ihm. Du kannst auch x drücken, um ein ausgewähltes Teammitglied zu stoppen, oder die Leitung bitten, ein Ersatzmitglied zu starten, wenn das aktuelle feststeckt.
Abschließen und reviewen
Wenn alle Teammitglieder fertig sind, meldet sich die Leitung mit einer kurzen Zusammenfassung und den Befehlen, um das Projekt zu starten.

Abschließende Anweisungen der Leitung
Jetzt prüfst du die Arbeit. Öffne die generierten Dateien im Editor und lies die Diffs.

Die generierte Datei app/main.py
Du kannst auch die vom Database Agent erstellte und befüllte Datenbank inspizieren.

Die Tabelle greetings
Installiere anschließend die Abhängigkeiten, starte uvicorn app.main:app --reload und öffne http://localhost:8000 im Browser, um zu bestätigen, dass der Full Stack End-to-End funktioniert.

Finale App
Wenn du Änderungen möchtest, sag der Leitung, was zu justieren ist – sie behebt es selbst oder startet ein neues Teammitglied dafür. Bist du zufrieden, kann die Leitung die Änderungen committen. Beim Beenden der Sitzung fährt sie die Teammitglieder herunter und räumt die Teamkonfiguration auf.
Das war’s!
Fazit
Claude Code Agent Teams stehen für zwei Dinge: Spezialisierung und Koordination. Jedes Teammitglied hat seinen Arbeitsbereich und ein eigenes Kontextfenster. Die Leitung hält die Ausrichtung, die Aufgabenliste hält alle synchron, und direkte Nachrichten verhindern, dass du Informationen zwischen Sitzungen weiterreichen musst.
Das große Bild: KI-gestützte Entwicklung wandert vom Solo- in den koordinierten Modus. Agent Teams zeigen heute, wie das in Claude Code aussieht – und ein ähnliches Muster erscheint in Claude Tag für Slack. Wer sich jetzt daran gewöhnt, verbringt weniger Zeit mit Kontextgrenzen und mehr Zeit mit echten Features.
Du willst dich in Generativer KI zertifizieren lassen? Hier sind die Besten Zertifizierungen für Generative KI 2026 inklusive Top-Kurse, Vorbereitungstipps und FAQs.
FAQs
Was sind Claude Code Agent Teams?
Claude Code Agent Teams sind eine Koordinationsschicht, mit der mehrere Claude-Code-Sitzungen gleichzeitig am selben Projekt arbeiten. Eine Sitzung agiert als Teamleitung und erstellt weitere Sitzungen (Teammitglieder), die spezifische Teile der Arbeit übernehmen. Die Teammitglieder teilen sich eine Aufgabenliste, schreiben sich Nachrichten und führen ihre Arbeit parallel unter der Koordination der Leitung aus.
Wodurch unterscheiden sich Agent Teams von Subagenten?
Subagenten laufen innerhalb einer einzelnen Claude-Code-Sitzung und können Ergebnisse nur an den Hauptagenten zurückmelden. Agent Teams bestehen aus unabhängigen Claude-Code-Sitzungen, die sich eine Aufgabenliste teilen und einander direkt Nachrichten schicken – ohne über die Leitung zu gehen. Nutze Agent Teams, wenn die Ausführenden Erkenntnisse teilen oder sich bei miteinander verknüpften Aufgaben abstimmen müssen.
Wann lohnt sich der Einsatz eines Agent Teams?
Agent Teams eignen sich für Arbeit, die von paralleler Exploration profitiert: mehrschichtige Features, große Refaktorierungen, Debugging mit konkurrierenden Hypothesen und repository-weite Audits. Weniger sinnvoll sind sie für kleine Bugfixes oder wenn mehrere Teammitglieder dieselben Dateien bearbeiten würden. Faustregel: Wenn eine Einzelsitzung am Kontextlimit scheitern oder viel zu lange brauchen würde, lohnt sich ein Team die zusätzlichen Tokens.
Wie hoch sind die Tokenkosten für Agent Teams?
Jedes Teammitglied ist eine vollständige Claude-Code-Sitzung mit eigenem Kontextfenster, daher skaliert der Tokenverbrauch linear mit der Teamgröße. Ein Team mit drei oder vier Mitgliedern nutzt grob drei- bis viermal so viele Tokens wie eine Einzelsitzung für die gleiche Arbeit. Du hältst die Kosten im Zaum, indem du die Leitung auf ein stärkeres Modell wie Opus setzt und die Teammitglieder auf Sonnet – Ausführung braucht meist weniger Tiefgang als Koordination.
Wie verhindere ich, dass Teammitglieder sich gegenseitig überschreiben?
Teile die Arbeit entlang von Datei- oder Modulgrenzen, sodass jedes Teammitglied einen klaren Bereich besitzt. Benenne im Briefing die konkreten Dateien oder Verzeichnisse pro Teammitglied und vermeide, dass zwei Mitglieder an derselben Datei arbeiten. Muss eine Aufgabe Änderungen in derselben Datei vornehmen, lege sie als Abhängigkeit in der Aufgabenliste fest und führe sie sequenziell aus statt parallel.
