Rede nicht mit einer einzigen Claude-Instanz. Spawn dir stattdessen ein Team.

Ich habe Claude gebeten, mir bei diesem Guide zu helfen, und so habe ich beschrieben, was ich wollte: spawn ein paar Subagenten, lass sie das aus verschiedenen Blickwinkeln recherchieren, und komm dann mit etwas Synthetisiertem zu mir zurück. Diese Anweisung ist das eigentliche Thema des Guides, nicht bloss der Aufhänger. Also, bevor es weitergeht: Das ist passiert. Eine Claude-Instanz hat dieses Briefing gelesen, entschieden, welche Blickwinkel es wert waren, abgedeckt zu werden, Teile der Recherche losgeschickt, die auf eigene Faust liefen, und einen Entwurf zurückgebracht. Ich habe nicht jeden Schritt mitverfolgt. Ich habe das Ergebnis gelesen und um Änderungen gebeten.

Wenn du Claude Code seit mehr als ein paar Wochen nutzt, hast du wahrscheinlich schon die Grenzen der Version gespürt, bei der die meisten stehen bleiben: eine durchgehende Konversation, in der du fragst, es macht etwas, du liest das Ergebnis, du fragst wieder. Das funktioniert. Es bedeutet aber auch, dass jedes Suchergebnis, jede Datei, die es öffnet, um deine Frage zu verstehen, jede Sackgasse, die es erkundet, in derselben Konversation liegen bleibt wie alles andere – und diese wird mit jeder Minute, die die Session läuft, grösser, langsamer und unübersichtlicher. Ich habe schon einmal darüber geschrieben, warum ein volles Context Window die KI leise schlechter macht, nicht nur langsamer. Subagenten sind die Lösung für genau den Fall, in dem nicht nur die Konversation, sondern die Arbeit selbst dieses Fenster füllt.

Was ein Subagent eigentlich ist

Stell dir Claude Code als Projektleitung vor, die an einem Schreibtisch sitzt. Ein Subagent ist eine zweite Kopie von Claude, die die Projektleitung auf einen Botengang schicken kann, etwa: «Lies jede Datei, die den Checkout-Flow betrifft, und sag mir, was sich geändert hat.» Er arbeitet von seinem eigenen, leeren Schreibtisch aus, mit einer eigenen Kopie der Anweisungen und ohne das Durcheinander vom Schreibtisch der Projektleitung. Er gräbt sich durch die Details. Er zeigt seine Arbeit nicht. Er kommt mit einem kurzen Bericht zurück, und sein Schreibtisch – alle Dateien, die er geöffnet hat, alle falschen Fährten, denen er gefolgt ist – wird geräumt, sobald er fertig ist.

Das ist der ganze Mechanismus. Drei Dinge unterscheiden das davon, einfach dieselbe Claude-Instanz zu bitten, drei Dinge nacheinander zu erledigen.

Isolation. Der Subagent startet ohne alles aus der Hauptkonversation, ausser dem, was ihm explizit mitgegeben wird. Er sieht nicht, was du vor fünf Minuten gesagt hast, und er muss es auch nicht. Er hat eine Aufgabe und genau den Context, den er dafür braucht.

Parallelität. Jeder Subagent ist ein eigener, separater Durchlauf, deshalb können mehrere gleichzeitig laufen. Die Projektleitung wartet nicht, bis Subagent eins mit Datei A fertig ist, bevor sie Subagent zwei nach Datei B fragen kann.

Kompression. Ein Subagent liest vielleicht zehn Dateien und führt zwanzig Suchen aus, um eine einzige Frage zu beantworten. Was in den Hauptstrang zurückkommt, ist ein Abschnitt – die Antwort, nicht die Suchhistorie. Das eigene Context Window der Projektleitung bleibt frei für den Teil der Arbeit, der tatsächlich Kontinuität braucht: zu entscheiden, was mit der Antwort passiert.

