Subagent-Team strukturieren — welche sechs Rollen Du im Daily-Driver brauchst

Einen Subagent zu bauen ist die einfache Uebung. Sechs Subagents nebeneinander laufen zu lassen ohne dass sie sich gegenseitig die Files zerschiessen oder die selbe Recherche dreimal machen, das ist die schwere. Ich hab das über acht Wochen mit fünf verschiedenen Setups getestet und bin bei genau sechs Rollen gelandet, die jeder Solo-Founder oder kleines Team gut gebrauchen kann. Mehr wird unuebersichtlich, weniger lässt Luecken.

Voraussetzung: Du hast das Playbook "Dein erster Sub-Agent in 30 Minuten" durch und kennst das CEO-Worker-Pattern aus Level 5 Lesson 2. Das hier ist der nächste Schritt, naemlich aus einem einzelnen Spezialisten ein abgestimmtes Team zu machen.

1. Die sechs Rollen die fast jeder braucht

Bevor Du Files anlegst, ueberleg welche Aufgaben Du wirklich abgibst. Aus meinen acht Wochen Test sind das diese sechs:

• Researcher — recherchiert externe Quellen, fasst zusammen, schreibt Bericht
• Reviewer — liest Code oder Text und gibt konkretes Feedback, ändert aber nichts
• Drafter — schreibt erste Versionen von Texten, Code, Mails, Posts
• Auditor — prüfen ob Behauptungen stimmen, Quellen verifizieren, gegen Inventar checken
• Coordinator — verteilt Aufgaben an die anderen, fasst Ergebnisse zusammen
• Janitor — raeumt auf, archiviert, deduppt, loescht alte Drafts

Sechs ist die Obergrenze. Ich hatte mal acht und der Coordinator hat alles vergessen weil zu viele Optionen. Bei sechs trifft er konsistent die richtige Wahl.

2. Permission-Profile vorher festlegen

Jeder Subagent kriegt einen anderen Tool-Zugang. Das ist Pflicht, sonst hast Du nach drei Wochen jemand der "mal eben" prod ueberschreibt. Mein Standard:

• Researcher: nur Web-Search + Read, kein Write, kein Bash
• Reviewer: nur Read + Grep, kein Write
• Drafter: Read + Write nur in drafts/, kein git
• Auditor: Read + Web-Search + Verify-Tools, kein Write
• Coordinator: nur Tool-Aufrufe an andere Agents, kein direktes File-Write
• Janitor: Read + Write + Delete in drafts/.archive-*, sonst nichts

Schreib das als ersten Eintrag in jeden Agent-Markdown File rein, oben in den Frontmatter. Wenn Dein Setup die Permissions per tools: Array unterstützt, nutz das. Wenn nicht, schreib es als Prosa in den Prompt und der Coordinator filtert.

3. Agents-Ordner sauber aufteilen

Bei sechs Agents brauchst Du Struktur. Bei mir liegt das so:

~/.claude/agents/
  researcher.md
  reviewer.md
  drafter.md
  auditor.md
  coordinator.md
  janitor.md

Pro Projekt zusätzlich .claude/agents/ im Repo, da kommen Projekt-Varianten rein. Wenn Du für Academy einen anderen Drafter brauchst als für Kundensites, leg .claude/agents/drafter.md im Academy-Repo an. Der ueberschreibt den globalen automatisch. Wichtig: die globalen sind die Generalisten, die lokalen die Spezialisten. Nicht umgekehrt.

4. Wer triggert wen

Der häufigste Anfaengerfehler: jeder Agent kann jeden anderen aufrufen. Das gibt Endlosschleifen. Bei mir geht das nur in eine Richtung. Coordinator ist oben, der ruft Researcher, Drafter, Reviewer, Auditor, Janitor. Diese fünf rufen keine anderen. Wenn der Drafter etwas reviewt haben will, gibt er das an den Coordinator zurück mit Notiz "bitte Review einplanen". Der Coordinator entscheidet.

Das klingt umständlich, ist es aber nicht. Es verhindert dass Du in Loops landest und macht das Debugging trivial. Wenn was schiefgeht, schau in den Coordinator-Trace.

5. Shared Memory oder isolierte Kontexte

Hier wirds knifflig. Jeder Subagent hat seinen eigenen Context-Window. Wenn Researcher 30 Quellen gelesen hat, sieht der Drafter davon nichts. Drei Optionen:

Erste Option: Coordinator schreibt nach jedem Subagent-Call eine Zusammenfassung in eine Datei und gibt die dem nächsten Agent als Input. Funktioniert, ist aber Handarbeit.

Zweite Option: Du nutzt einen Memory-MCP-Server (siehe Level 4 Lesson 3) und alle Agents schreiben/lesen aus dem gleichen Memory-Store. Schoenste Lösung. Braucht aber Setup.

Dritte Option: Du lässt jeden Agent isoliert arbeiten und nimmst in Kauf dass manche Dinge zweimal recherchiert werden. Bei kleinen Teams oft OK.

