Claude Code Agent Teams: Parallele Agenten Setup Guide

Was sind Agent Teams?

Eine Claude Code Session ist gut. Fünf, die parallel am selben Projekt arbeiten, sind eine andere Liga.

Agent Teams wurden gerade mit Opus 4.6 veröffentlicht. Du startest mehrere Claude Code Instanzen, jede mit eigenem Context Window, und sie koordinieren sich autonom—sie schicken sich Nachrichten, nehmen Tasks an und berichten an einen Lead Agent zurück.

Hier ist, wie es funktioniert und wann es die Token-Kosten tatsächlich wert ist.

Was Agent Teams sind

Ein Team besteht aus drei Teilen:

1. Team Lead: Deine primäre Claude Code Session. Sie erstellt das Team, spawnt Teammates, weist Tasks zu und synthetisiert die Ergebnisse.
2. Teammates: Separate Claude Code Instanzen. Jede hat ihr eigenes Context Window, lädt den Projekt-Kontext (CLAUDE.md, MCP Server, Skills) und arbeitet unabhängig.
3. Shared Task List: Eine zentrale Liste von Arbeitspaketen. Tasks haben drei Status: pending, in progress, completed. Tasks können voneinander abhängen—blockierte Arbeit wird automatisch freigegeben, wenn Abhängigkeiten erledigt sind.

Der entscheidende Unterschied zu Subagents: Teammates reden miteinander.

Ein Subagent berichtet nur an den Main Agent zurück. Das war's. Mitglieder eines Agent Teams schicken sich Direktnachrichten, challengen die Ergebnisse der anderen und koordinieren sich selbstständig. Das ist echte Agentic Orchestration.

Vergleich & Setup

Agent Teams vs Subagents: Wann man was nutzt

Das ist die Entscheidung, auf die es ankommt. Falsche Wahl = verschwendete Tokens. Vermeide die Agent Swarm Trap.

Nutze Subagents, wenn: Du schnelle, fokussierte Worker brauchst, die berichten. "Recherchiere X und sag mir, was du findest."

Nutze Agent Teams, wenn: Worker Ergebnisse teilen, sich gegenseitig challengen und selbst koordinieren müssen. "Untersuche diesen Bug aus drei Blickwinkeln und debattiert, welche Theorie stimmt."

Setup: 2 Minuten

Agent Teams sind experimentell und standardmäßig deaktiviert. Ein Setting muss geändert werden:

Option 1: settings.json

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

Option 2: Environment Variable

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Das war's. Jetzt sag Claude einfach in natürlicher Sprache, dass ein Team erstellt werden soll:

I'm refactoring the auth module. Create an agent team:

• One teammate on the backend JWT logic
• One on the frontend session handling
• One writing integration tests

Claude spawnt das Team, erstellt eine Shared Task List und beginnt mit der Koordination.

Modes, Use Cases & Tipps

Anzeigemodi

Zwei Optionen, wie du dein Team siehst:

1. In-process (Default): Alle Teammates laufen in deinem Terminal. Nutze Shift+Up/Down, um einen Teammate auszuwählen. Enter zeigt die Session, Escape unterbricht. Funktioniert überall.
2. Split panes: Jeder Teammate bekommt einen eigenen Terminal-Pane. Du siehst alle Outputs gleichzeitig. Erfordert tmux oder iTerm2.

Setze es in der settings.json:

{
  "teammateMode": "in-process"
}

Oder per Session: claude --teammate-mode in-process. Split Panes sehen cool aus, aber In-Process funktioniert in jedem Terminal. Starte dort.

Die besten Use Cases

Nach dem Durcharbeiten der Docs und Features sind dies die Setups, die die Token-Kosten wert sind. Ähnlich wie ich meine Claude Code Architecture aufgebaut habe, geht es hier um Skalierung.

1. Parallel Code Review

Ein Reviewer tendiert zu einer Art von Problemen. Drei Reviewer mit verschiedenen Linsen fangen mehr. Erstelle ein Agent Team für PR #142:

• Security Reviewer: Token Handling, Input Validation, Auth Flows.
• Performance Reviewer: N+1 Queries, Memory Leaks, unnötige Renders.
• Test Reviewer: Coverage Lücken, Edge Cases, Flaky Tests.

Der Lead synthetisiert alles.

2. Debugging mit konkurrierenden Hypothesen

Das ist der Killer-Use-Case. Einzelne Agenten finden eine plausible Erklärung und hören auf. Mehrere Agenten, die gegeneinander argumentieren, finden die richtige Erklärung.

Spawn 5 Teammates, um verschiedene Hypothesen zu untersuchen. Lass sie miteinander reden, um die Theorien der anderen zu widerlegen. Update Findings mit dem Konsens, der entsteht. Parallele Investigation mit Debatte fördert die stärkste Theorie zutage.

3. Multi-Modul Feature Work

Wenn ein Feature Frontend, Backend und Tests umfasst—jeder Teammate besitzt einen Layer. Keine File-Konflikte.

• Teammate 1: Backend API Endpoints & DB Schema.
• Teammate 2: Frontend Components & State.
• Teammate 3: E2E Tests.

Pro Tipps

• Plan Approval für Risikoreiches: Teammates arbeiten im Read-Only Plan Mode, bis der Lead den Ansatz genehmigt.
• Delegate Mode: Wenn der Lead codet statt zu koordinieren -> Shift+Tab drückt ihn zurück in den Orchestration-Mode (Spawning, Messaging, Task Management). Kein Code anfassen.
• Kontext geben: Sie laden CLAUDE.md automatisch, erben aber nicht die History des Leads. Pack task-spezifische Details in den Spawn-Prompt.
• File-Konflikte vermeiden: Zwei Teammates im selben File = Overwrites. Teile Arbeit so auf, dass jeder Teammate andere Files besitzt.

Limits & Fazit

Die ehrlichen Limits

Das ist experimentell. Wisse, worauf du dich einlässt:

• Keine Session Resumption: /resume und /rewind stellen In-Process Teammates nicht wieder her. Wenn du resumest, versucht der Lead vielleicht Teammates zu erreichen, die nicht mehr existieren.
• Token-Kosten sind real: Ein 5-Personen Team verbrennt grob 5x die Tokens einer Single Session. Für Routine-Tasks lohnt sich das nicht.
• Ein Team pro Session: Räum das aktuelle Team auf, bevor du ein neues startest. Teammates können keine eigenen Teams spawnen.
• Split Panes brauchen tmux/iTerm2: Funktioniert nicht im VS Code Integrated Terminal.

Aufräumen

Wenn du fertig bist: Clean up the team.

Der Lead checkt auf aktive Teammates und failt, wenn noch welche laufen. Fahr sie zuerst runter: "Ask the researcher teammate to shut down". Räum immer über den Lead auf. Wenn eine tmux Session hängen bleibt: tmux kill-session -t <session-name>.

Das Urteil

Agent Teams sind das interessanteste Feature im Opus 4.6 Release—und das teuerste.

Für Code Reviews, Adversarial Debugging und Multi-Modul Features findet die parallele Exploration Dinge, die ein einzelner Agent übersehen würde. Das Pattern der konkurrierenden Hypothesen ist das Lernen allein schon wert.

Für sequentielle Tasks oder Edits im selben File: Bleib bei Subagents oder einer einzelnen Session. Der Overhead lohnt sich nicht.

Wir bewegen uns weg von statischen Abläufen. Das ist ein weiterer Schritt dahin, warum Static Middleware is Dead. Starte mit einem Read-Only Task—einem Code Review—bevor du dich an parallelisierte Implementierung wagst.