In Claude Code ist das eingebaut. Bitte es in normaler Sprache darum, etwa «recherchiere das aus ein paar verschiedenen Blickwinkeln parallel» oder «prüfe jede dieser fünf Dateien parallel auf denselben Bug», und es kann von sich aus entscheiden, für die wirklich unabhängigen Teile Subagenten zu starten. Ein paar Spezialisten sind auch von Haus aus dabei, einer fürs Durchsuchen einer Codebase gebaut, einer fürs Entwerfen eines Plans, bevor überhaupt Code angefasst wird, und du kannst dir eigene mit einem kurzen, im Projekt gespeicherten Briefing schreiben – für alles, was du mehr als einmal auf dieselbe Art delegierst.

Das ist keine Claude-Code-Exklusivität, und es lohnt sich, genau zu sein, wo die eigentliche Trennlinie verläuft. Es geht nicht um Anthropic gegen den Rest, sondern um agentisches Harness gegen reaktiven Chat. Der normale Chat auf Claude.ai macht das nicht: Ein einzelnes Hin-und-her-Gespräch hat keine laufende Aufgabe, von der aus delegiert werden könnte, und dasselbe gilt für die normalen Apps von ChatGPT und Gemini. OpenAIs Codex bringt ein eigenes Subagenten-Setup mit, und Googles Gemini CLI (das in Antigravity aufgeht) hat im April 2026 Unterstützung für Subagenten bekommen – beide laufen nach demselben Muster: Projektleitung delegiert an Spezialisten, wie hier beschrieben. Claude Cowork, Anthropics Agent für nicht codebezogene Büroarbeit, läuft auf derselben Engine wie Claude Code, die Architektur ist also sehr wahrscheinlich auch dort vorhanden – ich habe allerdings nicht bestätigt, dass das Feature im Interface von Cowork genauso explizit zugänglich gemacht wird wie in Claude Code.

Kannst du dir einen Subagenten bauen, der wie dein CTO denkt?

Ja, und es lohnt sich, genau zu verstehen, was du dir damit einkaufst.

Jeder Subagent läuft mit einem System-Prompt: feste Anweisungen, die bei jedem Aufruf gleich bleiben, egal was ihn ausgelöst hat. Die Spezialisten, die bei Claude Code von Haus aus dabei sind, funktionieren so. Du kannst dir eigene genauso bauen: ein kurzes, gespeichertes Briefing, das sinngemäss sagt: «Wenn du aufgerufen wirst, wäge Dinge so ab, wie es ein CTO tun würde. Bevorzuge Wartbarkeit und Einstellungskosten gegenüber der eleganten Lösung, markiere alles, was einen Single Point of Failure schafft, frag, was beim Zehnfachen der aktuellen Grösse kaputtgeht, bevor du zustimmst, dass etwas live gehen soll.» Speichere das einmal, und danach kannst du einen CTO-artigen Subagenten mit Namen aufrufen. Meine Notizen zum parallelen Führen mehrerer Sessions beschreiben, wie man dasselbe mitten in einer Konversation macht – die KI bitten, spontan eine Verhaltensökonomin oder einen First-Principles-Denker zu spielen. Der Unterschied hier: Die Persona ist gespeichert, nicht jedes Mal neu eingetippt.

Ein gespeicherter Subagent kann auch über den Persona-Prompt hinausgehen. Du kannst ihn auf ein bestimmtes Modell festlegen (den CTO-Subagenten auf dein stärkstes Reasoning-Modell, weil genau bei Ermessensentscheidungen ein günstigeres Modell oberflächlich wird) und seine Tools einschränken (ein Reviewer-Subagent, der Code lesen, aber nicht bearbeiten kann, sodass er strukturell nicht selbst «reparieren» kann, was er eigentlich kritisieren soll, statt ihm das nur zu sagen). Für die Modellwahl brauchst du auch keinen gespeicherten Subagenten: Wenn du einen im Moment spawnst, kannst du das Modell im selben Atemzug nennen, etwa «lass die Konkurrenzrecherche als günstigeren, schnelleren Subagenten laufen, aber die finale Synthese läuft auf deinem stärksten Modell». Dieselbe Logik aus Teuer denken, günstig ausführen gilt Subagent für Subagent: Einer, der einfache Lookups macht, braucht nicht dein teuerstes Modell, einer, der eine Ermessensentscheidung trifft, schon.

