Claude · Parallele Subagents: Arbeit auf frische Kontexte verteilen

Eine einzelne Claude-Code-Konversation kann nur eine begrenzte Menge gleichzeitig durchdenken. Wenn eine Aufgabe also wirklich breit ist, schieben Sie nicht alles in einen Kontext, sondern verteilen die Arbeit auf Subagents: separate Claude-Instanzen, die jeweils ihr eigenes frisches Context WindowContext WindowDas Context Window ist die maximale Textmenge (gemessen in Tokens), die ein Sprachmodell auf einmal verarbeiten kann, einschließlich Input-Prompt und generiertem Output.Vollständige Definition ansehen → bekommen, unabhängig arbeiten und nur ihre Schlussfolgerungen zurückmelden.

Sie wissen bereits, dass das Context Window begrenzt ist und dass Überfüllen die Qualität verschlechtert. Subagents sind die strukturelle Antwort auf dieses Problem innerhalb von Claude Code. In dieser Lektion geht es darum, wann Sie darauf zurückgreifen, wie Sie eigene definieren und was Sie dafür aufgeben.

Was ein Subagent tatsächlich ist

Ein Subagent ist ein Kind-Task, den Claude Code startet, um einen Teil der Arbeit zu übernehmen. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → läuft mit einem sauberen Kontext, erledigt seine Aufgabe mit eigenem Tool-Zugriff und gibt eine Zusammenfassung an den Haupt-Agent zurück (den Orchestrator), der ihn gestartet hat.

Drei Eigenschaften sind relevant:

• Frischer Kontext. Jeder Subagent startet leer. Er erbt nicht die Historie Ihrer Hauptkonversation. Genau das ist der Punkt: Er konkurriert nicht um Platz mit allem anderen, was Sie bisher gemacht haben.
• Unabhängige Ausführung. Mehrere Subagents kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen gleichzeitig laufen. Claude Code schickt sie los und wartet, bis alle fertig sind.
• Rückgabe nur der Zusammenfassung. Sie bekommen nicht das komplette Transkript des Subagents in Ihren Hauptkontext zurück. Sie bekommen seine Schlussfolgerung. Das unordentliche Zwischendenken bleibt isoliert.

Die letzte Eigenschaft ist der Trick, der Fan-out skalierbar macht. Wenn ein Subagent 40 Dateien liest, um eine Frage zu beantworten, berühren diese 40 Dateien nie Ihr Hauptfenster. Nur die Antwort tut es.

Wann paralleles Fan-out besser ist als eine lange Konversation

Fan-out gewinnt, wenn die Arbeit breit und trennbar ist. Die Teile hängen nicht von den Ergebnissen der anderen ab, sie sequenziell laufen zu lassen wäre also nur langsamer, ohne Vorteil.

Gute Kandidaten:

• Breite Code-Suche. „Finde jede Stelle, an der wir die Payments-APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → aufrufen, und prüfe, ob wir den Timeout-Fall behandeln.“ Ein einzelner Agent, der seriell greppt und liest, verbrennt seinen Kontext. Teilen Sie es nach Verzeichnis oder nach Service auf.
• Audits über viele Dateien. Security Review, Dependency Review, Accessibility-Durchgang. Jedes Thema ist eine eigene Linse auf denselben Baum.
• Mehrere wirklich unabhängige Aufgaben. Die Docs aktualisieren, die Migration schreiben und das Changelog entwerfen. Kein gemeinsamer State, also kein Grund zu serialisieren.

Fan-out ist das falsche Werkzeug, wenn die Arbeit tief und sequenziell ist: ein Refactoring, bei dem Schritt drei vom Ergebnis von Schritt zwei abhängt, oder das Debuggen eines einzelnen Fehlers, bei dem jeder Befund die nächste Frage eingrenzt. Dort hält eine durchgehende Konversation den Faden. Subagents, die sich nicht sehen können, würden denselben Kontext nur neu herleiten und sich möglicherweise widersprechen.

Das mentale Modell: Breite geht an Subagents, Tiefe bleibt im Hauptthread.

Die Briefing-Steuer

Weil jeder Subagent mit nichts startet, zahlen Sie einen Preis: Sie müssen ihn vollständig briefen. Er kennt Ihre Architektur nicht, Ihre Namenskonventionen nicht und nicht, wie „fertig“ aussieht, solange Sie es ihm nicht im Dispatch sagen.

Ein vager Dispatch („review das Auth-Modul“) erzeugt eine vage Zusammenfassung. Ein Subagent hat keine Möglichkeit, Ihnen mitten in der Aufgabe eine klärende Frage zu stellen, wie es eine interaktive Session kann. Der Prompt, den Sie ihm geben, muss also in sich geschlossen sein:

• Was zu betrachten ist (Scope)
• Worauf zu achten ist (die konkrete Frage)
• In welchem Format zu berichten ist

Das ist die Disziplin, die Fan-out Ihnen abverlangt. Es ist dieselbe Disziplin, die gute Delegation von einem Menschen verlangt: je klarer das Briefing, desto nützlicher das Ergebnis.

Eigene Subagent-Typen

Sie können wiederverwendbare Subagent-Typen definieren, damit Sie nicht jedes Mal Briefings neu schreiben. In Claude Code existieren Subagents als Markdown-Dateien mit YAML-Frontmatter, entweder in .claude/agents/ für ein bestimmtes Projekt oder in Ihrer User-Config für alle Projekte.

Das Frontmatter legt Identität und Berechtigungen des Agents fest. Der Body ist sein System Prompt: die festen Anweisungen, die er bei jedem Lauf bekommt.

---
name: security-auditor
description: Reviews a directory for injection, auth, and secret-handling flaws. Use for security-focused code review.
tools: Read, Grep, Glob
---

You are a security reviewer. Given a directory path, inspect the code for:
- unsanitized inputs reaching queries, shell calls, or file paths
- missing authentication or authorization checks on sensitive routes
- secrets, tokens, or keys committed in source

Report only confirmed or strongly suspected issues. For each, give the
file, the line range, the risk, and a one-line fix. If you find nothing,
say so plainly. Do not summarize the whole codebase.

Zwei Dinge sind erwähnenswert. Die description ist das, was der Orchestrator liest, um zu entscheiden, wann er an diesen Agent delegiert, schreiben Sie sie also für den Router, nicht für sich selbst. Und tools ist absichtlich eng gehalten: Dieser Agent kann lesen und suchen, aber nicht schreiben oder Befehle ausführen. Least Privilege gilt für Subagents genauso wie für jede andere Automatisierung.

Das vollständige SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen → und der Unterschied zwischen Agents auf Projekt- und auf User-Ebene sind im Claude Code subagents guide dokumentiert.

Ein konkretes Beispiel: eine Codebase parallel auditieren

Angenommen, Sie haben einen Service übernommen mit vier großen Bereichen: api/, billing/, auth/ und workers/. Sie wollen vor einem Release schnell einen Security-Blick über alle vier. Sequenziell würde ein Agent den ganzen Baum lesen und irgendwo um workers/ herum knapp an Platz werden.

Stattdessen sagen Sie dem Orchestrator, er soll fan-out machen. In einer interaktiven Claude-Code-Session reicht dafür eine Bitte in normaler Sprache:

Use the security-auditor subagent to review each of these
directories in parallel: api/, billing/, auth/, and workers/.
Give me one consolidated table of findings sorted by severity.

Claude Code startet vier Instanzen von security-auditor, eine pro Verzeichnis. Jede bekommt einen frischen Kontext, liest nur ihren zugewiesenen Teil und gibt eine kurze Liste der Findings zurück. Der Orchestrator wartet auf alle vier und führt sie dann zu der Tabelle zusammen, die Sie angefordert haben.

Was in Ihrem Hauptkontext zurückkommt, ist kompakt: vier Zusammenfassungen und eine zusammengeführte Tabelle. Was Sie *nicht* bekommen, sind die hunderte Zeilen, die jeder Agent gelesen hat, um diese Zusammenfassungen zu erzeugen. Genau so soll es sein. Sie wollten das Urteil, nicht die Beratung.

Vergleichen Sie das mit einer langen Session, die dasselbe Review macht. Bis sie bei workers/ angekommen wäre, lägen die Details von api/ weit oben im Kontext begraben, würden um Aufmerksamkeit konkurrieren und die Präzision des Modells still verschlechtern. Fan-out umgeht das vollständig, weil kein einzelner Agent je mehr hält als seinen Teil.

Programmatischer Dispatch mit dem Agent SDK

Der interaktive Ablauf ist für einmalige Arbeiten gut. Wenn Sie Fan-out in einem Skript oder einer CI-PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → wollen, gibt Ihnen das Claude Agent SDK dieselbe Subagent-Maschinerie im Code, sodass Sie ein Multi-File-Audit über die GitHub-Integration in einen Pre-Release-Check einbauen können, der bei jedem Pull Request läuft.

Das Muster ist identisch: Agent-Typen einmal definieren, dann den Orchestrator Arbeitsteile an sie routen lassen. Das SDK übernimmt die parallele Ausführung und das Einsammeln der Zusammenfassungen, sodass Sie keine Threads selbst verwalten.

