Claude · 10 Min.
Claude Code Subagents: Wie Teams 2026 Arbeit in Agenten-Slices schneiden
Subagents sind keine Prompt-Personas. Richtig eingesetzt sind sie ein Organisationsmuster für parallele, prüfbare Softwarearbeit.
SYSTEMS Grafik zu Claude Code Subagents: Explore -> Plan -> Verify. Fokus: Wie nutzen Teams Subagents in Claude Code, ohne Chaos im Codebase-Workflow zu erzeugen?
Kurzfassung
Subagents sind spezialisierte Arbeitskontexte mit eigener Beschreibung, eigenen Toolrechten und optionaler Isolation. Der entscheidende Skill ist nicht Prompt-Länge, sondern Task-Slicing. Parallele Agentenarbeit braucht Ownership, Review-Gates und klare Integrationsverantwortung.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Subagents sind keine Personas Der größte Denkfehler bei Claude Code Subagents ist, sie wie Chat-Personas zu behandeln: "Du bist Reviewer", "Du bist Tester", "Du bist Security-Experte." Das ist zu flach.
Die aktuelle Claude-Code-Dokumentation zeigt ein anderes Bild. Subagents können eigene Tools, verbotene Tools, Modelle, Permission Modes, MCP-Server , Hooks, Skills, Memory, Background-Verhalten, maximale Turns und Worktree-Isolation haben.
Das macht Subagents zu einer Architekturfrage. Ein Team entscheidet nicht nur, was ein Agent tun soll. Es entscheidet, welchen Kontext, welche Rechte und welche Grenzen dieser Agent bekommt.
Warum Subagents Teams wirklich helfen Ein einzelner Agent kann viel leisten, aber sein Kontext wird schnell unübersichtlich. Sobald Exploration, Planung, Implementierung, Tests, Review und Dokumentation in derselben Session liegen, steigt das Risiko für falsche Annahmen.
Subagents trennen Arbeit in klarere Zuständigkeiten:
So bleibt die Hauptsession der Integrator. Sie entscheidet, was zusammenpasst, statt alles selbst im Kopf zu halten.
Ein Explorer liest Code und findet echte Pfade, ohne zu schreiben. Ein Worker implementiert einen eng geschnittenen Slice. Ein Reviewer prüft Diff, Risiken und fehlende Tests. Ein Test-Runner findet passende Kommandos und analysiert Fehler. Ein Security-Agent schaut auf Auth, Secrets, RLS, Rollen und API-Grenzen. Gute Slices statt grosse Aufträge "Baue das komplette Dashboard neu" ist keine gute Subagent-Aufgabe. Sie ist zu breit, schwer prüfbar und erzeugt Konflikte.
Gute Subagent-Aufgaben haben harte Grenzen:
Ein Beispiel für einen schlechten Auftrag: "Verbessere die Admin-Experience." Ein guter Auftrag: "Bearbeite nur `src/pages/admin/Contacts.tsx` und `src/components/admin/contact-table.tsx`. Ziel: Suchfilter entprellen, leere Zustände verbessern, bestehende API nicht ändern. Test: Typecheck und manueller Filterfall."
ein klarer Zielzustand ein begrenzter Schreibbereich konkrete Dateien oder Module eindeutige Tests ein erwartetes Ergebnisformat definierte Stop-Bedingungen Toolrechte sind Produktivitätshebel Viele Teams geben jedem Agenten alle Tools. Das führt flexibel an, ist aber selten sauber.
Claude Code erlaubt Toolrestriktionen und `disallowedTools`. Ein read-only Explorer braucht keine Schreibrechte. Ein Reviewer braucht nicht deployen. Ein Test-Agent muss nicht an Supabase-Migrations schreiben. Ein Worker braucht eventuell Edit-Rechte, aber nur in seinem Modul.
Das ist kein Misstrauen gegen AI. Es ist gute Systemarchitektur. Menschen bekommen in produktiven Organisationen auch nicht alle Rechte für jedes System.
Worktree-Isolation für riskante Parallelität Wenn mehrere Subagents parallel schreiben, entstehen schnell Konflikte. Claude Code unterstützt Worktree-Isolation für Subagents. Damit kann ein Agent in einer isolierten Kopie des Repos arbeiten, statt dieselben Dateien im Hauptarbeitsbaum zu berühren.
Das ist besonders sinnvoll für:
Trotzdem ersetzt Isolation keine Integration. Am Ende muss jemand entscheiden, welcher Patch übernommen wird, welche Tests zählen und welche Änderungen verworfen werden.
größere Refactors konkurrierende Lösungsansätze Testfixes, die parallel zur Feature-Arbeit laufen riskante Experimente Agenten, die viel ausprobieren müssen Hooks machen Subagents kontrollierbar Subagents werden stark, wenn Hooks ihre Lebenszyklen sichtbar machen. `SubagentStart` kann Delegation protokollieren. `SubagentStop` kann prüfen, ob der Agent Evidenz geliefert hat. `TaskCreated` und `TaskCompleted` können helfen, Arbeit nachvollziehbar zu machen.
Damit entsteht ein echtes Agenten-Team statt loser Nebenprozesse. Jede Delegation bekommt Auftrag, Rechte, Ergebnis und Prüfung.
Der Integrator ist die wichtigste Rolle Subagents können Arbeit aufteilen. Sie können aber nicht automatisch garantieren, dass alles zusammenpasst.
Der Integrator muss am Ende prüfen:
In kleinen Teams kann das ein Mensch sein. In reiferen AI-Workflows kann ein Hauptagent integrieren und ein Reviewer-Agent danach gegenprüfen.
Haben zwei Agenten dieselbe Datei verändert? Passen Typen, APIs und UI-Zustände zusammen? Wurden bestehende Patterns eingehalten? Sind Tests wirklich gelaufen? Gibt es neue Security- oder UX-Risiken? Wurde fremde Arbeit versehentlich überschrieben? Der SYSTEMS-Blick Claude Code Subagents sind kein Weg, einfach "mehr AI" auf ein Projekt zu werfen. Sie sind ein Muster für kontrollierte Arbeitsteilung.
Wer Slices sauber schneidet, Toolrechte begrenzt, Worktrees nutzt und Reviews erzwingt, bekommt echte Parallelität. Wer nur viele Agenten startet, bekommt mehr offene Enden.
Die Architektur entscheidet, ob Subagents Output skalieren oder Chaos.