Wo sich das gegenüber einem spontanen «schau dir das wie ein CTO an» an den Orchestrator lohnt: bei Wiederverwendung, Einschränkung und angesammelten Spezifika. Brauchst du diese Perspektive nur einmal, ist der eingetippte Satz billiger als eine gepflegte Datei, und das Modell weiss ohnehin grob, worauf ein CTO achtet. Die Persona zu benennen, schaltet nicht von selbst verborgenes Wissen frei. Ein gespeicherter Subagent zahlt sich aus, sobald du dieselbe Perspektive wiederholt brauchst und sie jedes Mal gleich angewendet haben willst, sobald du die Tool- oder Modelleinschränkung wirklich brauchst, oder sobald die Persona anfängt, Context zu speichern, der spezifisch für dich ist statt generisch. Ein blosser «CTO-Subagent» gibt dir dasselbe generische CTO-Urteil, das dir auch eine Ad-hoc-Anweisung schon liefert, weil das Modell darüber hinaus nichts hat, worauf es zugreifen kann. Ein CTO-Subagent, dessen feste Anweisungen zusätzlich sagen «markiere immer alles, was unser Compliance-Risiko vergrössert, weil wir in einer regulierten Branche tätig sind», gibt dir etwas, das das Modell vorher nicht wusste. Das allgemeine Wissen liefert das Modell so oder so. Was du in einen festen Subagenten speicherst, ist der Teil, der wirklich dir gehört: die Spezifika, die aus einem generischen Experten deinen Experten machen.

Warum Leute das wirklich machen

Der klarste öffentliche Beleg dafür, warum sich dieses Muster lohnt, ist Anthropics eigener Bericht darüber, wie die Research-Funktion von Claude gebaut wurde – sie läuft genau so. Ein Lead-Agent plant die Frage und zerlegt sie in Teile, und eine Gruppe von Subagenten untersucht diese Teile gleichzeitig, jeder mit eigenem Suchbudget, bevor die Lead-Instanz die Erkenntnisse zu einer Antwort zusammenfügt. Intern schlug die Multi-Agent-Version einen einzelnen, sehr fähigen Agenten, der allein arbeitete, in Anthropics eigener Recherche-Evaluation um 90,2 %. Simon Willison, der einen der meistgelesenen Engineering-Blogs zu KI-Tools schreibt und offen skeptisch gewesen war, ob es sich lohnt, mehrere Agenten parallel laufen zu lassen, nannte den Beitrag das, was «mich von dieser Skepsis geheilt hat». Seine Frage vorher war gewesen, wieso man sich die Mühe macht, mehrere Prompts parallel laufen zu lassen, wenn ein gut geschriebener Prompt gegen ein Spitzenmodell die Aufgabe normalerweise ohnehin erledigt. Anthropics eigene Zahlen waren die Antwort: Das tut er nicht, jedenfalls nicht bei der Art Frage, die sich wirklich in unabhängige Teilfragen aufspalten lässt.

Gratis ist das nicht. Anthropic berichtet auch, dass die Multi-Agent-Version ungefähr das 15-Fache an Token einer einzelnen Chat-Antwort verbraucht, und dass allein dieser Tokenverbrauch den grössten Teil des Leistungsunterschieds erklärt. Die Lead-Instanz deckt mehr Boden ab, weil die Arbeit aufgeteilt und gleichzeitig statt nacheinander erledigt wurde. Das ist keine klügere Lead-Instanz, nur ein beschäftigteres Team. Das ist der Deal in einem Satz: Du kaufst dir Abdeckung und Geschwindigkeit mit Token.

