Du hast ein Feature, das drei Dinge gleichzeitig braucht. Du kannst Subagents innerhalb einer einzelnen Claude Code Session spawnen und sie parallel arbeiten lassen. Oder du teilst die Arbeit in drei unabhängige Tasks auf, gibst jeden einem separaten Agenten in einem eigenen tmux-Pane und lässt sie laufen, ohne voneinander zu wissen.

Beide Ansätze parallelisieren Arbeit. Sie lösen unterschiedliche Probleme. Wähle den falschen und du verbrennst entweder Context Window für Koordinations-Overhead oder erzeugst Merge-Konflikte, deren Behebung länger dauert als der ursprüngliche Task.

Das ist das Entscheidungs-Framework, das ich jeden Tag verwende, während ich 13 Claude Code Agenten auf derselben Codebase laufen lasse. Keine Theorie. Das Ergebnis davon, es oft genug falsch gemacht zu haben, um zu wissen, wo die Grenze verläuft.

Zwei Arten von Parallelismus

Claude Code unterstützt zwei grundlegend verschiedene Wege, Arbeit gleichzeitig auszuführen.

Subagents sind Kindprozesse, die innerhalb einer einzelnen Claude Code Session gestartet werden. Der Parent-Agent startet mehrere Subagents, jeder bearbeitet einen Teil des Problems, dann sammelt er die Ergebnisse ein. Sie teilen das gleiche Arbeitsverzeichnis und den Context des Parents. Stell sie dir als Threads in einem einzelnen Prozess vor.

Parent agent
  ├── Subagent A: "Search lib/ for all usages of parseConfig"
  ├── Subagent B: "Search server/ for all usages of parseConfig"
  └── Subagent C: "Search components/ for all usages of parseConfig"

Separate Agenten laufen in unabhängigen Claude Code Sessions, typischerweise in separaten tmux-Panes. Jeder hat sein eigenes Context Window, seine eigene CLAUDE.md-Identitätsdatei und seine eigene Sicht auf die Codebase. Sie teilen keinen Speicher. Sie kommunizieren über Artefakte: Task-Kommentare, Status-Updates, committeten Code. Stell sie dir als separate Prozesse ohne Shared State vor.

tmux pane 1: eng1 agent → "Build the REST endpoint"
tmux pane 2: eng2 agent → "Build the React component"
tmux pane 3: qa1 agent  → "Write integration tests for both"

Das mentale Modell ist wichtig, weil es bestimmt, wie Arbeit zwischen den Einheiten fließt. Subagents können Daten günstig an den Parent zurückgeben. Separate Agenten reichen Daten über das Dateisystem, Git oder einen externen Task-Tracker weiter.

Wann Subagents gewinnen

Verwende Subagents, wenn die Arbeit einen gemeinsamen State hat und die Ergebnisse zusammengeführt werden müssen.

Parallele Recherche. Du musst fünf Verzeichnisse nach einem Muster durchsuchen, drei Dokumentationsdateien lesen und die Erkenntnisse zu einer Empfehlung zusammenfassen. Subagents können jeweils einen Suchpfad übernehmen, Ergebnisse zurückgeben, und der Parent kann sie ohne Serialisierungs-Overhead kombinieren.

Unabhängige Transformationen auf denselben Daten. Du refactorst ein Modul und musst die Type Definitions, die Tests und die Dokumentation in einer kohärenten Änderung aktualisieren. Jeder Subagent kümmert sich um eine Datei, aber der Parent stellt sicher, dass die Änderungen konsistent sind, weil er alle drei Ergebnisse sieht, bevor er committet.

Schnelle Exploration. Du debuggst und musst gleichzeitig das Git-Log, die Test-Ausgabe und die Runtime-Config prüfen. Subagents können alle drei parallel sammeln und der Parent erstellt eine Diagnose.

Das Muster: Auffächern, einsammeln, auf dem kombinierten Ergebnis handeln. Wenn deine Parallelisierung damit endet, dass der Parent über alle Outputs zusammen nachdenken muss, sind Subagents das richtige Werkzeug.

