Claude Code Agent Teams: Einrichtung, Tipps und Anwendungsfälle

Claude Code Agent Teams: Einrichtung, Tipps und Anwendungsfälle

Ich habe ein Token-Budget von 47 Dollar in neunzehn Minuten verbrannt. Vier Agents, alle auf Opus 4.6, alle arbeiteten an derselben Next.js-Codebase, alle bearbeiteten layout.tsx gleichzeitig.

Der Orchestrator hat den Konflikt nicht erkannt. Der Frontend-Agent hat den Auth-Wrapper des Backend-Agents überschrieben. Der QA-Agent testete eine Version der Datei, die gar nicht mehr existierte. Und der Design-Agent -- derjenige, den ich gestartet hatte, um "die UI aufzupolieren" -- führte eine Tailwind-Klasse ein, die das responsive Grid zerstörte, an dem der Frontend-Agent acht Minuten lang gebaut hatte.

Neunzehn Minuten. Siebenundvierzig Dollar. Eine Codebase, die schlechter war als vorher.

Das war Februar 2026. Ich hatte gerade zum ersten Mal Claude Code Agent Teams aktiviert und jeden Fehler gemacht, vor dem die Dokumentation warnt -- plus ein paar, die sie nicht erwähnt. Seitdem habe ich Agent Teams in über dreißig echten Projekten eingesetzt, von SaaS-Dashboards über API-Migrationen bis hin zu einer Content-Pipeline, die jetzt den Blog betreibt, den du gerade liest. Das Feature entwickelte sich von "teurer Katastrophe" zum mächtigsten Werkzeug in meinem Entwicklungs-Workflow.

Das ist der Guide, den ich mir gewünscht hätte, als ich anfing. Nicht die Marketing-Version. Nicht der Drei-Absatz-Quickstart. Das volle Bild -- Einrichtung, Konfiguration, 30+ hart erarbeitete Tipps und die sechs Anwendungsfälle, bei denen Agent Teams wirklich alles andere übertreffen, was ich ausprobiert habe.

Was Agent Teams wirklich sind (und warum Sub-Agents nicht ausreichen)

Bevor du irgendeine Konfiguration anfasst, brauchst du ein mentales Modell, das präziser ist als "mehrere Agents arbeiten zusammen." Der Unterschied zwischen Sub-Agents und Agent Teams ist wie der zwischen Freelancern und einem eingespielten Team -- und wenn du das verwechselst, kostet dich das echtes Geld.

Sub-Agents sind unabhängige Claude Code-Instanzen, die von deiner Hauptsession gestartet werden. Jeder bekommt sein eigenes Context Window. Jeder führt seine Aufgabe aus und meldet sich beim übergeordneten Agent zurück. Das entscheidende Detail: Sub-Agents können nicht miteinander kommunizieren. Sie berichten nach oben an den Orchestrator, Punkt. Wenn Agent A feststellt, dass das Datenbankschema eine neue Spalte braucht, erfährt Agent B davon nichts, es sei denn, du gibst diese Information manuell weiter.

Agent Teams fügen darüber eine Kommunikationsschicht hinzu. Teammates können sich direkt gegenseitig Nachrichten schicken. Der Frontend-Agent kann den Backend-Agent fragen "Welches Format gibt der /users-Endpoint zurück?" und bekommt eine Antwort, ohne über den Orchestrator zu gehen. Ein Agent fungiert als Teamleiter -- er koordiniert, delegiert, fasst zusammen -- während die Teammates eigenständig arbeiten, aber über Message Passing verbunden bleiben.

Hier ist die Analogie, bei der es bei mir endlich Klick gemacht hat: Sub-Agents sind E-Mail. Du schickst Anweisungen, sie schicken Ergebnisse zurück. Agent Teams sind Slack. Alle sind im selben Channel, Nachrichten fließen in Echtzeit, und der Projektleiter hält alles zusammen.

Die Auswirkungen sind praktisch und unmittelbar. Sub-Agents funktionieren perfekt für Aufgaben, die wirklich unabhängig sind -- Linting ausführen, Dokumentation generieren, Tests aufsetzen. Keine Koordination nötig, kein geteilter Kontext, keine Nachrichten ausgetauscht. Schnell und günstig.

Agent Teams glänzen, wenn die Arbeit voneinander abhängt. Wenn das Frontend den API-Vertrag kennen muss, bevor es Fetch-Calls baut. Wenn der QA-Agent die tatsächliche Komponentenstruktur braucht, um sinnvolle Tests zu schreiben. Wenn eine Datenbankschema-Änderung sich auf das Verständnis jedes Agents vom System auswirken sollte.

Ich werde als Nächstes den genauen Setup-Prozess durchgehen, aber diese Unterscheidung sollte jede Entscheidung beeinflussen, die du von hier an triffst. Wenn deine Aufgaben keine Koordination brauchen, sind Agent Teams eine teure Methode, um etwas zu tun, was Sub-Agents für einen Bruchteil der Kosten erledigen.

Das komplette Setup: Von Null zum laufenden Team

Agent Teams sind Stand März 2026 in Claude Code immer noch als experimentell gekennzeichnet. Das bedeutet, du musst sie aktiv einschalten, und das Verhalten des Features kann sich zwischen Releases ändern. Hier ist die genaue Reihenfolge, der ich bei einem frischen Setup folge.