Dasselbe Muster taucht in viel kleinerem Massstab in ganz normalen Coding-Workflows auf. Ein Entwickler, der auf seinem Blog hamy.xyz schreibt, hat beschrieben, wie er neun Subagenten aufgesetzt hat, um jeden Pull Request zu reviewen – einen für Security, einen für Performance, einen für Testabdeckung und so weiter – statt eines einzigen Durchgangs, der versucht, all diese Anliegen gleichzeitig im Kopf zu behalten. Sein eigener Vergleich zeigte einen spürbar höheren Anteil an wirklich umsetzbaren Vorschlägen als bei einem einzelnen Reviewer-Durchgang, nach der Logik, dass ein Agent, der nur nach SQL-Injection sucht, weniger übersieht als einer, der gleichzeitig an SQL-Injection, Performance und Namenskonventionen denken will. Dieselbe Idee, kleiner gedacht: Ein Subagent, der nur deine Datenbankschicht kennt, schreibt besseren Datenbankcode als einer, der dein ganzes Projekt gleichzeitig jongliert – aus demselben Grund, aus dem ein Spezialist Dinge findet, die eine Generalistin überfliegt.

Vieles von dem, was ich auf dieser Site mache, hat von Natur aus genau diese Form, ohne dass ich es so geplant hätte. Wenn ich einen Stapel neuer Tools in die Content-Inbox lege und Claude bitte, sie zu verarbeiten, ist das keine einzelne Aufgabe. Es ist eine Handvoll unabhängiger Aufgaben: Preise und Positionierung für Tool A recherchieren, prüfen, ob Tool B schon auf der Site existiert, ein Logo für Tool C finden. Keine davon hängt von einer anderen ab. Arbeitet Claude sechs Tools nacheinander in derselben Konversation ab, sind das sechs Runden Preisseiten und Suchergebnisse, die sich aufeinanderstapeln, und bei Tool sechs ist der Context voller Details zu den Tools eins bis fünf, die nicht mehr wichtig sind. Schick stattdessen sechs Subagenten los, einen pro Tool. Sie laufen gleichzeitig, jeder startet sauber und vergisst die Preisseite des irrelevanten Tools in dem Moment, in dem er fertig ist, und was bei mir ankommt, sind sechs kurze Zusammenfassungen statt der Rohrecherche von sechs Tools, durch die ich mich sonst selbst hätte wühlen müssen.

Wo es mehr kostet, als es bringt

Die 15-fache Tokenzahl ist die Schlagzeile, aber der subtilere Preis ist die Koordination. Ein Subagent kann dir mitten in der Aufgabe keine Rückfrage stellen, so wie eine normale Konversation das kann. Er arbeitet mit dem Briefing, das er bekommen hat, und meldet sich einmal zurück – eine vage Anweisung erzeugt also ein vages Ergebnis, ohne Chance zur Korrektur, bevor es schon fertig ist. Je mehr Subagenten gleichzeitig laufen, desto mehr Wege gibt es, wie das schiefgehen kann, und desto mehr muss die Projektleitung tatsächlich lesen und abgleichen, was zurückkommt, statt einfach anzunehmen, dass alles zusammenpasst.

Genau in diesem Abgleich steckt auch der eigentliche Wert, und er lässt sich leicht überspringen. Anthropics Bericht macht denselben Punkt über die eigene Lead-Instanz: Sie ist die einzige Stelle, die alle Antworten zusammen sieht, und kann deshalb eine Verbindung erkennen, die keiner der einzelnen Subagenten sehen konnte – einen Befund aus einem Blickwinkel, der erst im Licht eines Befunds aus einem anderen Blickwinkel wichtig wird. Spawnst du fünf Subagenten und klebst ihre fünf Berichte hintereinander, ohne dass irgendjemand sie tatsächlich zusammenführt, hast du die Token-Kosten bezahlt und genau den Teil übersprungen, der sie wert gemacht hätte.

