Claude Code Subagenten: Spezialisierte KI-Helfer nutzen

Stell dir vor, du hast ein kleines Team von Spezialisten an deiner Seite: Eine Person kümmert sich nur um Code-Reviews, eine andere schreibt Tests, eine dritte durchforstet die Doku. Genau dieses Gefühl bekommst du mit Claude Code Subagenten. Ein Subagent ist wie ein spezialisierter Mitarbeiter, dem du eine klar umrissene Teilaufgabe gibst – und der sie erledigt, ohne dass du selbst jeden Schritt begleiten musst. In diesem Artikel zeige ich dir als Solopreneur oder Entwickler, was Subagenten eigentlich sind, wozu sie taugen, wie du dir deine eigenen kleinen Helfer baust und welche Fehler du dir gleich sparen kannst. Keine Sorge: Es bleibt praxisnah, und Fachbegriffe erkläre ich unterwegs. Und falls Claude Code bei dir noch nicht eingerichtet ist, findest du den Einstieg in der Claude Code Anleitung.

Was sind Subagenten in Claude Code?

Subagenten sind eigenständige Helfer innerhalb von Claude Code. Das Besondere: Jeder Subagent arbeitet mit einem eigenen Kontextfenster. Das Kontextfenster ist quasi der „Arbeitsspeicher“ oder das Kurzzeitgedächtnis der KI – also alles, was sie in einem Gespräch gerade im Blick hat. Wenn du selbst mit Claude Code chattest, läuft das im Hauptkontext. Ein Subagent bekommt dagegen seinen eigenen, frischen Arbeitsspeicher.

Wichtig zu verstehen: Ein Subagent ist kein Fork und kein Thread deiner Sitzung. Es ist eine separate Claude-Instanz, die dein Haupt-Agent (der „Lead“) kurz zum Leben erweckt. Anthropic beschreibt Subagenten in der offiziellen Claude-Code-Dokumentation als isolierte Agent-Instanzen, die fokussierte Teilaufgaben übernehmen – mit eigenem Kontext, eigenen Anweisungen und eigenen Rechten.

Vier Dinge, die jeder Subagent mitbringt

Ein Subagent ist kein Klon von dir und deinem Chatverlauf. Er bekommt vier eigene Sachen mit auf den Weg:

• Ein eigenes Kontextfenster, komplett getrennt von deiner Hauptsitzung.
• Eigene Tool-Berechtigungen. Du kannst ihn zum Beispiel auf reines Lesen beschränken. Ein Reviewer, der nichts kaputt machen kann? Sehr beruhigend.
• Einen eigenen System-Prompt. Das ist seine Rollenbeschreibung – was er ist, wie er arbeitet, was er zurückgeben soll.
• Optional ein eigenes Modell. Mechanische Arbeit auf Haiku, knifflige Analyse auf Opus. Dazu gleich mehr.

Das asymmetrische Prinzip

Jetzt kommt der Teil, den viele unterschätzen. Der Subagent bekommt beim Start nur den Dispatch-Prompt, deine CLAUDE.md und den Projektstand – nicht deinen kompletten Gesprächsverlauf. Und zurück gibt er ausschließlich seine finale Zusammenfassung. Alles dazwischen – die 40 gelesenen Dateien, die Grep-Treffer, die Sackgassen – bleibt in seinem Kontext und berührt deinen Hauptchat nie.

Ich finde das Bild vom Tech-Lead ziemlich treffend: Du bekommst die Pull-Request-Beschreibung, nicht das Arbeitsprotokoll von acht Stunden. Genau das hält deinen Lead-Kontext frei – und ein freier Kontext bedeutet bessere Antworten, auch nach drei Stunden Session.

Wozu sind Claude Code Subagenten gut?

Der größte Gewinn liegt in drei Punkten, die zusammen deinen Arbeitsalltag spürbar entspannen. Erstens kannst du Aufgaben parallelisieren. Während einer die Tests schreibt, prüft ein anderer die Sicherheit. Das spart Zeit, vor allem bei größeren Projekten. Zweitens hältst du deinen Hauptkontext sauber. Du verlierst nicht den Faden, nur weil im Hintergrund 500 Zeilen Log analysiert wurden. Und drittens baust du dir echte Spezialisten statt eines Alleskönners, der alles ein bisschen kann.