Schritt 1: Das experimentelle Flag aktivieren

Öffne deine Claude Code Einstellungsdatei. Auf macOS liegt sie unter ~/.claude/settings.json. Füge das experimentelle Agent Teams Flag hinzu:

{
  "experimental": {
    "agentTeams": true
  }
}

Du kannst auch die Umgebungsvariable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 setzen, wenn du die Einstellungsdatei nicht anfassen willst. Ich nutze die Einstellungsdatei, weil sie über Terminal-Sessions hinweg bestehen bleibt, ohne mein Shell-Profil zu verschmutzen.

Schritt 2: Den Anzeigemodus wählen

Diese Entscheidung hat einen größeren Einfluss auf deinen Workflow, als du erwarten würdest. Agent Teams unterstützen zwei Rendering-Modi:

Tmux Split-Pane-Modus gibt jedem Teammate sein eigenes Terminal-Pane. Du siehst alle Agents gleichzeitig nebeneinander arbeiten. Du kannst in jedes Pane klicken und direkt mit dem jeweiligen Agent interagieren. Das ist mein bevorzugtes Setup für komplexe Projekte -- das visuelle Feedback ist unbezahlbar.

Voraussetzungen: tmux installiert (brew install tmux auf macOS), und du musst Claude Code aus einer tmux-Session heraus starten. Beginne mit tmux new -s dev, dann starte Claude Code innerhalb dieser Session.

In-Process-Modus führt alles in einem einzigen Terminalfenster aus. Die Ausgabe der Teammates erscheint inline, und du interagierst über den Lead mit den Agents. Weniger visueller Overhead, funktioniert überall, aber es ist schwieriger nachzuverfolgen, was jeder Agent in Echtzeit tut.

Konfiguriere das in deinen Einstellungen:

{
  "teammateMode": "tmux"
}

Die Optionen sind "tmux", "in-process" oder "auto" (das standardmäßig tmux wählt, wenn es eine tmux-Session erkennt, ansonsten in-process).

Ein Fallstrick, der mich erwischt hat: Der Split-Pane-Modus funktioniert nicht im integrierten Terminal von VS Code, Windows Terminal oder Ghostty. Wenn du eines davon nutzt, bleib bei in-process oder wechsle zu einem eigenständigen Terminal. Ich nutze iTerm2, das auch native Split Panes über seine Python API unterstützt -- installiere die it2 CLI und aktiviere die Python API in den iTerm2-Einstellungen.

Schritt 3: Team-Rollen in natürlicher Sprache definieren

Hier weichen Agent Teams von traditionellen Orchestrierungsframeworks ab. Du schreibst keine Konfigurationsdateien für jeden Agent. Du beschreibst dein Team dem Lead Agent in einfachem Deutsch (oder Englisch).

Hier ist ein echtes Prompt, das ich für ein aktuelles SaaS-Projekt verwendet habe:

I need a team of 4 agents for this project:

1. Lead (you) - Architecture decisions, task delegation, integration review
2. Frontend specialist - React, TypeScript, Tailwind, component architecture
3. Backend specialist - Node.js, Express, PostgreSQL, API design
4. QA specialist - Testing, validation, integration checks

Rules:
- Frontend and backend must agree on API contracts before building
- QA writes tests only after receiving the actual implementation
- Nobody touches files outside their domain without lead approval

Der Lead Agent erstellt Teammates basierend auf deiner Beschreibung. Jeder Teammate bekommt sein eigenes Context Window (ungefähr 200K Tokens mit Opus 4.6) und seine zugewiesene Spezialisierung.

Schritt 4: Modelle strategisch zuweisen

Das ist der größte Kostenhebel, den du hast. Nicht jeder Agent braucht Opus 4.6. Meine Standard-Modellzuweisung:

Ein Vier-Agent-Team, das komplett auf Opus läuft, kostet ungefähr das 4-fache eines gemischten Teams. Der Qualitätsunterschied bei Ausführungsaufgaben -- React-Komponenten schreiben, CRUD-Endpoints bauen, Tests aufsetzen -- ist zwischen Opus und Sonnet vernachlässigbar. Spar dir Opus für das Denken, das es wirklich braucht.

Schritt 5: Planen, bevor du ausführst

Das ist nicht verhandelbar. Bevor das Team eine einzige Zeile Code schreibt, nutze den Plan-Modus, um die Arbeit aufzugliedern. Der Plan-Modus ist günstig -- ein Agent denkt den Ansatz durch. Der Ausführungsmodus mit einem vollen Team ist teuer -- vier Agents verbrauchen parallel Tokens.

Mein Workflow: Plan-Modus mit dem Lead Agent starten, einen vollständigen Aufgabenüberblick und Architekturplan erstellen lassen, diesen überprüfen, anpassen, und erst dann zur Ausführung mit dem vollen Team wechseln. Das schafft einen Checkpoint, bevor du echte Tokens investierst.

Denk so darüber nach: Der Plan-Modus ist der Architekturentwurf. Die Agent-Team-Ausführung ist das Bauteam. Du würdest kein Bauteam ohne Baupläne auf die Baustelle schicken. Gleiches Prinzip, anderes Medium.

30+ Tipps, die mir Tausende an Tokens gespart haben