Wobei Subagents schlecht abschneiden: Alles was mehr als ein paar Minuten pro Branch dauert, alles was Dateien in überlappenden Pfaden modifiziert, oder alles was eine unabhängige Verifizierung braucht. Subagents teilen ein Arbeitsverzeichnis, also korrumpieren zwei Subagents, die in dieselbe Datei schreiben, gegenseitig ihre Arbeit. Und weil sie den Context teilen, frisst ein langläufiger Subagent in das verfügbare Window des Parents.

Wann separate Agenten gewinnen

Verwende separate Agenten, wenn die Arbeit unabhängig verifiziert werden kann und keinen gemeinsamen Context braucht, um Sinn zu ergeben.

Verschiedene Komponenten desselben Features. "Baue den API-Endpoint" und "Baue das Frontend, das ihn aufruft" sind bis zur Integration unabhängig. Der API-Ingenieur braucht die React-Komponente nicht im Context. Der Frontend-Ingenieur braucht nicht das Datenbankschema. Jedem seinen eigenen Agenten mit einer scoped CLAUDE.md zu geben hält den Context sauber und verhindert, dass die Komplexität eines Agenten in die Arbeit des anderen blutet.

Unterschiedliche Akzeptanzkriterien. Wenn Task A erledigt ist, sobald der Endpoint 200 mit der korrekten JSON-Shape zurückgibt, und Task B erledigt ist, sobald die Komponente die Daten mit korrekten Error States rendert, sind das separate Verifizierungsziele. Ein QA-Agent kann jeden unabhängig validieren. Subagents können nicht unabhängig geprüft werden, weil sie einen kombinierten Output produzieren.

Arbeit, die verschiedene Teile der Codebase berührt. File Ownership ist der einfachste Weg, Merge-Konflikte zu vermeiden. Agent A besitzt server/, Agent B besitzt components/. Keiner greift in das Territorium des anderen. Wenn du das mit Subagents versuchst, müsste der Parent File-Locking verwalten, was den Zweck der Parallelisierung zunichtemacht.

Tasks mit unterschiedlichen Zeithorizonten. Ein Task dauert 10 Minuten, der andere 2 Stunden. Bei Subagents wartet der Parent auf das langsamste Kind. Bei separaten Agenten wird der kurze Task fertig, verifiziert und geshippt, während der lange noch läuft.

Das Muster: Abfeuern, vergessen, separat verifizieren. Wenn jedes Arbeitsstück für sich steht und einzeln geprüft werden kann, sind separate Agenten mit strukturierten Tasks sauberer.

Das Übergabe-Problem

Der eigentliche Entscheidungspunkt läuft auf Übergaben hinaus.

Subagent-Übergaben sind günstig. Das Kind gibt Daten an den Parent im selben Context zurück. Keine Serialisierung, keine File-Writes, kein Warten auf Status-Updates. Der Parent startet drei Subagents, sie liefern drei Ergebnisse, der Parent hat alles was er braucht.

Übergaben zwischen separaten Agenten sind teuer, aber langlebig. Agent A schließt Arbeit ab, committet Code, aktualisiert einen Task-Status und kommentiert, was er getan hat. Agent B nimmt dieses Signal auf (entweder über einen Koordinator oder durch Polling des Task-Trackers) und startet seine abhängige Arbeit. Der Overhead ist real: Du brauchst ein Task-System, ein Status-Protokoll und einen Weg für Agenten, zu erfahren, was andere Agenten getan haben.

Die Faustregel: Wenn die Arbeit mehr als eine Übergabe zwischen den parallelen Einheiten erfordert, verwende Subagents. Bei einem einzelnen Fan-out-and-gather sind Subagents einfacher. Wenn der Output von Agent A der Input von Agent B ist, der zum Input von Agent C wird, sind die Koordinationskosten separater Agenten gerechtfertigt, weil jede Übergabe ein verifiziertes, committetes Artefakt produziert, das nicht verloren geht, wenn ein Agent abstürzt oder an ein Context-Limit stößt.

Ein konkretes Beispiel. Du musst:

Alle API-Endpoints finden, die User-Daten zurückgeben
Rate Limiting zu jedem hinzufügen
Tests für die neuen Rate Limits schreiben
Die API-Dokumentation aktualisieren

Schritte 1 und 2 sind eng gekoppelt. Die Suchergebnisse (Schritt 1) fließen direkt in die Änderung (Schritt 2). Ein Subagent übernimmt die Suche; der Parent wendet die Änderungen an. Das ist ein Subagent-Pattern.