Konkret lohnen sich Subagenten vor allem in diesen Situationen:

• Parallele Codebase-Erkundung: Ein Helfer schaut sich die Auth an, einer die Datenbank, einer die API – gleichzeitig, statt nacheinander.
• Schwere Kontextaufgaben: 50 Dateien durchsuchen, drei relevante zurückmelden. Klassische Wühlarbeit, die nichts in deinem Hauptchat verloren hat.
• Spezialisierte Rollen: Reviewer, Security-Prüfer, Test-Schreiber. Jeder mit genau den Anweisungen, die er für seinen Job braucht.
• Unbeeinflusste Reviews: Und das ist mein persönlicher Favorit. Ein Subagent kennt deine Diskussion nicht, in der ihr euch selbst überzeugt habt, dass die Lösung schon passt. Er sieht nur den Code. Frischer Blick, ganz ohne Betriebsblindheit.

Gerade als Solopreneur ohne großes Team fühlst du dich damit, als hättest du plötzlich ein paar fleißige Kollegen, die dir Routinearbeit abnehmen.

Subagent, Skill oder Haupt-Agent – wer macht was?

Bevor du loslegst, klären wir kurz die wichtigste Frage überhaupt. Denn viele bauen einen Subagenten, wo eigentlich ein Skill hingehört – und wundern sich dann über zähe Ergebnisse.

Der Unterschied ist im Kern ganz simpel: Ein Skill läuft im Kontext seines Elterngesprächs, sieht den vollen Verlauf und lässt sein Ergebnis dort auch liegen. Er erbt die Tools und das Modell. Ein Subagent macht ein eigenes Fass auf: eigener Kontext, nur der Dispatch-Prompt als Input, eigene Tool-Allowlist, gern auch ein günstigeres Modell – und zurück kommt nur die finale Nachricht. Der Haupt-Agent ist derjenige, der die ganze Zeit mit dir spricht und alles sieht.

Merk dir am besten diesen Dreiklang: Der Skill lehrt das WIE (eine Prozedur, die Claude anwenden soll). Der Hook erzwingt eine Regel (etwas, das immer passieren muss). Der Subagent isoliert Arbeit (etwas, das woanders passieren soll). Wenn du diese drei sauber auseinanderhältst, sparst du dir eine Menge Frust.

Übrigens schließen die sich nicht aus, im Gegenteil: Ein Subagent kann über das Feld skills: gezielt Skills nachladen. Und ein SubagentStop-Hook kann prüfen, was der Subagent zurückmeldet, bevor es beim Lead landet. Die drei spielen also zusammen.

Wie verwaltest und erstellst du Subagenten?

Der einfachste Einstieg ist der Slash-Command /agents. Slash-Commands sind Befehle, die du direkt in Claude Code mit einem Schrägstrich eintippst. Wenn du /agents eingibst, öffnet sich die Verwaltungsoberfläche: Du siehst deine bestehenden Subagenten, kannst sie bearbeiten und neue anlegen. Genauso gut kannst du Claude einfach bitten: „Bau mir einen Subagenten, der meine Auth-Diffs auf Sicherheitsprobleme prüft.“ Er schreibt dir die Datei dann selbst.

Denn unter der Haube ist jeder Subagent einfach eine Markdown-Datei (eine simple Textdatei mit leichter Formatierung). Sie liegt entweder im Ordner .claude/agents/ deines Projekts – dann gilt sie fürs Projekt und wandert mit ins Git-Repo – oder unter ~/.claude/agents/ in deinem Benutzerordner, dann steht sie dir überall zur Verfügung. Gibt es einen Namenskonflikt, gewinnt die Projektversion. Mein Tipp: Alles, was das Team betrifft, gehört ins Projekt und damit in die Versionskontrolle. So arbeiten nicht drei Leute mit drei leicht unterschiedlichen Reviewern.

Das YAML-Frontmatter: vier Felder, die alles entscheiden