Ich sammle diese seit Februar. Einige stammen aus meinen eigenen teuren Fehlern. Andere aus Mustern, die mir über Dutzende von Projekten aufgefallen sind. Ich habe sie nach Kategorien gruppiert, weil eine flache Liste von 30 Einträgen nicht umsetzbar ist.

Team-Zusammenstellung

1. Starte mit 3 Agents, nicht mit 5. Der Koordinationsaufwand zwischen Agents skaliert nicht linear. Drei Agents können effizient koordinieren. Fünf Agents verbringen einen erheblichen Teil ihrer Tokens nur damit, miteinander zu reden. Ich starte jedes Projekt mit drei und füge nur einen vierten hinzu, wenn die Arbeitslast es klar erfordert.

2. Jeder Agent braucht eine klare Domänengrenze. "Frontend-Agent" ist klar. "Hilfs-Agent" ist es nicht. Wenn du die Domäne eines Agents nicht in einem Satz beschreiben kannst, ist die Rolle nicht gut genug definiert, und der Agent wird in das Territorium anderer Agents abdriften.

3. Der Lead Agent sollte dein teuerstes Modell sein. Der Lead trifft architektonische Entscheidungen, löst Konflikte zwischen Teammates und behält den ganzheitlichen Blick auf das Projekt. Billiges Denken hier verursacht teure Fehler überall sonst.

4. Passe die Modellfähigkeit an die Aufgabenkomplexität an. Unit Tests schreiben erfordert kein Opus-Level-Reasoning. Ein Datenbankschema mit komplexen Beziehungen zu entwerfen schon. Weise Modelle basierend auf der kognitiven Anforderung der Rolle zu, nicht pauschal "alles bekommt das beste Modell."

5. Erstelle kein Team für sequenzielle Arbeit. Wenn Aufgabe B erst starten kann, wenn Aufgabe A fertig ist, brauchst du keine zwei Agents -- du brauchst einen Agent, der zwei Dinge tut. Agent Teams lohnen sich, wenn Aufgaben parallel laufen können.

Aufgabenplanung

6. Begrenze Aufgaben auf 5-6 pro Agent. Ich habe festgestellt, dass das der Sweet Spot ist. Weniger als 3 und du nutzt den Agent nicht aus. Mehr als 7 und der Agent verliert den Überblick über seinen eigenen Fortschritt, wiederholt Arbeit oder vergisst frühere Entscheidungen.

7. Schreibe Aufgabenbeschreibungen, als würdest du einen neuen Auftragnehmer briefen. Beschreibe, was gebaut werden soll, welche Einschränkungen gelten, welche Dateien bearbeitet werden und welche Dateien tabu sind. Unklare Aufgaben produzieren unklare Ergebnisse -- und diese Ergebnisse kosten Tokens zum Beheben.

8. Definiere Erfolgskriterien für jede Aufgabe. "Baue das Auth-System" ist vage. "Baue JWT-basierte Auth mit Refresh Tokens, gib 401 für abgelaufene Tokens zurück und unterstütze rollenbasierten Zugriff für Admin/User/Viewer-Rollen" sagt dem Agent genau, wann er fertig ist.

9. Plane die Integrationspunkte, bevor du die Arbeit aufteilst. Der Lead Agent sollte einen gemeinsamen Vertrag erstellen -- API-Schemas, Datenbankmodelle, Typdefinitionen, Event-Formate -- bevor irgendein Teammate anfängt zu bauen. Das eliminiert die Mehrheit der Integrationsprobleme.

10. Konzentriere das Denken am Anfang, das Bauen am Ende. Verwende 20% deiner Session für Planung und 80% für Ausführung. Die meisten Leute kehren dieses Verhältnis um und bezahlen dafür mit Nacharbeit.

Kommunikation und Kontext

11. Kontextaustausch ist auf Message Passing beschränkt. Agents teilen sich weder Speicher noch Context Windows. Wenn Agent A etwas entdeckt, das Agent B wissen muss, muss diese Information explizit als Nachricht gesendet werden. Nichts passiert automatisch.

12. Versorge Teammates von Anfang an mit kritischem Kontext. Wenn du Team-Rollen definierst, nimm die wichtigsten architektonischen Entscheidungen, den Tech-Stack und die Einschränkungen in das initiale Prompt auf. Jeder Token, den du in Context Seeding investierst, spart zehn Tokens an verwirrtem Agent-Verhalten später.

13. Setze explizite Kommunikationsprotokolle. Lass Agents nicht frei miteinander kommunizieren. Definiere Übergabepunkte: "Frontend-Agent sendet API-Erwartungen an Backend-Agent, bevor er Fetch-Calls schreibt." "Backend-Agent teilt den finalen Endpoint-Vertrag mit QA, bevor Tests geschrieben werden." Struktur verhindert Rauschen.

14. Nutze den Lead Agent als Router, nicht als Flaschenhals. Der Lead sollte delegieren und prüfen, nicht jede Nachricht zwischen Teammates weiterleiten. Direkte Agent-zu-Agent-Kommunikation existiert aus gutem Grund -- wenn jede Kommunikation über den Lead läuft, hast du das Sub-Agent-Modell nachgebaut, aber mit mehr Overhead.