Schritte 3 und 4 sind voneinander unabhängig, hängen aber von Schritt 2 ab. Die Tests brauchen den tatsächlichen Endpoint-Code. Die Docs brauchen die finale API-Shape. Das sind separate Tasks für separate Agenten, jeder mit eigenen Akzeptanzkriterien, jeder für sich verifizierbar.

Strukturierte Task-Aufteilung in der Praxis

Wenn die Antwort "separate Agenten" lautet, brauchst du eine Methode, das Feature in Tasks zu zerlegen, die parallel laufen können, ohne sich gegenseitig in die Quere zu kommen.

Der Zerlegungsprozess:

1. Den Dependency Graph identifizieren. Bevor du irgendetwas aufteilst, zeichne auf, was von was abhängt:

Feature: User profile page with activity feed

- API endpoint: GET /users/:id/profile     (no deps)
- API endpoint: GET /users/:id/activity     (no deps)
- React component: ProfileHeader            (depends on profile API)
- React component: ActivityFeed             (depends on activity API)
- Integration test: profile page end-to-end (depends on all above)

Die zwei API-Endpoints haben keine Abhängigkeiten. Sie können parallel laufen. Die zwei React-Komponenten hängen jeweils von einer API ab. Der Integrationstest hängt von allem ab.

2. Ownership-Grenzen ziehen. Jeder Task bekommt einen File-Scope. Der Profile-API-Agent besitzt server/routes/profile.ts und server/services/profile.ts. Der Activity-API-Agent besitzt server/routes/activity.ts und server/services/activity.ts. Keiner fasst die Dateien des anderen an. Wenn eine gemeinsame Utility geändert werden muss, erstellt ein Agent die Änderung und der andere wartet.

3. Akzeptanzkriterien pro Task definieren. Jeder Task braucht eine klare "fertig"-Bedingung, die verifiziert werden kann, ohne die anderen Tasks anzuschauen. "Profile API gibt 200 mit korrekter Shape zurück" ist verifizierbar. "Profilseite funktioniert" nicht, weil es von der Integration abhängt.

4. Übergabe-Artefakte spezifizieren. Was braucht ein nachgelagerter Agent von einem vorgelagerten? Normalerweise: committeten Code auf einem bekannten Branch, ein Status-Update und einen Kommentar, der den Interface-Contract beschreibt (API-Shape, Component Props, Funktionssignaturen).

Diese Zerlegung verwandelt ein vages "baue die Profilseite" in fünf diskrete Tasks mit expliziten Abhängigkeiten und Verifizierungskriterien. Jeder Task kann einem Agenten zugewiesen werden, der genau den Context hat, den er braucht, und nicht mehr.

Beads für strukturierte Aufteilung

Hier wird ein echtes Task-System wichtig. Du kannst fünf parallele Tasks nicht mit Klebezetteln und Terminal-Output tracken.

beads ist ein Local-first Issue-Tracker, der diese Zerlegung nativ modelliert. Ein Epic repräsentiert das Feature. Children repräsentieren die Subtasks. Dependencies verhindern, dass Agenten Arbeit beginnen, bevor die Voraussetzungen erfüllt sind.

So sieht die Aufteilung in der Praxis aus:

# Create the epic
bd create --title "User profile page with activity feed" \
  --type epic --priority p2

# Create subtasks as children
bd create --title "GET /users/:id/profile endpoint" \
  --parent bb-epic1 --type task --priority p2

bd create --title "GET /users/:id/activity endpoint" \
  --parent bb-epic1 --type task --priority p2

bd create --title "ProfileHeader React component" \
  --parent bb-epic1 --type task --priority p2 \
  --deps bb-profile-api

bd create --title "ActivityFeed React component" \
  --parent bb-epic1 --type task --priority p2 \
  --deps bb-activity-api

bd create --title "Profile page integration test" \
  --parent bb-epic1 --type task --priority p2 \
  --deps bb-profile-header,bb-activity-feed

Die Struktur ist jetzt explizit. Ein Agent, der bd show bb-profile-header ausführt, sieht, dass er vom Profile-API-Task abhängt. Wenn dieser Task noch nicht erledigt ist, weiß der Agent, dass er nicht starten soll. Wenn der API-Agent fertig ist und seinen Task als abgeschlossen markiert, wird die Dependency des Frontend-Agenten aufgelöst.