Oben in der Datei steht ein kleiner Info-Block – das sogenannte Frontmatter. Das ist nur ein abgegrenzter Bereich am Dateianfang, eingerahmt von zwei Linien aus drei Bindestrichen. Darin stehen die Eckdaten. Danach folgt der eigentliche Text: der System-Prompt, also die Anweisung, wie sich dein Helfer verhalten soll. Der läuft bei jeder Aktivierung mit.

So sieht eine einfache Subagent-Definition aus:

---
name: code-reviewer
description: >
  Führt ein kritisches Code-Review durch. Wird automatisch nach
  Abschluss eines Features und vor dem Commit aufgerufen.
tools: Read, Grep, Glob, Bash(git diff:*)
model: haiku
---

Du bist ein erfahrener Code-Reviewer.

Wenn du aufgerufen wirst:
- Sieh dir die zuletzt geänderten Dateien an.
- Achte auf Bugs, unklare Benennungen und Sicherheitslücken.
- Gib konkrete, freundliche Verbesserungsvorschläge.

Gib am Ende ein VERDICT zurück: pass oder fail.
Liste Findings immer im Format Datei:Zeile.
Du reparierst nichts selbst.

Die Felder bedeuten konkret: name ist der Aufrufname – kleingeschrieben, mit Bindestrichen, identisch zum Dateinamen. Über ihn sprichst du den Helfer später mit @agent-name an. description erklärt Claude, wann dieser Subagent dran ist. tools ist eine Allowlist der erlaubten Werkzeuge. model legt das KI-Modell fest. Optional kannst du mit color noch eine Farbe für die Oberfläche setzen. Lässt du tools oder model weg, erbt der Subagent einfach die Standardeinstellungen.

Beim Modell hast du die Wahl zwischen Opus 5 (am stärksten, für knifflige Aufgaben), Sonnet 5 (ausgewogen, der Allrounder) und Haiku 4.5 (schnell und günstig für einfache Jobs). Für mechanische Arbeit auf Opus zu setzen, ist wie mit Kanonen auf Spatzen zu schießen – und du zahlst es an der Rechnung.

Ein Detail zu tools, das oft übersehen wird: Du kannst Bash gezielt einschränken. Bash(git diff:*) erlaubt eben nur Diffs und nicht das ganze Terminal. Seit Juni 2026 gibt es dafür eine erweiterte Berechtigungssyntax nach dem Muster Tool(param:value) – damit kannst du zum Beispiel auch Agent(model:opus) verbieten, wenn dir teure Subagenten in die Quere kommen.

Die description ist eine Routing-Regel, kein Jobtitel

Das ist das wichtigste Feld der ganzen Datei, und deshalb bekommt es einen eigenen Abschnitt. Claude entscheidet anhand der description, ob dein Subagent zur aktuellen Aufgabe passt. Das Matching läuft wahrscheinlichkeitsbasiert – eine vage Beschreibung bedeutet also: unzuverlässiges Delegieren.

Schreib deshalb keinen Jobtitel, sondern eine Regel. „Überprüft Code“ ist schwach. „Wird nach Abschluss eines Features und vor dem Commit aufgerufen“ ist stark, weil ein Auslöser drinsteht. Bei einem Doku-Helfer statt „schreibt Texte“ lieber: „Wird verwendet, sobald ein Entwurf fertig ist und vor der Veröffentlichung.“ Du beschreibst nicht, was der Helfer kann, sondern wann er ran soll.

So startet Claude einen Subagenten

Es gibt vier Wege, und du solltest alle vier kennen:

• Automatisch über das Agent-Tool. Claude routet selbst, wenn das Tool erlaubt ist und deine description semantisch passt. Der Name „Task“ ist übrigens seit Version 2.1.63 nur noch ein Alias für „Agent“ – falls du das irgendwo liest.
• Per @mention. Tipp einfach @agent-reviewer src/api/auth.ts überprüfen. Es gibt sogar Type-Ahead, du musst dir also keine Namen merken.
• In normaler Sprache. „Verwende Subagenten, um Auth, DB und API parallel zu erkunden.“ Das Schlüsselwort „parallel“ ist hier wirklich wichtig – lässt du es weg, arbeitet Claude die Sachen gerne mal brav nacheinander ab.
• Über deine CLAUDE.md. Dort legst du das Routing-Verhalten einmal fürs ganze Team fest. Damit gilt es für alle, ohne dass es jemand jedes Mal dazuschreiben muss.