15. Halte Nachrichten zwischen Agents knapp. Ein Agent, der seine gesamte Code-Ausgabe an einen anderen Agent schickt, verschwendet Tokens auf beiden Seiten. Nachrichten sollten Entscheidungen, Verträge und Interface-Definitionen enthalten -- nicht vollständige Implementierungen.

Datei- und Konfliktmanagement

16. Lass niemals zwei Agents gleichzeitig dieselbe Datei bearbeiten. Das ist der Fehler, der mich 47 Dollar in neunzehn Minuten gekostet hat. Dateikonflikte in Agent Teams sind lautlos -- es gibt keinen Merge-Konflikt-Dialog. Ein Agent überschreibt einfach die Arbeit des anderen. Weise Datei-Ownership explizit zu.

17. Erstelle eine Datei-Ownership-Map. Bevor die Ausführung beginnt, sollte der Lead Agent eine klare Zuordnung erstellen: "Frontend-Agent besitzt alles in /src/components und /src/hooks. Backend-Agent besitzt /src/api und /src/db. QA besitzt /tests." Grauzonen verursachen Kollisionen.

18. Nutze ein gemeinsames Types- oder Contracts-Verzeichnis. Ich erstelle ein /src/shared- oder /src/contracts-Verzeichnis, aus dem sowohl Frontend- als auch Backend-Agent lesen, aber nur der Lead Agent hineinschreibt. Das verhindert Contract Drift.

19. Wenn ein Agent die Datei eines anderen Agents ändern muss, leite es über den Lead. Der Lead prüft die Änderung, bestätigt, dass sie nicht kollidiert, und führt die Änderung entweder selbst durch oder genehmigt dem anfragenden Agent explizit, fortzufahren. Das fügt ein paar Sekunden Latenz hinzu, verhindert aber Minuten an Debugging.

Kostenkontrolle

20. Überwache den Token-Verbrauch aktiv, nicht passiv. Warte nicht bis zum Ende der Session, um deine Rechnung zu prüfen. Claude Code zeigt den Token-Verbrauch in Echtzeit an. Wenn ein Agent schneller Tokens verbrennt als erwartet, stimmt etwas nicht -- er steckt wahrscheinlich in einer Schleife oder produziert übermäßig viel Output.

21. Beende untätige Agents sofort. Ein Agent, der seine Aufgaben erledigt hat, aber noch läuft, verbraucht weiterhin Ressourcen. Der Orchestrator kümmert sich um die Bereinigung, aber ich habe gesehen, wie Agents minutenlang untätig saßen, bevor sie beendet wurden. Manuelles Herunterfahren ist schneller und günstiger.

22. Nutze Sub-Agents für unabhängige Aufgaben, Teams für voneinander abhängige. Ich kann das nicht genug betonen. Vier koordinierende Agents für vier unabhängige Aufgaben laufen zu lassen, ist wie ein Meeting einzuberufen, das vier E-Mails hätte sein können. Nutze Sub-Agents für isolierte Arbeit. Reserviere Agent Teams für Arbeit, die wirklich Koordination erfordert.

23. Fasse verwandte Aufgaben zusammen. Statt für jede kleine Aufgabe einen neuen Agent zu starten, gruppiere verwandte Aufgaben unter einem Agent. Ein Agent, der "alle drei API-Endpoints für User Management bauen" erledigt, ist effizienter als drei Agents, die jeweils einen Endpoint bauen.

24. Mache vor dem Start eine Kostenschätzung. Schnelle Rechnung: Ein 3-Agent-Team, das 30 Minuten auf Opus 4.6 läuft, verbraucht ungefähr 200K-300K Tokens. Beim aktuellen Pricing sind das 15-25 Dollar. Bei einem gemischten Modell-Team (ein Opus, zwei Sonnet) kostet dieselbe Session 6-10 Dollar. Kenne deine Zahlen, bevor du anfängst.

Monitoring und Steuerung

25. Schau alle 10-15 Minuten rein. Agent Teams sind nicht "einrichten und vergessen." Ich überprüfe den Fortschritt in regelmäßigen Abständen, erkenne Abdrift frühzeitig und passe Aufgabenzuweisungen an, wenn ein Agent blockiert ist, während ein anderer untätig ist.

26. Du kannst direkt mit jedem Teammate interagieren. Im tmux Split-Pane-Modus klickst du in das Pane eines Agents und gibst ihm direkte Anweisungen. Du bist nicht darauf beschränkt, über den Lead zu sprechen. Wenn ich bemerke, dass ein bestimmter Agent in die falsche Richtung steuert, greife ich direkt ein, anstatt die Korrektur über den Orchestrator weiterzuleiten.

27. Nutze Hooks für Lifecycle-Events. Claude Code unterstützt Hooks, die ausgelöst werden, wenn Teammates untätig werden, Aufgaben abschließen oder auf Fehler stoßen. Ich habe diese mit Slack-Benachrichtigungen verbunden, sodass ich eine Nachricht bekomme, wenn ein Agent fertig ist oder feststeckt -- kein Bedarf, ständig das Terminal zu beobachten.

28. Achte auf Endlosschleifen. Gelegentlich geraten zwei Agents in ein Ping-Pong-Muster -- Agent A stellt Agent B eine Frage, Agent B antwortet mit einer Gegenfrage, und sie schleifen. Wenn du siehst, dass der Token-Verbrauch in die Höhe schießt, ohne dass sichtbarer Fortschritt entsteht, greif sofort ein.

