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 fuer parallele, pruefbare 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-Laenge, sondern Task-Slicing. Parallele Agentenarbeit braucht Ownership, Review-Gates und klare Integrationsverantwortung.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten Architekturentscheidungen.
Subagents sind keine Personas Der groesste 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 koennen 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 unuebersichtlich. Sobald Exploration, Planung, Implementierung, Tests, Review und Dokumentation in derselben Session liegen, steigt das Risiko fuer falsche Annahmen.
Subagents trennen Arbeit in klarere Zustaendigkeiten:
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 prueft 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 Auftraege "Baue das komplette Dashboard neu" ist keine gute Subagent-Aufgabe. Sie ist zu breit, schwer pruefbar und erzeugt Konflikte.
Gute Subagent-Aufgaben haben harte Grenzen:
Ein Beispiel fuer 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 Zustaende verbessern, bestehende API nicht aendern. 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 Produktivitaetshebel Viele Teams geben jedem Agenten alle Tools. Das fuehlt 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 fuer jedes System.
Worktree-Isolation fuer riskante Parallelitaet Wenn mehrere Subagents parallel schreiben, entstehen schnell Konflikte. Claude Code unterstuetzt Worktree-Isolation fuer Subagents. Damit kann ein Agent in einer isolierten Kopie des Repos arbeiten, statt dieselben Dateien im Hauptarbeitsbaum zu beruehren.
Das ist besonders sinnvoll fuer:
Trotzdem ersetzt Isolation keine Integration. Am Ende muss jemand entscheiden, welcher Patch uebernommen wird, welche Tests zaehlen und welche Aenderungen verworfen werden.
groessere Refactors konkurrierende Loesungsansaetze Testfixes, die parallel zur Feature-Arbeit laufen riskante Experimente Agenten, die viel ausprobieren muessen Hooks machen Subagents kontrollierbar Subagents werden stark, wenn Hooks ihre Lebenszyklen sichtbar machen. `SubagentStart` kann Delegation protokollieren. `SubagentStop` kann pruefen, ob der Agent Evidenz geliefert hat. `TaskCreated` und `TaskCompleted` koennen helfen, Arbeit nachvollziehbar zu machen.
Damit entsteht ein echtes Agenten-Team statt loser Nebenprozesse. Jede Delegation bekommt Auftrag, Rechte, Ergebnis und Pruefung.
Der Integrator ist die wichtigste Rolle Subagents koennen Arbeit aufteilen. Sie koennen aber nicht automatisch garantieren, dass alles zusammenpasst.
Der Integrator muss am Ende pruefen:
In kleinen Teams kann das ein Mensch sein. In reiferen AI-Workflows kann ein Hauptagent integrieren und ein Reviewer-Agent danach gegenpruefen.
Haben zwei Agenten dieselbe Datei veraendert? Passen Typen, APIs und UI-Zustaende zusammen? Wurden bestehende Patterns eingehalten? Sind Tests wirklich gelaufen? Gibt es neue Security- oder UX-Risiken? Wurde fremde Arbeit versehentlich ueberschrieben? Der SYSTEMS-Blick Claude Code Subagents sind kein Weg, einfach "mehr AI" auf ein Projekt zu werfen. Sie sind ein Muster fuer kontrollierte Arbeitsteilung.
Wer Slices sauber schneidet, Toolrechte begrenzt, Worktrees nutzt und Reviews erzwingt, bekommt echte Parallelitaet. Wer nur viele Agenten startet, bekommt mehr offene Enden.
Die Architektur entscheidet, ob Subagents Output skalieren oder Chaos.
