Subagenten in Claude Code: parallel arbeiten, ohne den Kontext zu verschmutzen

Es kommt der Punkt, an dem Claude Code in einem einzigen Gespräch zu knapp wird. Du bittest ihn, ein halbes Dutzend Dateien zu durchsehen, um etwas zu finden, und die Sitzung füllt sich mit Code-Dumps, die du nicht mehr brauchst. Oder du willst, dass er drei Dinge gleichzeitig untersucht, und am Ende machst du sie doch eins nach dem anderen und wartest. Das Werkzeug, um diese Decke zu durchbrechen, heißt Subagent, und die meisten nutzen es nicht, weil sie nicht verstehen, wann er hilft und wann er stört.

Genau dafür ist dieser Leitfaden da: verstehen, was ein Subagent wirklich ist, wie man Arbeit parallelisiert, wie man den Auftrag so schreibt, dass er mit etwas Brauchbarem zurückkommt, und —genauso wichtig— wann man ihn NICHT anfassen sollte.

Was ein Subagent ist (und warum es nicht „ein weiterer Tab" ist)

Die Versuchung ist, sich einen Subagenten als zweites Chatfenster vorzustellen. Das ist er nicht. Der entscheidende Unterschied liegt im Kontext: Der Subagent startet sauber, sieht dein Gespräch nicht, macht seine Arbeit und gibt dir ein Destillat zurück. Er bringt dir nicht die 40 Dateien, die er gelesen hat; er bringt dir den Satz, der zusammenfasst, was er gefunden hat.

Das ändert das mentale Modell. In einer normalen Sitzung bleibt alles, was Claude liest, im Speicher und konkurriert um seine Aufmerksamkeit. Je mehr Rauschen du anhäufst, desto schlechter denkt er über das nach, was zählt. Der Subagent ist die Art und Weise, die Drecksarbeit außerhalb zu erledigen und nur die Antwort zu behalten.

Es gibt verschiedene Typen je nach Rechten: die Nur-Lese-Agenten, gedacht, um zu recherchieren und zu suchen, ohne etwas anzufassen, und die mit vollen Rechten, um Änderungen auszuführen. Wähle den restriktivsten, der genügt: um zu finden, wo eine Funktion definiert ist, einen mit Lesezugriff; damit er ein langes Refactoring isoliert, einen mit Rechten.

Wofür sie taugen: die drei Anwendungen, die sich lohnen

Nicht alles wird delegiert. Das sind die drei Szenarien, in denen ein Subagent klar gewinnt:

1. Recherchieren, ohne den Kontext zu verschmutzen. „Finde, in welchen Dateien dieses Muster verwendet wird, und sag mir, welche man anfassen muss." Der Subagent liest 30 Dateien und gibt dir eine Liste von 5 zurück. Dein Gespräch bekommt vom Durchforsten nichts mit, nur das Ergebnis.
2. Unabhängige Arbeit parallelisieren. Drei Fragen, die nicht voneinander abhängen, werden gleichzeitig gestartet und kommen gemeinsam zurück. Das ist es, was wirklich vervielfacht: Nicht, dass Claude schneller arbeitet, sondern dass er an drei Fronten gleichzeitig arbeitet.
3. Eine lange, autonome Aufgabe isolieren. Eine Migration, ein Durchlauf durch die Tests, eine massive Übersetzung. Etwas mit klarem Ziel, das unterwegs keine Aufsicht braucht und ein abgeschlossenes Ergebnis liefert.

Der gemeinsame Faden der drei: Aufgaben mit scharfem Ziel und klarem Ende. Wenn du nicht beschreiben kannst, wann der Subagent „fertig" ist, ist er wahrscheinlich kein Kandidat zum Delegieren.

Wie man sie startet: seriell und parallel

Um einen Subagenten zu starten, beschreibst du dem Hauptagenten die Aufgabe und bittest ihn, sie zu delegieren. Das Stück, das fast niemand nutzt, ist die Parallelität: Wenn du mehrere unabhängige Aufgaben in ein und derselben Nachricht anforderst, verteilt Claude sie auf Subagenten, die gleichzeitig laufen, und wartet, bis alle fertig sind, bevor er synthetisiert.

Ich brauche drei unabhängige Recherchen, starte sie PARALLEL (je ein Subagent) und fass danach alles zusammen:

1. Wo und wie das Newsletter-Formular in diesem Repo validiert wird (Dateien + Funktion).
2. Welcher E-Mail-Anbieter aktuell verdrahtet ist und wo der API-Key konfiguriert wird.
3. Ob es Tests gibt, die die Anmeldung eines Abonnenten abdecken, und welche.

Jeder Subagent gibt nur zurück: absolute Dateipfade + 2-3 Zeilen Schlussfolgerung. Kein Abladen von ganzem Code.

Achte auf zwei Details im Auftrag. Erstens „PARALLEL": Du machst klar, dass die drei unabhängig sind und gemeinsam laufen können. Zweitens das Ausgabeformat („Pfade + 2-3 Zeilen, kein Code-Dump"): Ohne das gibt dir jeder Subagent eine Textwand zurück und du verlierst den Vorteil des sauberen Kontexts.