Es gibt eine Art von Aufgabe, bei der ich das auf genau dieser Site bewusst nicht mache: Schreiben. Ich lasse Claude keinen Guide entwerfen, indem ich ihn auf drei Subagenten aufteile, die parallel verschiedene Abschnitte schreiben. Stimme muss aus einem durchgehenden Strang kommen, der das ganze Stück von Anfang bis Ende sieht, wo ein Satz zwei Absätze vorher eine Formulierung ausschliesst, die du gerade verwenden willst, wo der Rhythmus des letzten Abschnitts den nächsten vorbereitet. Drei Subagenten, die die Arbeit der anderen nicht sehen können, greifen jeder zu ihrem eigenen Rhythmus, und das zusammengeflickte Ergebnis liest sich wie von drei verschiedenen Autoren – weil es das auch ist. Die Recherche für das Stück ist eine andere Sache. Genau darin sind Subagenten gut: unabhängiges, paralleles Graben. Das eigentliche Schreiben bleibt in einem Strang.

Die generelle Regel hinter beiden Beispielen: Greif zu Subagenten, wenn sich die Arbeit selbst sauber in Teile aufteilen lässt, die während der Arbeit nicht miteinander reden müssen – wie Recherche, parallele Dateiprüfungen oder unabhängige Reviews. Lass es sein bei allem, was kurz genug ist, dass der Koordinationsaufwand die Arbeit selbst übersteigt, und lass es auch sein bei allem, wo der Wert in einem einzigen, durchgehenden Strang von Urteilsvermögen liegt, den die Teile verlieren würden, wenn sie getrennt wären.

Selbst ausprobieren

Du musst nichts einrichten, um damit anzufangen, und du brauchst auch keine Entwickleraufgabe, um es auszuprobieren. Nimm eine echte Business-Entscheidung, vor der du gerade stehst, und frag danach so, wie du ein kleines Team bitten würdest, sie vor deiner Entscheidung zu prüfen:

“Ich überlege, den Preis unseres Pro-Plans von 29 auf 39 Dollar im Monat zu erhöhen. Spawn drei Subagenten, die das parallel untersuchen: einer schaut sich nur an, was das mit Kundenabwanderung und Kundenbindung macht, einer vergleicht nur, was die Konkurrenz für etwas Vergleichbares verlangt, und einer rechnet nur die Umsatzmathematik durch, unter der Annahme, dass wir bei dem neuen Preis einen spürbaren Anteil an Kunden verlieren. Lass jeden mit einem kurzen Fazit zurückkommen, und gib mir danach deine eigene Synthese, ob sich das lohnt.”

Drei unabhängige Blickwinkel, drei Subagenten, eine Synthese, die du wirklich liest. Das ist das ganze Muster, bei einer Frage, die nichts mit Code zu tun hat. Vergleiche, was zurückkommt, mit dem, was du bekommen hättest, wenn du dasselbe in einem einzigen langen Strang gefragt hättest, wo die Abwanderungsanalyse, die Konkurrenzrecherche und die Umsatzmathematik zu einem einzigen Absatz verschwimmen, statt für sich zu stehen.

Merkst du, dass du mehr als ein- oder zweimal dieselbe Art von delegierter Aufgabe verlangst – dieselbe Review-Checkliste, dieselbe Recherche-Form –, ist das der Punkt, ab dem es sich lohnt, sie als benannten Subagenten zu speichern, den du aufrufen kannst, statt das Briefing jedes Mal neu zu erklären.

---

Das ist ein anderer Wandel als der in Der Rausch des Orchestrators, bei dem es darum geht, dass du persönlich mehrere separate Claude-Code-Sessions parallel über Fenster und Desktops hinweg laufen lässt. Subagenten sind eine einzige Session, die diese Delegation intern übernimmt, ohne dass du selbst zwischen Bildschirmen wechseln musst. Für die Mechanik, wie du Claude Code im Alltag konkret nutzt, siehe Claude Code: Wenn KI aufhört zu reden und anfängt zu handeln. Und falls dich vor allem das volllaufende Context Window hierhergeführt hat, ist Was das Context Window ist – und was du dagegen tun kannst das Stück, auf dem dieses hier aufbaut.