Lifecycle und Aufräumen

29. Agents stoppen automatisch, wenn ihre Aufgabenwarteschlange leer ist. Der Orchestrator verwaltet das Herunterfahren, aber das Timing ist nicht immer sofort. Wenn du mit der Session fertig bist, sag dem Lead Agent explizit, dass er abschließen soll.

30. Ein Team pro Session. Ein Lead Agent kann nur ein Team gleichzeitig verwalten. Wenn du eine andere Team-Zusammensetzung für ein anderes Projekt brauchst, starte eine neue Session.

31. Teammates können keine eigenen Teams erstellen. Die Hierarchie ist flach: ein Lead, mehrere Teammates. Keine Sub-Teams, keine rekursive Orchestrierung. Wenn dein Projekt dieses Verschachtelungslevel braucht, bist du wahrscheinlich besser mit mehreren unabhängigen Sessions bedient.

32. Räume Agent-Prozesse nach Abstürzen auf. Wenn eine Session mitten im Team abstürzt, können verwaiste Agent-Prozesse weiterlaufen. Prüfe auf veraltete Prozesse und beende sie manuell. Das vermeidet sowohl Ressourcenverschwendung als auch potenzielle Konflikte, wenn du eine neue Session startest.

33. Dokumentiere, was funktioniert hat. Nach jeder Team-Session verbringe ich zwei Minuten damit, zu notieren, welche Modellzuweisungen, Teamgrößen und Kommunikationsmuster für diesen Projekttyp am besten funktioniert haben. Diese Bibliothek von Templates lässt mich jetzt optimierte Teams in unter drei Minuten hochfahren.

Sechs Anwendungsfälle, bei denen Agent Teams Solo-Agents klar schlagen

Theorie ist gut und schön. Was wirklich zählt, ist zu wissen, wann du zu diesem Werkzeug greifst. Nach über dreißig Projekten rechtfertigen diese sechs Szenarien konsistent den Koordinationsaufwand.

1. Full-Stack-Anwendungsentwicklung

Das ist der kanonische Anwendungsfall, und er liefert wirklich. Drei Agents -- Architektur-Lead, Frontend-Spezialist, Backend-Spezialist -- arbeiten parallel an einer gemeinsamen Codebase. Der Lead erstellt zuerst den API-Vertrag, beide Implementierungs-Agents bauen gleichzeitig gegen diesen Vertrag, und Integrationsprobleme tauchen durch Agent-zu-Agent-Messaging auf statt beim Debugging im Nachhinein.

Bei einem aktuellen Projekt -- ein Multi-Tenant-Dashboard mit rollenbasiertem Zugriff und Echtzeit-WebSocket-Updates -- lieferte das Agent Team in 35 Minuten, wofür ein Solo-Agent fast 90 Minuten gebraucht hätte. Nicht weil die Agents schneller tippten, sondern weil der Frontend-Agent Komponenten baute, während der Backend-Agent Endpoints erstellte. Echte parallele Ausführung bei voneinander abhängiger Arbeit.

Der Schlüssel: Das Contract-First-Muster, das ich in Tipp #9 beschrieben habe, ist hier Pflicht. Ohne einen gemeinsamen API-Vertrag bauen die Agents auf Annahmen, die sofort auseinanderlaufen.

2. Code Review mit spezialisierten Perspektiven

Dieser Anwendungsfall hat mich überrascht, wie gut er funktioniert. Weise drei Agents zu, denselben PR zu reviewen, jeder mit einem anderen Fokus: Sicherheitslücken, Performance-Engpässe und Testabdeckungslücken. Jeder Agent untersucht den Code durch seine spezialisierte Linse und erstellt einen fokussierten Bericht. Der Lead Agent fasst die drei Berichte zu einem einzelnen Review zusammen.

Das Ergebnis ist gründlicher als jedes Single-Pass-Review, und der spezialisierte Fokus bedeutet, dass jeder Agent Dinge findet, die ein Generalist übersehen würde. Ein sicherheitsfokussierter Agent hat einen SQL-Injection-Vektor in einer parametrisierten Query gefunden, die auf den ersten Blick korrekt aussah -- das Parameter-Escaping behandelte Array-Inputs nicht. Ein performancefokussierter Agent entdeckte eine N+1-Query, die hinter einer ORM-Abstraktion versteckt war. Keines der beiden Ergebnisse wäre bei einem Standard-Review aufgefallen.

Die Kosten für ein Drei-Agent-Code-Review liegen bei etwa 3-5 Dollar an Tokens. Für kritische PRs ist das ein Schnäppchen.

3. Debugging mit konkurrierenden Hypothesen

Wenn ein Bug mehrere mögliche Ursachen hat, ist der traditionelle Ansatz sequenziell: Hypothese A untersuchen, wenn das nicht der Grund ist, Hypothese B probieren. Agent Teams lassen dich alle Hypothesen gleichzeitig untersuchen.

