Praxis-Patterns
Wissen
Subagent oder Agent Team?
Die wichtigste Entscheidung ist: Brauche ich ein Team oder reicht ein Subagent? Hier die klare Abgrenzung:
Subagent -- wenn die Aufgabe:
- Eine klar abgeschlossene Teilaufgabe ist
- Das Ergebnis an den Hauptagenten zurückfließen soll
- Kein eigenständiges, lang laufendes Arbeiten erfordert
- Beispiel: "Recherchiere, wie die Auth-Middleware aufgebaut ist"
Agent Team -- wenn die Aufgabe:
- Aus mehreren unabhängigen Teilaufgaben besteht
- Die Teilaufgaben parallel laufen können
- Die Agents über längere Zeit eigenständig arbeiten
- Beispiel: "Implementiere drei neue API-Endpunkte mit Tests"
*Faustregel
Wenn du die Aufgabe in einem Satz beschreiben kannst und nur ein Ergebnis zurückbrauchst -- nimm einen Subagent. Wenn du eine Todo-Liste mit mehreren unabhängigen Punkten hast -- nimm ein Agent Team.
Pattern 1: Parallele Feature-Entwicklung
Das häufigste Pattern. Der Lead plant die Features, und jeder Teammate implementiert eines in einem eigenen Git Worktree:
Lead: "Wir brauchen drei neue Endpunkte: /users, /posts, /comments"
Teammate 1 (worktree-1): Implementiert /users
Teammate 2 (worktree-2): Implementiert /posts
Teammate 3 (worktree-3): Implementiert /comments
Lead: Mergt die Ergebnisse zusammen
Jeder Teammate arbeitet in einem eigenen Worktree, sodass es keine Git-Konflikte während der Entwicklung gibt. Der Lead mergt am Ende die Branches zusammen.
Wann sinnvoll: Bei klar voneinander getrennten Features, die keine gemeinsamen Dateien verändern.
Pattern 2: Code + Tests parallel
Ein Teammate implementiert das Feature, ein anderer schreibt parallel die Tests:
Lead: "Feature X implementieren und testen"
Teammate 1: Implementiert Feature X
Teammate 2: Schreibt Tests (wartet auf API-Interface, dann parallel)
Lead: Prüft, ob Tests und Implementierung zusammenpassen
Hier nutzt du Dependencies: Die Test-Task hängt davon ab, dass die Interface-Definition (nicht die komplette Implementierung) steht. Sobald Teammate 1 die Interfaces definiert hat, kann Teammate 2 loslegen.
Wann sinnvoll: Bei TDD-nahen Workflows oder wenn du sicherstellen willst, dass Tests nicht "auf die Implementierung geschrieben" werden.
Pattern 3: Review + Fix parallel
Ein Teammate reviewt Code, ein anderer behebt die gefundenen Issues:
Lead: "Codebase-Review und Fixes für das auth-Modul"
Teammate 1: Reviewt den Code, erstellt Issues als Tasks
Teammate 2: Nimmt abgeschlossene Review-Tasks und fixt sie
Lead: Prüft die Fixes und schließt den Review ab
Hier arbeiten die Teammates in einer Pipeline: Teammate 1 produziert Review-Findings als Tasks, Teammate 2 konsumiert und bearbeitet sie. Das Messaging-System wird genutzt, um den Fix-Teammate über Prioritäten zu informieren.
Wann sinnvoll: Bei größeren Code Reviews oder Refactorings, bei denen Review und Fix Hand in Hand gehen.
Du musst eine einzelne Funktion refactoren und willst sicherstellen, dass alle Aufrufer aktualisiert werden. Subagent oder Agent Team?
Verstehen
Kostenabwägung
!Kosten im Blick behalten
Jeder Teammate ist eine eigene Claude-Instanz mit eigenem Context Window. Das bedeutet: Die Kosten skalieren linear mit der Anzahl der Teammates.
Eine realistische Kosteneinschätzung:
| Setup | Ungefähre Kosten* |
|---|---|
| 1 Agent (normal) | 1x Basis |
| Lead + 2 Teammates | ~3x Basis |
| Lead + 4 Teammates | ~5x Basis |
*Die tatsächlichen Kosten hängen von der Aufgabenkomplexität und der Session-Dauer ab.
Wann sich Teams finanziell lohnen: Wenn die Zeitersparnis die Mehrkosten rechtfertigt. Drei Features in 10 Minuten statt in 30 Minuten -- bei gleichen Kosten pro Feature -- können den 3x-Aufschlag wert sein, wenn deine Zeit teurer ist als die API-Kosten.
Wann du bei Subagents bleiben solltest: Bei Aufgaben, die sequenziell ablaufen müssen, oder bei knappem Budget. Ein einzelner Agent, der drei Aufgaben nacheinander erledigt, kostet weniger als drei parallele Agents.
Vergleichstabelle: Subagents vs. Agent Teams
| Kriterium | Subagents | Agent Teams |
|---|---|---|
| Aktivierung | Automatisch oder per Prompt | Feature-Flag + expliziter Start |
| Kosten | Niedrig (teils Haiku) | Hoch (jeder Teammate = volle Instanz) |
| Parallelität | Begrenzt | Echte Parallelität |
| Kommunikation | Nur Ergebnis zurück | Messages + Broadcasts |
| Koordination | Keine nötig | Shared Task List |
| Komplexität | Niedrig | Mittel bis hoch |
| Stabilität | Produktionsreif | Experimentell |
| Typischer Einsatz | Recherche, Planung, Einzelaufgaben | Parallele Features, große Refactorings |
| Git-Workflow | Optional Worktree | Worktrees empfohlen |
| Session-Resume | Nicht relevant (kurzlebig) | Nur Lead, nicht Teammates |
Anwenden
Checkliste: Ist ein Agent Team sinnvoll?
Bevor du ein Agent Team startest, prüfe diese Punkte:
- Hast du mindestens zwei unabhängige Aufgaben, die parallel laufen können?
- Sind die Aufgaben groß genug, dass die Parallelität einen spürbaren Zeitvorteil bringt?
- Sind die Aufgaben in verschiedenen Dateien/Modulen, sodass es keine Merge-Konflikte gibt?
- Ist das Kostenbudget vorhanden? (Rechne mit N+1 Instanzen für N Teammates)
- Bist du bereit, mit einem experimentellen Feature zu arbeiten?
Wenn du weniger als drei Punkte abhaken kannst, bleib bei Subagents.
Reflektieren
Agent Teams sind ein mächtiges Werkzeug, aber kein Allheilmittel. Die richtige Entscheidung zwischen Subagent und Agent Team hängt von der Aufgabenstruktur, dem Budget und der Risikobereitschaft ab. Starte klein -- ein Lead mit zwei Teammates und klaren, unabhängigen Tasks -- und steigere die Komplexität, wenn du Erfahrung gesammelt hast.