Parallel arbeiten: drei bis fünf sind der Sweet Spot

Bis zu zehn Tasks laufen gleichzeitig, weitere werden in eine Warteschlange gestellt. Der Lead schickt dafür mehrere Task-Aufrufe in einer einzigen Antwort raus. Klingt nach „viel hilft viel“? Ist es nicht.

Denn Parallelität kostet. Drei parallele Subagenten verbrauchen ungefähr das Vierfache eines einzelnen Durchlaufs. Bei den größeren Agent Teams landest du sogar bei etwa dem Siebenfachen. Dafür bekommst du Zeit zurück – aber eben nicht umsonst. In der Praxis haben sich drei bis fünf gleichzeitige Subagenten als guter Kompromiss aus Tempo und Kosten herausgestellt.

Damit das sauber läuft, halte dich an drei Regeln: Parallelisiere nur wirklich unabhängige Arbeitseinheiten, sonst rennen dir zwei Helfer in dieselbe Datei (hallo, Race Conditions). Gib jedem Subagenten eigene Tools und einen eigenen Scope. Und verlange von allen ein einheitliches Zusammenfassungsformat, damit der Lead die Ergebnisse überhaupt vergleichen kann.

Fünf Subagenten, die sich sofort lohnen

Genug Theorie. Das hier sind fünf Helfer, mit denen du in der Praxis am meisten rausholst – inklusive der Tools, die sie brauchen, und dem Modell, das ich dafür wählen würde.

• code-reviewer (Read, Grep, Glob, Bash(git diff) · Haiku): Gibt ein klares VERDICT pass/fail zurück und listet Findings als Datei:Zeile. Wichtig: Er repariert nichts selbst. Reviewen und Reparieren in einem Agenten zu mischen, ist ein Klassiker unter den Fehlern.
• debugger (Read, Grep, Glob, Bash · Sonnet): Kommt zum Einsatz, wenn du schon zwei, drei Anläufe hinter dir hast. Liefert eine Diagnose in der Kette Fehlerpunkt → Ursache → Fix.
• test-writer (Read, Write, Edit, Bash(npm test) · Sonnet): Schreibt Tests und macht sie grün. Einer der wenigen Fälle, in denen ein Subagent auch schreiben darf.
• security-auditor (nur Read, Grep, Glob · Sonnet): Prüft gegen OWASP-Muster, ohne jede Schreibberechtigung. Er soll finden, nicht anfassen.
• doc-writer (Read, Write, Edit, Glob · Haiku): README und API-Dokumentation. Mechanische Arbeit, günstiges Modell, passt.

Wenn du Inspiration für weitere Rollen suchst: In der Community gibt es umfangreiche Sammlungen wie awesome-claude-code-subagents mit über 100 fertigen Definitionen. Kopier die aber bitte nicht blind – übersetz die Idee in dein Projekt, deine Tool-Policy, deine Ordnerstruktur.

Subagenten vs. Skills vs. Plugins

Diese drei Begriffe werden gern verwechselt, machen aber unterschiedliche Dinge:

• Subagenten sind eigenständige Helfer mit eigenem Kontextfenster, die eine Teilaufgabe übernehmen. Denk an einen delegierten Mitarbeiter.
• Skills sind eher Wissens- und Fähigkeitspakete: Anleitungen und Ressourcen, die Claude bei einer bestimmten Art von Aufgabe heranzieht – ohne dafür einen separaten Kontext aufzumachen. Denk an ein Handbuch, das aufgeschlagen wird, wenn es gebraucht wird.
• Plugins sind Bündel, die mehrere Dinge zusammenpacken und verteilbar machen – etwa Slash-Commands, Subagenten oder Skills in einem installierbaren Paket. Denk an eine Toolbox, die du als Ganzes teilen kannst.

Faustregel: Du willst eine Aufgabe delegieren? Subagent. Du willst Claude eine Fähigkeit beibringen? Skill. Du willst mehreres bündeln und weitergeben? Plugin.

Best Practices für Subagenten

