Subagenten: Delegieren wie ein Tech-Lead

Kennst du das? Du lässt Claude für einen Post recherchieren, und nach fünf Exa-Suchen ist dein Kontext voll mit Suchergebnissen, Zwischennotizen und verworfenen Quellen. Der eigentliche Auftrag — den Post schreiben — ertrinkt im Rauschen. Genau dieses Problem lösen Subagenten: spezialisierte Helfer, an die dein Hauptagent Teilaufgaben abgibt.

Ein guter Tech-Lead schreibt nicht jeden Commit selbst. Er delegiert, bekommt Ergebnisse zurück und behält den Überblick. Ab dieser Lektion arbeitet Claude Code für dich genauso.

Warum Subagenten? Das Kontext-Argument

Der wichtigste Grund ist nicht Geschwindigkeit — sondern Kontext-Hygiene.

Jeder Subagent bekommt ein eigenes Context Window. Was er dort liest, sucht und verwirft, landet nie in deinem Hauptgespräch. Zurück kommt nur das Endergebnis: eine Zusammenfassung, eine Liste, ein Urteil.

Konkret für unsere Content-Fabrik:

Ohne Subagent:
Hauptkontext = Auftrag + 5 Suchen + 40 Suchergebnisse
             + Zwischennotizen + fertiger Text
→ Kontext verwässert, Claude vergisst frühe Anweisungen

Mit Subagent:
Hauptkontext = Auftrag + kompakte Recherche-Zusammenfassung + fertiger Text
→ Kontext bleibt scharf, die Qualität bleibt konstant

Der zweite Vorteil: Parallelisierung. Mehrere Subagenten arbeiten gleichzeitig — fünf Recherche-Suchen parallel statt nacheinander. In der 5-Phasen-Pipeline hast du das Muster schon gesehen: Phase 2 (Research) und Phase 4 (Deaify) sind wie gemacht dafür.

Der dritte Vorteil: Spezialisierung. Ein Subagent hat eine eigene Rollenbeschreibung und eigene Werkzeug-Rechte. Dein Recherche-Agent darf suchen, aber keine Dateien ändern. Dein Kritiker-Agent liest Texte, führt aber keine Shell-Befehle aus. Weniger Rechte, weniger Überraschungen.

So baust du einen Subagenten

Ein Subagent ist eine Markdown-Datei in .claude/agents/ — pro Agent eine Datei:

dein-projekt/
├── CLAUDE.md
├── .claude/
│   ├── skills/
│   ├── commands/
│   └── agents/
│       ├── recherche.md
│       └── kritiker.md

Die Datei besteht aus YAML-Frontmatter plus Anweisungstext. Drei Felder sind wichtig:

name — so heißt der Agent
description — wann Claude an ihn delegieren soll (der wichtigste Teil!)
tools — welche Werkzeuge der Agent nutzen darf

Beispiel: Der Recherche-Agent für deinen Content-Workflow

Baust du den Telegram-Workflow aus diesem Kurs nach, ist das dein erster sinnvoller Subagent — er übernimmt Phase 2 der Pipeline:

---
name: recherche
description: Recherchiert ein Content-Thema mit Websuche. Nutzen, wenn
  fuer einen Post oder Artikel aktuelle Quellen, Daten oder Gegenthesen
  gesammelt werden sollen.
tools: WebSearch, WebFetch, Read
---

Du bist der Recherche-Agent der Content-Fabrik.

## Auftrag
Sammle zu einem gegebenen Thema aktuelle, belastbare Informationen.

## Prozess
1. Suche nach dem Kernthema (aktuelle Diskussionen)
2. Suche nach der Gegenthese (was sagen Kritiker?)
3. Suche nach konkreten Zahlen, Studien, Statistiken
4. Notiere zu jeder Quelle: URL, Datum, Kernaussage in 1-2 Saetzen

## Ausgabe
Ein kompaktes Recherche-Dokument (max. 400 Woerter):
- 5-8 Quellen mit Kurzzusammenfassung
- 3 konkrete Datenpunkte oder Zitate
- 1 ueberraschende Erkenntnis

## Regeln
- Keine Quellen erfinden. Lieber "nichts gefunden" als geraten.
- Nur die Ausgabe zurueckgeben, keine rohen Suchergebnisse.

Zwei Details verdienen Aufmerksamkeit:

Die description entscheidet über die Delegation. Claude liest sie und entscheidet selbstständig, ob eine Aufgabe zum Agenten passt — genau wie bei Skills. Schwammige description = der Agent wird nie oder ständig aufgerufen.
Die Ausgabe-Regeln schützen deinen Hauptkontext. "Max. 400 Wörter, keine rohen Suchergebnisse" sorgt dafür, dass nur Substanz zurückfließt. Ohne diese Regel kippt der Subagent seine komplette Recherche in dein Hauptgespräch — und der Kontext-Vorteil ist dahin.

Delegation in der Praxis

Sobald die Datei existiert, delegiert Claude von selbst, wenn eine Aufgabe zur description passt. Du kannst auch explizit anweisen:

Nutze den recherche-Agenten fuer das Thema "Kontext-Rot bei langen
Sessions" und schreib danach den Telegram-Post nach STYLE.md.

Der Hauptagent startet den Subagenten, wartet auf dessen Zusammenfassung und schreibt dann — mit sauberem Kontext — den Post.

Wann Subagent, wann selbst machen?

Nicht jede Aufgabe verdient einen Subagenten. Delegation kostet Startzeit und Tokens, und der Subagent kennt dein bisheriges Gespräch nicht.

Subagent lohnt sich:

Die Teilaufgabe produziert viel Wegwerf-Kontext (Recherche, Log-Analyse, Codebasis durchsuchen)
Mehrere unabhängige Teilaufgaben können parallel laufen (4 Kritiker, 5 Suchen)
Die Aufgabe braucht eine klar abgegrenzte Rolle mit eigenen Regeln und weniger Rechten
Das Ergebnis lässt sich in wenigen Absätzen zurückgeben

Selbst machen:

Kleine, schnelle Aufgaben (eine Datei lesen, einen Satz umformulieren) — Delegation wäre teurer als die Aufgabe selbst
Aufgaben, die das gesamte Gesprächswissen brauchen — der Subagent startet ohne eure Vorgeschichte
Enge Feedback-Schleifen mit dir — du willst bei jedem Schritt eingreifen, nicht auf einen Endbericht warten

Faustregel: Delegiere wie ein guter Tech-Lead. Abgeschlossene Pakete mit klarem Ergebnis gehen raus, Kern-Entscheidungen und alles Kurzlebige bleiben bei dir.

Typische Stolperfallen

Drei Fehler tauchen bei den ersten eigenen Subagenten immer wieder auf:

Fehler 1: Die description beschreibt den Agenten statt den Einsatzfall. "Ein Agent für Recherche" sagt Claude nicht, wann er delegieren soll. Besser: "Nutzen, wenn für einen Post aktuelle Quellen gesammelt werden sollen." Schreibe die description wie eine Wenn-dann-Regel, nicht wie eine Stellenanzeige.

Fehler 2: Der Subagent bekommt alle Werkzeuge. Ohne tools-Eintrag erbt der Agent den vollen Werkzeugkasten — inklusive Schreiben und Shell. Ein Kritiker, der aus Versehen "hilfsbereit" deine Datei umschreibt, ist kein Kritiker mehr. Gib jedem Agenten nur, was seine Rolle braucht.

Fehler 3: Wissen doppelt pflegen. Steht deine Stilvorlage im Subagenten und in STYLE.md, laufen beide Versionen auseinander. Der Agent soll auf die Quelldateien verweisen (Lies STYLE.md), nicht ihren Inhalt kopieren — dieselbe Regel wie bei Skills.

Übungen

Genug Theorie. Drei Aufgaben, aufsteigend im Anspruch:

Übung 1 — Recherche-Agent anlegen. Erstelle .claude/agents/recherche.md nach dem Beispiel oben. Starte Claude Code und gib den Auftrag: "Recherchiere mit dem recherche-Agenten den aktuellen Stand von Telegram-Bot-Limits." Prüfe danach: Wie kompakt ist die Antwort im Hauptgespräch? Tauchen rohe Suchergebnisse auf? Falls ja, schärfe die Ausgabe-Regeln nach.

Übung 2 — Kritiker als Subagent. Baue einen zweiten Agenten kritiker.md, der Texte nach den 4 Kritiker-Kriterien aus KI-Slop bekämpfen prüft (Rhythmus, KI-Stempel, Spezifität, Faktencheck) und nur eine Mängelliste mit konkreten Korrekturvorschlägen zurückgibt. Gib ihm ausschließlich Lese-Werkzeuge — ein Kritiker soll bewerten, nicht umschreiben. Lass einen alten Post von dir prüfen.

Übung 3 — Pipeline mit Delegation. Kombiniere beides: Lass Claude einen kompletten Post erzeugen, wobei Phase 2 an den recherche-Agenten und Phase 4 an den kritiker-Agenten geht. Vergleiche das Ergebnis mit einem Durchlauf ohne Subagenten — achte auf Qualität der Quellen und darauf, wie gut sich Claude am Ende noch an deine Stilvorgaben vom Anfang erinnert.

Zusammenfassung

Subagenten sind Markdown-Dateien in .claude/agents/<name>.md mit Frontmatter aus name, description und tools
Jeder Subagent hat ein eigenes Context Window — dein Hauptgespräch bleibt sauber
Die description steuert, wann Claude delegiert; die Ausgabe-Regeln steuern, wie viel zurückfließt
Delegieren bei Wegwerf-Kontext, Parallelarbeit und abgegrenzten Rollen — selbst machen bei Kleinkram und Aufgaben, die das ganze Gespräch brauchen
In der Content-Fabrik übernehmen Subagenten Phase 2 (Research) und Phase 4 (Deaify) der Pipeline

In der nächsten Lektion drehen wir den Spieß um: Statt Aufgaben zu delegieren, ziehst du automatische Leitplanken ein, die bei jedem Werkzeug-Einsatz greifen — mit Hooks.