Die Trade-offs, klar benannt

Fan-out ist mächtig, aber nicht kostenlos. Behalten Sie vier Kosten im Blick.

Sie verlieren das Transkript. Die Zusammenfassung ist alles, was Sie bekommen. Wenn ein Subagent zu einer falschen Schlussfolgerung kommt, können Sie nicht leicht nachvollziehen, *wie* er dorthin gelangt ist, ohne ihn erneut laufen zu lassen. Entwerfen Sie Ihre Agent-Prompts so, dass sie Belege berichten (Datei, Zeile, Begründung), nicht nur Urteile, damit die Zusammenfassung für sich prüfbar ist.

Keine gemeinsamen Erkenntnisse. Wenn der auth/-Agent ein Muster findet, das auch dem api/-Agent helfen würde: Pech, sie können nicht miteinander reden. Wenn übergreifendes Wissen wichtig ist, machen Sie entweder einen ersten Durchgang, um gemeinsamen Kontext zu schaffen, und legen den in jedes Briefing, oder Sie halten die Arbeit in einem Thread.

Mehr Agents heißt mehr Tokens. Vier frische Kontexte, die jeweils Dateien lesen, sind insgesamt mehr Arbeit als ein Kontext, der alles einmal liest, auch wenn es in Wall-Clock-Zeit schneller fertig ist. Sie tauschen TokenTokenEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen →-Effizienz gegen Geschwindigkeit und Qualität. Für breite Aufgaben meist lohnend, für kleine verschwenderisch.

Orchestrierungs-Overhead. Aufteilen, Dispatchen und Zusammenführen hat eigene Kosten im Hauptkontext. Wenn eine Aufgabe klein genug ist, dass ein Agent sie bequem erledigt, fügt Fan-out nur Zeremonie hinzu. Reservieren Sie es für Aufgaben, die einen einzelnen Kontext wirklich überlaufen lassen.

Eine schnelle Entscheidungsregel

Bevor Sie fan-out machen, fragen Sie: Kann ich das in Teile zerlegen, die die Ergebnisse der anderen nicht sehen müssen? Wenn ja, und es sind mehr als zwei oder drei, dann fan-out. Wenn die Teile verflochten sind oder es nur ein paar sind, bleiben Sie in einer Konversation.

Wie sich das ins größere Ökosystem einfügt

Subagents sind ein Claude-Code-Konstrukt, aber dieselbe Form findet sich im gesamten Anthropic-Tooling. Das Agent SDK stellt sie für Produktions-Agents bereit. Die Messages API gibt Ihnen das rohe Primitiv, um eigene Orchestrierung zu bauen, falls Sie etwas MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßgeschneidertes brauchen. Und weil Subagents MCP-Verbindungen erben, kann jeder einzelne dieselben Tools und Datenquellen erreichen (über das Model Context Protocol), die Ihre Hauptsession nutzt, ohne dass Sie pro Agent etwas neu verkabeln.

Der rote Faden: **Claudes Tooling gibt Ihnen immer wieder Wege, Kontext bewusst zu *isolieren*, statt ihn standardmäßig anwachsen zu lassen**. Projects isolieren Wissen nach Workspace. Skills isolieren wiederverwendbare Abläufe. Subagents isolieren eine Arbeitseinheit. Jedes ist eine andere Antwort auf dieselbe Realität des begrenzten Kontexts.

Wichtigste Erkenntnisse

• Fan-out, wenn Arbeit breit und trennbar ist, nicht tief und sequenziell. Breite Suchen, Audits über viele Dateien und unabhängige Aufgaben sind der Sweet Spot. Refactorings und die Jagd nach einem einzelnen Bug gehören in einen Thread.
• Briefen Sie jeden Subagent vollständig. Frischer Kontext heißt keine gemeinsame Historie und keine Gelegenheit, Ihnen Fragen zu stellen. Scope, Frage und Report-Format gehören in den Dispatch.
• Definieren Sie wiederverwendbare Agent-Typen in `.claude/agents/`. Schreiben Sie die description für den Router und gewähren Sie nur die Tools, die jeder Agent braucht.
• Entwerfen Sie Prompts so, dass sie Belege zurückgeben, nicht nur Urteile. Sie bekommen nur die Zusammenfassung zurück, machen Sie die Zusammenfassung also für sich prüfbar.
• Kennen Sie den Tausch: Geschwindigkeit und Kontextqualität rauf, Token-Kosten und Sichtbarkeit zwischen Agents runter. Reservieren Sie Fan-out für Aufgaben, die einen einzelnen Kontext wirklich überlaufen lassen.