Ich hatte ein Production-Problem, bei dem API-Antwortzeiten alle paar Stunden von 200ms auf 3 Sekunden hochschossen. Drei mögliche Ursachen: Erschöpfung des Datenbankverbindungspools, Memory Leak in einem Background Worker oder Throttling durch einen Upstream-Service. Ich wies jede Hypothese einem anderen Agent zu und ließ sie parallel untersuchen. Zwanzig Minuten später fand Agent C das Upstream-Throttling -- ein Rate Limit auf einer Geocoding-API, die niemand dokumentiert hatte. Die anderen beiden Agents fanden keine Belege für ihre Hypothesen, was genauso wertvoll war, weil es zwei Tage potenzielles Suchen im Dunkeln eliminierte.

4. Schreib- und Redaktions-Workflows

Dieser Anwendungsfall entspricht direkt der Content-Pipeline, die ich für diesen Blog nutze. Drei Agents mit verschiedenen Rollen: Researcher (sammelt Quellen, Datenpunkte, aktuelle Informationen), Writer (erstellt den Entwurf gemäß Markensprache und Struktur) und Editor (prüft auf Qualität, Genauigkeit, Konsistenz und SEO).

Der Researcher wird zuerst fertig und gibt seine Ergebnisse an den Writer weiter. Der Writer erstellt den Entwurf und übergibt ihn dem Editor. Der Editor prüft und sendet Änderungsvorschläge zurück. Dieser sequenzielle Flow mit Kommunikation produziert merklich besseren Output als ein einzelner Agent, der versucht, gleichzeitig zu recherchieren, zu schreiben und selbst zu redigieren -- weil jeder Agent sich auf eine kognitive Aufgabe konzentriert, ohne Context Switching.

5. Parallele Recherche und Exploration

Wenn du mehrere Tools, Ansätze oder Architekturen bewerten musst, bevor du eine Entscheidung triffst, lassen Agent Teams dich alle Pfade gleichzeitig erkunden. Ich habe das genutzt, als ich drei verschiedene State-Management-Ansätze für ein React-Projekt evaluierte -- ein Agent testete Zustand, einer testete Jotai, einer testete die native React Context API. Jeder Agent baute einen kleinen Proof-of-Concept, dokumentierte die Trade-offs und berichtete an den Lead.

Die kritische Regel für Research-Aufgaben: Halte die Agents während der Explorationsphase read-only. Lass sie Code lesen, Benchmarks laufen und Wegwerf-Prototypen schreiben -- aber lass sie nicht die Hauptcodebase modifizieren, bis der Lead die Ergebnisse geprüft und eine Richtung gewählt hat. Sonst hast du drei verschiedene Ansätze halb implementiert in deinem Produktionscode.

6. Cross-Platform Feature-Parität

Wenn du dasselbe Feature auf mehreren Plattformen auslieferst -- iOS und Android, Web und Mobile, oder sogar verschiedene Microservices, die synchronisiertes Verhalten brauchen -- halten Agent Teams die Parität aufrecht, indem jeder Plattform-Agent seine Implementierungsdetails mit den anderen teilt. Wenn der Android-Agent ein Datumsformatierungs-Utility implementiert, schickt er dem iOS-Agent den genauen Format-String, damit beide Plattformen identischen Output produzieren.

Ich habe das erst zweimal eingesetzt, aber beide Male hat es Abweichungen gefunden, die zu benutzersichtbaren Bugs geworden wären. Der Koordinationsaufwand ist hoch bei diesem Muster, daher empfehle ich es nur für Features, bei denen Plattform-Inkonsistenz ein ernstes Problem wäre -- Zahlungsabläufe, Datenserialisierung, alles wo "leicht unterschiedliches Verhalten auf iOS vs. Android" ein Support-Ticket bedeutet.

Die Workflow-Phasen: Wie eine Session tatsächlich abläuft

Für alle, die das Gesamtbild wollen, hier der typische Ablauf einer Agent-Team-Session von Anfang bis Ende. Ich verwende ein echtes Beispiel -- den Bau eines internen Tools zur Verfolgung des Content-Pipeline-Status.

Phase 1 -- Initialisierung. Ich öffne eine tmux-Session, starte Claude Code und überprüfe, ob das experimentelle Agents-Flag aktiv ist. Ich beschreibe dem Lead Agent das Projekt im Detail: den Tech-Stack (Next.js 15, Prisma, PostgreSQL), die Anforderungen (Dashboard mit Content-Status, Autoren-Zuweisungen, Veröffentlichungsdaten) und die Einschränkungen (muss sich in das bestehende Auth-System integrieren, darf das gemeinsame Datenbankschema nicht verändern).

Phase 2 -- Team-Erstellung. Ich sage dem Lead Agent, welches Team ich brauche. In diesem Fall: ein Frontend-Agent für die Dashboard-UI, ein Backend-Agent für die API-Schicht und Datenbankabfragen, und ein QA-Agent. Der Lead erstellt drei Teammates, die jeweils in ihrem eigenen tmux-Pane erscheinen. Ich kann alle vier Agents gleichzeitig sehen.

Phase 3 -- Aufgabenplanung. Bevor irgendjemand Code schreibt, erstellt der Lead Agent einen Aufgabenplan. Er skizziert jede Lieferung, weist Aufgaben bestimmten Agents zu, definiert den API-Vertrag zwischen Frontend und Backend und legt die Integrationstestkriterien fest. Ich überprüfe diesen Plan, passe zwei Aufgabenzuweisungen an, die keinen Sinn ergaben, und genehmige.