Die Kehrseite: Wenn eine Aufgabe vom Ergebnis einer anderen abhängt (B braucht das, was A produziert hat), ist keine Parallelität möglich. Das läuft in einer Kette, im selben Gespräch oder mit sequenziellen Subagenten, nicht gleichzeitig.

Gute Praktiken: der Auftrag ist alles

Ein Subagent ist nur so gut wie sein Brief. Da er dein Gespräch nicht sieht, weiß er alles nicht, was du ihm nicht sagst. Drei Regeln:

• Ziel, Umfang und Ausgabeformat, explizit. Was du willst, wie weit er gehen darf und wie er es dir zurückgibt. „Finde X" ist vage; „finde X in src/, ignoriere die Tests, gib mir absolute Pfade und eine Zeile pro Fund" ist umsetzbar.
• Verlange das Destillat, nicht den Prozess. Der Wert des Subagenten ist, dass er filtert. Wenn du ihn alles zurückgeben lässt, was er gelesen hat, hast du einen schmutzigen Kontext gegen einen anderen getauscht. Fordere eine Schlussfolgerung, keine Mitschrift.
• Eine Aufgabe, ein Subagent. Dasselbe Prinzip wie bei einer gesunden Sitzung: ein Ziel pro Agent. Wenn du drei unzusammenhängende Themen in einen einzigen Auftrag packst, macht der Subagent sie halb.

Und eine goldene Praxis für die Recherche: verdopple die Arbeit nicht. Wenn du eine Suche an einen Subagenten delegiert hast, mach sie nicht auch selbst „für alle Fälle", während du wartest. Warte auf das Ergebnis. Der klassische Fehler ist, den Subagenten zu starten und dann, ungeduldig, dieselben Dateien zu lesen: Du ziehst zweimal am selben Faden.

Wann man KEINE Subagenten einsetzen sollte

Dieser Abschnitt zählt genauso viel wie die vorigen, denn der Missbrauch von Subagenten ist genauso verbreitet wie ihr Nichtgebrauch. Setze sie nicht ein, wenn:

• Die Aufgabe winzig ist. Wenn du sie schneller erledigst, als du sie erklärst, ist das Erklären Zeitverschwendung. Delegieren hat feste Kosten an Anlauf und Kontext; unterhalb einer gewissen Größe lohnt es sich nicht.
• Es Abhängigkeiten in einer Kette gibt. Wenn Schritt B die Ausgabe von A braucht, gibt es nichts zu parallelisieren. Es zu erzwingen fügt nur Reibung hinzu.
• Es Hin und Her mit dir erfordert. Der Subagent arbeitet in einem Zug und gibt eine einzige Antwort zurück. Wenn die Aufgabe verlangt, dass du unterwegs entscheidest, halte sie im Hauptgespräch, wo du eingreifen kannst.
• Du die Datei und die genaue Angabe schon kennst. Um EINEN Wert in EINER bereits lokalisierten Datei anzuschauen, ist das Öffnen sofort erledigt. Einen Subagenten losschicken, um das zu suchen, wovon du schon weißt, wo es ist, ist Bürokratie.

Die Regel in Kurzform: delegiere, wenn die Arbeit groß, unabhängig und von klarem Ziel ist; mach es selbst, wenn sie klein, abhängig oder ergebnisoffen explorativ ist.

Das mentale Modell, das alles verändert

Hör auf, dir Claude Code als „einen Assistenten" vorzustellen, und fang an, ihn als „einen Assistenten, der andere einstellen kann" zu sehen. Du führst; die Subagenten arbeiten parallele Fronten ab und bringen dir Berichte. Deine Arbeit ist nicht mehr das Tun, sondern das Verteilen und Synthetisieren.

Wenn du das verinnerlichst, ändert sich die Frage bei jeder Aufgabe. Sie lautet nicht mehr „wie mache ich das?", sondern „mache ich das selbst oder delegiere ich es, und wenn ich delegiere, was muss er wissen, um mit etwas Brauchbarem zurückzukommen?". Diese zweite Frage —Ziel, Umfang, Ausgabeformat— ist es, die den, der Subagenten nutzt, um wirklich zu beschleunigen, von dem trennt, der nur Rauschen hinzufügt. Fang mit einer einzigen, gut geschriebenen Delegation an: einem Rechercheauftrag mit klarem Ausgabeformat. Wenn du das saubere Destillat zurückkommen siehst statt der Textwand, willst du nicht mehr anders arbeiten.