Jetzt der Teil, der den Unterschied macht zwischen „nettes Spielzeug“ und „spart mir jede Woche Stunden“.

Subagenten sind Informationssammler, keine Bauarbeiter

Das ist die wichtigste Erkenntnis überhaupt – und sie kommt direkt aus dem Claude-Code-Team rund um Adam Wolf: Subagenten funktionieren am besten als Informationssammler, nicht als Implementierer. Klingt erstmal enttäuschend? Ist es nicht, wenn du verstehst, warum.

Ein Subagent, der implementiert, muss dir am Ende erklären, was er gebaut hat. Und diese Erklärung ist immer schlechter als der Code selbst. Du bekommst eine Zusammenfassung, wo du eigentlich das Original bräuchtest. Deshalb hat sich das Muster Explore → Plan → Execute durchgesetzt: Die Subagenten erkunden (parallel, günstig, lesend), der Haupt-Agent plant und implementiert dann mit dem gesammelten Wissen selbst. Der Lead behält so den vollen Überblick über das, was tatsächlich geschrieben wird.

Plan first, parallelize second

Direkt daraus folgt der zweite Merksatz. Lauf erst mit /plan durchs Projekt – das ist rein lesend und damit günstig. Erst wenn der Plan steht und du ihn abgenickt hast, schickst du ihn ans Agent-Team. Wer sofort fünf Subagenten losschickt, bezahlt dafür, dass sie sich gegenseitig widersprechen.

Die restlichen Regeln in Kurzform

• Eine Aufgabe pro Subagent: Ein Helfer, der reviewt und deployt und dokumentiert, wird mittelmäßig in allem.
• Tools strikt einschränken: Ein Reviewer braucht Read, Grep und Glob. Sonst nichts. Weniger Tools bedeuten weniger Risiko und klareres Verhalten.
• Modell zur Aufgabe wählen: Für einfache, wiederholte Jobs reicht Haiku 4.5. Für anspruchsvolle Reviews lohnt sich Opus 5.
• Versioniere deine Subagenten: .claude/agents/ gehört ins Git. Dann siehst du im Review auch, wenn jemand die Rechte aufweicht.
• Setz einen SubagentStop-Hook als Qualitäts-Gate: Der feuert, bevor die Zusammenfassung beim Lead landet. Damit kannst du zum Beispiel erzwingen, dass das Ausgabeformat stimmt.
• Klein anfangen: Bau dir erst ein, zwei Subagenten, die echte Routine abnehmen. Lieber wenige, die du wirklich nutzt, als ein Dutzend Karteileichen.

Die häufigsten Fehler – und wie du sie vermeidest

Die meisten Probleme mit Subagenten sind erstaunlich vorhersehbar. Diese acht sehe ich immer wieder:

• Subagenten implementieren lassen: Wird langsam und token-hungrig. Beschränk sie auf Informationssammlung.
• Zu viele Tools: Gib das Minimum, nicht das Maximum.
• Zu viele parallel: Drei bis fünf. Punkt.
• Vage description: Dann scheitert das automatische Delegieren, und du wunderst dich, warum nie jemand kommt.
• Geteilter State: Zwei Helfer, eine Datei, Race Condition. Definier klare Datei-Ownership.
• Zu langer System-Prompt: Wenn du dort eine ganze Prozedur reinschreibst, gehört die eigentlich in einen Skill.
• Fehlendes Ausgabeformat: Ohne festes Format bekommst du fünf unterschiedliche Zusammenfassungen und darfst sie selbst sortieren.
• Kein SubagentStop-Gate: Dann landet auch mieser Output ungefiltert im Lead-Kontext.

Was 2026 neu dazugekommen ist

Das Thema bewegt sich schnell, deshalb hier die Neuerungen, die du wirklich kennen solltest.