Phase 4 -- Parallele Ausführung. Die Agents legen los. Frontend beginnt mit dem Bau der Dashboard-Komponenten. Backend erstellt das Prisma-Schema und die API-Routen. Ich kann den Fortschritt beider Agents in Echtzeit über die tmux-Panes verfolgen. Wenn der Frontend-Agent eine Klärung zur Antwortstruktur des /content-Endpoints braucht, schickt er dem Backend-Agent direkt eine Nachricht.

Phase 5 -- Monitoring und Steuerung. Nach etwa zwölf Minuten bemerke ich, dass der Frontend-Agent eine komplexe Filterkomponente baut, die nicht im Spec war. Ich klicke in sein Pane und lenke um: "Überspringe die erweiterten Filter vorerst. Konzentrier dich auf das Status-Board und die Autorenansicht." Der Agent passt sich sofort an.

Phase 6 -- Integration und QA. Sobald beide Implementierungs-Agents die Fertigstellung signalisieren, wird der QA-Agent aktiv. Er liest die Frontend-Komponenten und Backend-Endpoints, schreibt Integrationstests und führt sie aus. Zwei Fehlschläge: eine Datumsformatierungs-Diskrepanz und eine fehlende Error Boundary. Der QA-Agent meldet diese an die zuständigen Agents, die sie in unter zwei Minuten beheben.

Phase 7 -- Zusammenfassung und Aufräumen. Der Lead Agent erstellt eine Zusammenfassung: was gebaut wurde, welche Tests bestanden werden, was noch aussteht. Ich überprüfe den Output, bestätige, dass alles funktioniert, und schließe die Session. Gesamtdauer: 28 Minuten. Gesamte Token-Kosten mit dem gemischten Modell-Setup: ungefähr 8 Dollar.

Die ganze Sequenz fühlte sich weniger an wie "ein Tool benutzen" und mehr wie ein kleines Dev-Team zu leiten. Was in einem bedeutsamen Sinne genau das ist, was es ist.

Die ehrlichen Trade-offs, über die niemand spricht

Ich würde dir einen Bärendienst erweisen, wenn ich Agent Teams als universell überlegen darstellen würde. Sind sie nicht. Hier ist, was ich über ihre tatsächlichen Einschränkungen nach Monaten täglicher Nutzung gelernt habe.

Kosten skalieren linear, aber der Nutzen nicht. Drei Agents kosten dreimal so viel wie einer. Aber sie liefern nicht immer den dreifachen Nutzen. Für Projekte unter moderater Komplexität -- die meisten CRUD-Apps, die meisten Einzelseiten-Tools, die meisten Skripte -- ist ein Solo-Agent schneller, günstiger und produziert Output, der einfacher zu debuggen ist, weil ein Kopf ihn geschrieben hat.

Message Passing ist kein kostenloser Kontextaustausch. Agents können sich gegenseitig Nachrichten schicken, aber diese Nachrichten verbrauchen Tokens auf beiden Seiten -- Sender und Empfänger. Intensive Kommunikation zwischen Agents kann mehr kosten als das eigentliche Coding. Ich habe Sessions erlebt, in denen 30% des gesamten Token-Verbrauchs auf Inter-Agent-Messaging entfiel.

Der Orchestrator ist ein Single Point of Failure. Wenn der Lead Agent den Überblick über den Projektstatus verliert -- und das passiert -- driftet das gesamte Team ab. Das Context Window des Leads ist endlich, und den Status der Arbeit von fünf Teammates über Dutzende von Aufgaben zu verfolgen, kann selbst Opus 4.6 überfordern. Deshalb begrenze ich Teams auf 3-4 Agents und Aufgaben auf 5-6 pro Agent.

Team-Output zu debuggen ist schwieriger als Solo-Output zu debuggen. Wenn etwas im Output eines Solo-Agents kaputtgeht, weißt du, wer es geschrieben hat. Wenn etwas im Output eines Teams kaputtgeht, musst du nachverfolgen, welcher Agent den fehlerhaften Code produziert hat, welchen Kontext er hatte, als er diese Entscheidung traf, und ob die Nachricht eines anderen Agents die Wahl beeinflusst hat. Der Wirkungsradius eines Fehlers ist größer.

Das Feature ist noch experimentell. Session-Wiederaufnahme ist unzuverlässig. Das Herunterfahren von Teammates erfolgt nicht immer sauber. Tmux-Pane-Indexierung kann kaputtgehen, wenn deine Konfiguration nicht-standardmäßige Base Indices verwendet. Das sind Ecken und Kanten, und sie sind es wert, für komplexe Projekte toleriert zu werden -- aber sie bedeuten, dass Agent Teams noch kein produktionsreifes Tooling sind. Sie sind ein Power-Feature für Leute, die bereit sind, die Reibung zu managen.

Hier ist meine ehrliche Einschätzung nach drei Monaten: Agent Teams sind die richtige Wahl für vielleicht 15-20% der Projekte, an denen ich arbeite. Aber für diese 15-20% sind sie dramatisch besser als die Alternative. Die Kunst liegt darin zu wissen, welche 15-20% das sind.

Wenn du lieber jemanden hättest, der diese Art von Multi-Agent-Workflow für dein Projekt baut und konfiguriert, nehme ich individuelle AI-Automatisierungsaufträge an. Was ich bisher gebaut habe, kannst du dir unter fiverr.com/s/EgxYmWD ansehen.