Der Agent-Workflow folgt einem vorhersehbaren Ablauf:

# Agent claims the task
bd update bb-profile-api --claim --actor eng1

# Agent comments its plan before writing code
bd comments add bb-profile-api --author eng1 "PLAN:
1. Create route handler at server/routes/profile.ts
2. Add service layer at server/services/profile.ts
3. Return shape: { id, name, avatar, bio, joinedAt }
4. Test: curl localhost:3000/users/1/profile returns 200"

# Agent implements, tests, commits
# ...

# Agent marks done with verification steps
bd comments add bb-profile-api --author eng1 "DONE: Profile endpoint implemented.
Returns { id, name, avatar, bio, joinedAt }.
Verified: curl returns 200 with correct shape.
Commit: abc1234"

bd update bb-profile-api --status ready_for_qa

Jeder Schritt wird aufgezeichnet. Der QA-Agent liest den DONE-Kommentar und weiß genau, wie er verifizieren soll. Der nachgelagerte Agent liest den PLAN-Kommentar und kennt den API-Contract, bevor der Code überhaupt fertig ist.

Das ist kein Overhead um des Prozesses willen. Es ist die Mindeststruktur, die verhindert, dass fünf parallele Agenten fünf inkompatible Codestücke produzieren.

Die Wahl als Standard

Nach Monaten des Betriebs paralleler Agenten an Produktions-Code ist das mein Entscheidungsbaum:

Starte mit Subagents, wenn:

Der Task Recherche oder Exploration ist (Suchen, Lesen, Vergleichen)
Ergebnisse in einer einzelnen Aktion konvergieren müssen
Die gesamte Arbeit in ein Context Window passt
Keine unabhängige Verifizierung der einzelnen parallelen Einheiten nötig ist

Wechsle zu separaten Tasks, wenn:

Verschiedene Teile der Arbeit verschiedene Dateien berühren
Jedes Stück eigene Akzeptanzkriterien hat
Du möchtest, dass QA Teile unabhängig verifiziert
Die Arbeit lang genug dauert, dass ein Teil Stunden vor einem anderen fertig sein könnte
Agenten unterschiedlichen Context brauchen (ein Frontend-Agent braucht keine Datenbank-Interna)

Der hybride Ansatz für komplexe Features: Verwende Subagents für die Recherche- und Planungsphase (auffächern, Informationen sammeln, einen Plan synthetisieren), dann zerlege die Implementierung in separate Tasks für unabhängige Agenten. Der Spec-Driven Development Workflow passt hier natürlich: Ein einzelner Agent mit Subagents schreibt die Spec, dann wird die Spec in Tasks für die Multi-Agent-Flotte zerlegt.

Die Aufteilung visualisieren

Sobald du fünf oder zehn strukturierte Tasks mit Abhängigkeiten untereinander hast, wird die Fortschrittsverfolgung im Terminal schwierig. bd list zeigt eine flache Liste. Es zeigt nicht, welche Tasks blockiert sind, welche bereit zum Start sind oder wie weit das Epic fortgeschritten ist.

Das ist das Problem, das Beadbox löst. Es liest die gleiche beads-Datenbank und rendert Epic-Bäume mit Fortschrittsanzeigen, Abhängigkeitsbeziehungen und Agenten-Zuweisungen. Du siehst, welche Subtasks erledigt sind, welche auf Voraussetzungen blockiert sind und welche bereit sind, von einem Agenten aufgegriffen zu werden. Der Dependency Graph, den du mit --deps spezifiziert hast, wird zu einer visuellen Karte deiner parallelen Arbeit.

Wenn ein Agent einen Task abschließt und den Status aktualisiert, spiegelt Beadbox die Änderung in Echtzeit wider. Kein Refresh, kein erneutes bd list. Der Baum aktualisiert sich, der Fortschrittsbalken bewegt sich, und blockierte Tasks werden freigegeben, wenn ihre Dependencies aufgelöst werden.

Dieselben Daten. Nur sichtbar.

Wenn du Workflows wie diese aufbaust, gib Beadbox einen Stern auf GitHub.

Claude Code Subagents vs. strukturierter Task-Aufteilung: Wann was verwenden