Ich nutze Variante zwei mit Studiomeyer-Memory. Bei mir hat das die Doppel-Recherche um etwa 60 Prozent reduziert.

6. Output-Konventionen festziehen

Wenn der Drafter heute Markdown schreibt und morgen YAML, kann der Reviewer nichts damit anfangen. Mein Pattern:

• Researcher schreibt immer einen Bericht mit # Frage, ## Quellen, ## Befund, ## Verdict
• Drafter schreibt immer in drafts/{kind}/{slug}.md mit Frontmatter
• Reviewer schreibt immer eine Liste mit - [Severity] Zeile X: Befund Format
• Auditor schreibt immer eine Verify-Statistik oben und Findings unten
• Coordinator schreibt einen Status-Block: was wurde gemacht, was offen, nächster Schritt

Das macht das Mergen von Outputs trivial. Du liest drei Berichte und alle sind gleich strukturiert.

7. Konflikte zwischen Agents vermeiden

Drei Konflikte tauchen immer wieder auf:

Drafter und Janitor: der Drafter schreibt, der Janitor archiviert. Wenn beide gleichzeitig laufen, kann es passieren dass der Drafter eine Datei schreibt, der Janitor sie sieht und sofort wegraeumt. Lösung: Janitor läuft nie parallel, nur explizit über Coordinator-Trigger.

Researcher und Auditor: beide rufen externe URLs ab. Wenn die selben URLs gefragt werden, hast Du doppelte Kosten. Lösung: Auditor checkt erst im Memory-Store ob Researcher die URL schon hatte. Falls ja, recyclen.

Reviewer und Drafter: der Drafter schreibt Version 1, der Reviewer findet 12 Issues, der Drafter schreibt Version 2 mit teilweise neuen Issues. Lösung: max zwei Review-Runden pro Draft, danach geht das an Matthias oder den Menschen.

8. Wann der Coordinator zu viel will

Mein Coordinator hat irgendwann angefangen, alles selber machen zu wollen statt zu delegieren. Klassischer Drift. Das Pattern dahinter: wenn der Coordinator-Prompt zu viele "wenn X, mach Y" Regeln hat, denkt er er kann das gleich selber. Lösung: kürzer schreiben und am Ende einen Satz wie "Du bist Coordinator, nicht Executor. Dein Job ist Delegation, nicht Ausführung."

Konkrete Symptome zum Erkennen: Coordinator gibt 800-Worte-Antworten obwohl drei Subagent-Calls reichen würden. Coordinator argumentiert mit dem User statt zu fragen. Coordinator vergisst Subagents zu starten.

Bei mir hat ein Reset auf 200-Worte-System-Prompt das Problem in einem Tag gelöst.

9. Eval und Verbesserung

Nach zwei Wochen Betrieb solltest Du wissen welcher Agent zu langsam ist, welcher zu oft halluziniert, welcher zu viel kostet. Mein Setup:

Pro Tag läuft der Coordinator ein paar Mal, ich logge Token-Verbrauch pro Agent in eine CSV. Nach einer Woche sehe ich: Researcher braucht 40 Prozent, Drafter 30, Auditor 15, Reviewer 10, Coordinator 4, Janitor 1. Wenn der Drafter ploetzlich auf 50 hoch geht, schau ich was sich am Prompt geaendert hat.

Wenn Du Eval systematischer willst, schau Dir das Playbook "Agent-Eval in 60 Minuten" an. Das zeigt wie Du Testfaelle gegen jeden Agent laufen lässt.

10. Wann Du Subagents NICHT brauchst

Damit das nicht klingt wie "alle müssen Agents bauen": wenn Du weniger als drei wiederkehrende Aufgaben hast, brauchst Du kein Team. Ein einzelner Subagent reicht. Wenn Du keine wiederkehrenden Aufgaben hast, brauchst Du gar keinen, dann ist Vanilla-Claude-Code besser. Und wenn Du mehr als drei Personen im Team hast die alle ihre eigenen Setups fahren, ist ein Agent-Team unter Umständen Overkill und Du brauchst ein richtiges Multi-User-Setup mit geteilten Konfigs.

Faustregel die bei mir funktioniert: ab vier wiederkehrenden Aufgaben pro Woche lohnt sich der Setup-Aufwand für ein Team. Darunter nicht.

Was als nächstes

Wenn Du das Team stehen hast, sind das die zwei nächsten Schritte: erstens schau Dir das Playbook "Hooks gegen Halluzinationen" an um Audit-Schritte zu automatisieren. Zweitens lies Level 6 Lesson 7 "Multi-Agent-Orchestrierung" für die fortgeschrittenen Patterns wenn Du Richtung Skalierung gehst.

Quellen zum Vertiefen:

• Anthropic Doku zu Subagents in Claude Code: https://docs.claude.com/en/docs/claude-code/sub-agents
• Multi-Agent Research-Pattern (Anthropic Blog): https://www.anthropic.com/engineering/multi-agent-research-system