Agent Teams. Die große Erweiterung. Der Unterschied zu Subagenten: Teammates sind vollständig separate Claude-Code-Sitzungen, die direkt miteinander kommunizieren, statt brav an den Lead zu berichten. Sie können sich gegenseitig widersprechen, Aufgaben aus einer geteilten Liste ziehen und du kannst jeden einzeln ansprechen. Aktiviert wird das Ganze über die Umgebungsvariable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Der Preis: ungefähr das Siebenfache an Kosten. Nimm sie, wenn deine Helfer sich abstimmen müssen. Für „schnell mal was nachschauen und zurückmelden“ bleiben Subagenten das bessere Werkzeug. Am 15. Juni 2026 sind übrigens die Befehle TeamCreate und TeamDelete verschwunden – jede Sitzung ist jetzt implizit ein Team, sobald du Teammates über den name-Parameter startest.

Dynamic Workflows und Performance Outcomes. Hier plant der Lead nicht mehr eine Handvoll, sondern Dutzende bis Hunderte Subagenten. Jedes Ergebnis wird anschließend in einem separaten Kontext gegen eine Rubrik bewertet und bei Misserfolg zurückgeschickt. Klingt aufwendig, bringt aber laut Anthropic bis zu zehn Prozentpunkte bessere Ergebnisse. Für Jobs, die in ein einziges Gespräch nicht mehr reinpassen, ist das der Weg – die SDK-Doku zeigt, wie du so etwas aus einem Skript heraus orchestrierst.

Verschachtelung bis fünf Ebenen. Seit Version 2.1.172 können dateibasierte Subagenten selbst wieder Subagenten starten – bis zu fünf Ebenen tief. Für das SDK gilt das (noch) nicht. Und ehrlich: Wenn du Ebene vier brauchst, stimmt meistens was mit dem Zuschnitt nicht.

Multi-Agent Code Review. Seit dem 9. März 2026 gibt es für Team- und Enterprise-Kunden ein Review-Feature, bei dem die Anzahl der eingesetzten Agenten mit der Komplexität des Pull Requests skaliert. Kostenpunkt: grob 15 bis 25 US-Dollar pro Review. Ob sich das rechnet, hängt daran, wie teuer bei dir ein übersehener Bug in Produktion ist.

Der Entscheidungsbaum: Subagent, Hook, Skill oder einfach machen?

Wenn du dich mal wieder fragst, welches Werkzeug du greifen sollst, geh diese vier Fragen der Reihe nach durch:

• Brauchst du einen separaten Kontext? Also: Soll die Wühlarbeit woanders passieren und nur das Ergebnis zurückkommen? → Subagent.
• Ist es eine feste Regel, die immer gilt? Etwa: „Vor jedem Commit läuft der Linter.“ → Hook.
• Ist es eine wiederverwendbare Prozedur? Also ein Wie-macht-man-das, das Claude anwenden soll. → Skill.
• Nichts davon? → Mach es einfach direkt im Haupt-Agenten. Nicht jede Aufgabe braucht Infrastruktur.

Die letzte Zeile ist ernst gemeint. Der häufigste Fehler ist nicht der falsche Subagent, sondern ein Subagent, wo gar keiner nötig war.

Fazit

Claude Code Subagenten sind wie ein kleines Team aus Spezialisten, das dir Routinearbeit abnimmt – jeder mit eigener Rolle, eigenem Kontextfenster und klarem Auftrag. Du parallelisierst Aufgaben, hältst deinen Hauptchat sauber und bekommst durch die Isolation sogar bessere Reviews, weil dein Helfer eure gemeinsame Betriebsblindheit gar nicht erst kennt.

Merk dir vor allem zwei Dinge: Die description ist eine Routing-Regel, kein Jobtitel. Und Subagenten sind Informationssammler – erkunden lassen, planen, dann selbst umsetzen. Wenn du das beherzigst, funktioniert der Rest fast von allein.

Der Einstieg ist erstaunlich niederschwellig: Fang mit einem einzigen Subagenten an, der dir wirklich Arbeit spart – der code-reviewer ist ein guter erster Kandidat, weil er nur lesen darf und sofort Nutzen bringt. Erweitere von dort. Du wirst schnell merken, wie viel entspannter sich Entwicklung anfühlt, wenn du delegieren kannst.

Bereit für den nächsten Schritt? Der kostenlose Werkzeugkasten gibt dir sechs Sachen an die Hand, die du sofort kopieren kannst. Alles Weitere — Kurse, Vorlagen, Austausch — steckt im KI Business Dojo.

FAQ zu Claude Code Subagenten