Wie ich heute anfangen würde, wenn ich das Ganze neu aufsetze

Wenn ich in den Februar zurückgehen und mir selbst einen Fünf-Schritte-Plan geben könnte, wäre es dieser.

Erste Session: Solo-Agent, nur Plan-Modus. Fass Agent Teams nicht an. Erstelle deinen Projektplan mit einer einzelnen Claude Code-Instanz. Bring die Architektur in Ordnung, definiere die API-Verträge, skizziere die Dateistruktur. Das kostet fast nichts und liefert den Bauplan, den dein Team ausführen wird.

Zweite Session: zwei Agents, eine kleine Aufgabe. Starte einen Lead und einen Teammate. Gib ihnen ein abgegrenztes, risikoarmes Stück des Projekts -- ein einzelnes Feature mit klaren Grenzen. Beobachte, wie die Kommunikation fließt. Lerne die tmux-Oberfläche kennen. Gewöhne dich an den Rhythmus.

Dritte Session: drei Agents, echte Arbeit. Jetzt weißt du genug, um effektiv zu sein. Lead auf Opus, zwei Teammates auf Sonnet, klare Domänengrenzen, gemeinsame Verträge, 5-6 Aufgaben pro Agent. Das ist dein Produktions-Setup für 90% der teamwürdigen Projekte.

Jede weitere Session: verfeinere deine Templates. Dokumentiere, welche Modellzuweisungen, Teamgrößen und Kommunikationsmuster für welchen Projekttyp funktionieren. Nach zehn Sessions hast du eine Bibliothek von Team-Templates, die das Setup nahezu sofort macht.

Das Eine, das ich ändern würde: Ich hätte damit angefangen, die offizielle Anthropic-Dokumentation zu Agent Teams unter code.claude.com/docs/en/agent-teams zu lesen, statt durch Trial and Error zu lernen. Die Docs sind wirklich gut -- sie existierten nur nicht, als ich anfing zu experimentieren.

Der größte Wandel in meinem Denken über diese drei Monate betrifft nicht die Technologie. Es geht um die Rolle. Wenn ich Agent Teams nutze, höre ich auf, ein Entwickler zu sein, der AI benutzt, und werde ein technischer Lead, der AI-Entwickler führt. Die Fähigkeiten, die zählen, ändern sich: klares Anforderungsschreiben, Aufgabenzerlegung, Fortschrittsüberwachung, Integrationsplanung. Dieselben Fähigkeiten, die einen guten Engineering Manager ausmachen, machen auch einen guten Agent-Team-Operator aus.

Dein Terminal ist kein Texteditor mehr. Es ist eine Kommandozentrale. Und die Agents warten auf Befehle.

Häufig gestellte Fragen

Wie aktiviere ich Claude Code Agent Teams?

Füge "agentTeams": true zum "experimental"-Bereich von ~/.claude/settings.json hinzu, oder setze die Umgebungsvariable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Du brauchst ein Claude Pro- oder Max-Abonnement mit Zugang zu Opus 4.6 für die Lead-Agent-Rolle.

Wie viele Agents sollte ich in einem Claude Code Team verwenden?

Starte bei den meisten Projekten mit 3 Teammates -- ein Lead, zwei Spezialisten. Drei Agents bieten die beste Balance zwischen parallelem Durchsatz und Koordinationsaufwand. Teams mit 5 oder mehr verbringen einen überproportionalen Anteil ihrer Tokens für Inter-Agent-Messaging. Für eine detailliertere Aufschlüsselung siehe die Team-Zusammenstellungstipps oben.

Kosten Claude Code Agent Teams mehr als Sub-Agents?

Ja. Ein 3-Agent-Team verbraucht ungefähr 3-4x die Tokens einer einzelnen Session, die dieselbe Arbeit erledigt. Du kannst die Kosten senken, indem du günstigere Modelle (Sonnet 4.5 oder Haiku) den ausführungsfokussierten Teammates zuweist und Opus beim Lead belässt. Agent Teams sind nur dann kosteneffizient, wenn die Komplexität des Projekts wirklich Echtzeit-Koordination erfordert.

Können Claude Code Teammates dieselbe Datei bearbeiten?

Technisch ja, aber sie sollten es auf keinen Fall tun. Agent Teams haben keine Merge-Konflikt-Erkennung -- ein Agent überschreibt lautlos die Änderungen eines anderen. Weise jedem Agent vor Beginn der Ausführung eine explizite Datei-Ownership zu, und leite jede domänenübergreifende Dateiänderung über den Lead Agent.

Was ist der Unterschied zwischen Agent Teams und Sub-Agents in Claude Code?

Sub-Agents sind isolierte Arbeiter, die Ergebnisse an die übergeordnete Session zurückmelden -- keine Inter-Agent-Kommunikation. Agent Teams fügen direktes Message Passing zwischen Teammates hinzu und ermöglichen so Echtzeit-Koordination bei voneinander abhängigen Aufgaben. Nutze Sub-Agents für unabhängige parallele Arbeit, Agent Teams für kollaborative Arbeit, die geteilten Kontext erfordert.

Lass uns zusammenarbeiten

Du möchtest AI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe dir gerne.

• Fiverr (individuelle Entwicklung & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io