Agenten-Muster

Problem: Sub-Agenten funktionieren, aber du greifst immer wieder zur gleichen Form. Ein paar parallele Aufrufe, Daumen gedrückt, manueller Kleber für alles, was zurückkommt. Es gibt einen besseren Weg, Agenten-Arbeit zu organisieren, und die Form, die du wählst, entscheidet, ob die Ausgabe hält oder auseinanderfällt.

Sechs Orchestrierungsmuster tauchen immer wieder in echter Claude Code Arbeit auf. Jedes passt zu einer anderen Art von Job. Wähle schlecht und Token lecken, Dateien kollidieren oder Antworten driften weg. Wähle gut und eine Horde Agenten kann harte Arbeit mit fast keiner Aufsicht durchkauen.

Muster-Auswahl

Wenn du nur eine schnelle Auswahlregel brauchst, nimm diese:

Der Fehler ist, Muster wie Ideologie zu behandeln. Sie sind Arbeitsbelastungsformen. Nimm das, das zum Koordinierungsproblem vor dir passt.

Lies diese Seite, wenn die offene Frage die Orchestrierungsform ist. Wenn du noch entscheidest zwischen Sub-Agenten, Slash-Commands, Agentendefinitionen und repo-weiten Regeln, fang mit Agent Fundamentals an. Wenn deine Arbeitslast mehrere Claude-Sitzungen erfordert, die direkt über eine gemeinsame Task-Liste und ein Postfach zusammenarbeiten, geh zu Claude Code Agent Teams.

Das Orchestrator-Muster

Ein zentraler Faden führt das Ruder und gibt Arbeit an Spezialisten heraus. Er berührt selbst keinen Code. Sein ganzer Job ist Planung, Delegation, Überprüfung und Routing.

Wann du es nutzt: Features, die Frontend, Backend und Datenbank überschneiden. Alles, wo jemand das ganze Bild im Kopf halten muss.

Wie es in Claude Code funktioniert: Der primäre Chat wird zum Dirigenten. Er liest das Spec, entwirft einen Plan und spawnt dann Spezialisten über das Task-Tool. Ergebnisse kommen zurück, werden geprüft, und der nächste Schritt wird auf der Stelle entschieden.

You are the orchestrator. For this feature request, create a plan that:
1. Breaks the work into domain-specific tasks
2. Identifies dependencies between tasks
3. Dispatches each task to a sub-agent with explicit file scope
4. Reviews outputs before marking complete

Do NOT write implementation code yourself. Coordinate only.

CLAUDE.md ist das natürliche Zuhause für diese Verkabelung. Routing-Regeln leben in dieser Datei, und der Dirigent behandelt sie wie einen Vertrag. In einem soliden Setup wird der gesamte Task-Abhängigkeitsgraph zuerst ausgearbeitet, bevor ein Sub-Agent eine einzige Zeile schreibt.

Wann du es nicht nutzt: Kleine Jobs, die ein einziger Agent in einem Durchlauf erledigen kann. Eine Hilfsfunktion hinzufügen, einen Tippfehler beheben. Der Overhead der Orchestrierung ist teurer als jeder Nutzen, den sie zurückbringt.

Das Fan-Out / Fan-In-Muster

Viele Agenten gehen parallel raus. Alle berichten zurück. Ein Faden zieht die Ergebnisse zu einer einzigen Antwort zusammen.

Wann du es nutzt: Recherche-Sweeps. Mehrdatei-Analysen. Alles, wo jeder Agent an seinen eigenen Eingaben ohne Überschneidung arbeitet. Code-Reviews über unabhängige Module. Informationen aus verschiedenen Ecken einer Codebase sammeln, bevor eine Entscheidung getroffen wird.

Wie es in Claude Code funktioniert: Starte parallele Sub-Agenten, indem du mehrere Task-Tool-Aufrufe in einer Nachricht machst. Jeder öffnet seine eigenen Dateien oder verfolgt seine eigene Frage. Sobald jeder Agent zurückkommt, setzt der zentrale Faden die Teile zusammen.

Complete these 4 tasks using parallel sub-agents:

1. Read src/api/ and list all endpoints missing input validation
2. Read src/auth/ and identify any hardcoded secrets or weak patterns
3. Read src/db/ and check for missing indexes on frequently queried columns
4. Read src/utils/ and flag any functions with no error handling

After all agents report back, synthesize findings into a prioritized action list.

Die Fan-out-Phase ist schnell, weil Agenten keinen Zustand teilen. Die Fan-in-Phase ist das Herzstück: der Orchestrator erkennt Verbindungen zwischen Befunden, die kein einzelner Agent sehen konnte. Ein schwacher Auth-Pfad plus eine Lücke bei der Eingabevalidierung kann zusammen einen Live-Exploit ergeben, auch wenn keiner der einzelnen Reports so klingt.

Wann du es nicht nutzt: Jeder Job, bei dem mehrere Agenten überlappende Dateien bearbeiten müssen. Gleichzeitige Schreibvorgänge auf gemeinsamen Code führen direkt in Merge-Konflikte. Wenn die Arbeit nicht wirklich unabhängig ist, ist eine sequenzielle Kette der richtige Weg.

Das Validierungsketten-Muster

Ein Builder-Agent schreibt den Code. Ein anderer Validator-Agent prüft ihn. Ihre Rollen vermischen sich nie.

Wann du es nutzt: Produktions-Änderungen. Sicherheitssensible Arbeit. Überall, wo eine falsche Antwort echtes Geld kostet. Greif auf dieses Muster zurück, wenn ein Bug einfach nicht infrage kommt.

Wie es in Claude Code funktioniert: Zwei Tasks verdrahtet durch eine Abhängigkeit. Der Builder liefert zuerst Code. Sobald das erledigt ist, öffnet der Validator das Diff, führt Tests aus und reicht seinen Report ein, ohne eine einzige Datei anzufassen.

TaskCreate(
  subject="Build payment webhook handler",
  description="Create Stripe webhook handler in src/api/webhooks/stripe.ts.
  Handle checkout.session.completed, payment_intent.failed events.
  Verify webhook signatures. Include error handling."
)

TaskCreate(
  subject="Validate payment webhook handler",
  description="Read src/api/webhooks/stripe.ts. Verify:
  - Webhook signature verification exists
  - Both event types handled with proper responses
  - Error handling covers malformed payloads
  - No hardcoded secrets
  Report issues only. Do NOT modify any files."
)

TaskUpdate(taskId="2", addBlockedBy=["1"])

Der addBlockedBy-Link ist das, was den Validator ehrlich hält. Er wartet, bis der Builder fertig ist, und geht kalt rein. Keine gemeinsamen Annahmen. Keine vererbten blinden Flecken. Deshalb fängt die Prüfung tatsächlich Dinge.

Wenn der Validator ein Problem findet, öffnet er einen Fix-Task, der an einen Builder gerouted wird. Dann stellt ein neuer Validator hinter diesem Fix an. Der Kreislauf schärft sich, bis die Ausgabe stimmt.

Wann du es nicht nutzt: Wegwerf-Prototyping, wo Geschwindigkeit wichtiger ist als Korrektheit. Ein dedizierter Validator verdoppelt ungefähr den Rechenaufwand pro Task. Wenn der Code Scratch ist, bringt dich ein Agent schneller ans Ziel, für weniger Token.

Das Spezialistenrouting-Muster

Route jeden Task zum Domain-Experten, der den Job kennt. Frontend-Arbeit landet bei einem Frontend-Spezialisten. Migrationen gehen zum Datenbank-Experten. Jeder Agent hält seine eigenen Konventionen, Anweisungen und Tool-Grenzen.

Wann du es nutzt: Große Repos mit mehreren klaren Domains. Teams mit eingespielten Konventionen pro Schicht. Überall dort, wo generische Anweisungen dir immer wieder matschige, inkonsistente Ausgaben über die Codebase geben.

Wie es in Claude Code funktioniert: Richte Spezialisten-Agenten in .claude/agents/ ein, oder pin Routing-Regeln in deine CLAUDE.md. Der Orchestrator prüft den Task, markiert die Domain und gibt sie an den richtigen Experten weiter.

<!-- In CLAUDE.md -->

## Agent Routing Table

| Task Domain | Route To            | File Scope           |
| ----------- | ------------------- | -------------------- |
| React/UI    | frontend-specialist | src/components/      |
| API routes  | backend-engineer    | src/api/, src/lib/   |
| Database    | database-specialist | src/db/, migrations/ |
| Security    | security-auditor    | Any (read-only)      |
| Tests       | quality-engineer    | tests/, **tests**/   |

Jeder Spezialist, der in .claude/agents/ definiert ist, erbt deine CLAUDE.md automatisch. Coding-Standards kommen mit. Die eigene Datei des Agenten fügt den Rest hinzu: Framework-Entscheidungen, Namensregeln, auf diese Schicht zugeschnittene Fehlerbehandlung.

Wachstum ist günstig. Neue Domain bedeutet eine neue Agenten-Datei und eine neue Zeile in der Routing-Tabelle. Nichts wird umgeschrieben. Der Custom-Agents-Guide erklärt, wie man Spezialisten mit YAML-Frontmatter definiert.

Wann du es nicht nutzt: Winzige Codebases, wo ein einzelner Agent bereits genug Kontext über alles hat. Routing-Overhead bringt nichts, wenn es sowieso nur ein Ziel gibt.

Das Progressive-Verfeinerungs-Muster

Beginne mit einem lockeren Entwurf. Schicke ihn durch mehrere Runden der Bearbeitung. Jede Runde achtet auf eine einzige Qualitätsachse.

Wann du es nutzt: Content-Arbeit, verhedderte Architektur, jeder Job, bei dem es auf Anhieb richtig zu treffen unrealistisch ist. Funktioniert sauber bei Blog-Posts, API-Schemas oder Konfigurationsdateien, die mehrere Einschränkungen auf einmal erfüllen müssen.

Wie es in Claude Code funktioniert: Agenten in einer Sequenz einreihen, wo jeder die vorherige Ausgabe liest und einen Aspekt schärft.

Phase 1 - Draft: "Generate the initial API schema for a task management
system. Include all entities, relationships, and basic validation rules."

Phase 2 - Security review: "Review this schema. Add authentication
requirements, permission checks, and input sanitization rules.
Don't change the core structure."

Phase 3 - Performance review: "Review the schema for performance.
Add indexes, identify N+1 query risks, suggest denormalization
where read performance matters."

Phase 4 - Final validation: "Verify the schema is consistent.
Check that all referenced entities exist, foreign keys are valid,
and naming conventions are uniform."

Jede Phase hat enge Augen. Der Entwurfs-Agent kümmert sich um Vollständigkeit. Sicherheit fügt Schutzmaßnahmen hinzu. Performance optimiert. Validierung prüft Kohärenz. Kein Agent wird gebeten, alle Bedenken auf einmal zu jonglieren.

Es spiegelt wider, wie echte Entwickler arbeiten. Code landet nie produktionsreif beim ersten Durchlauf. Du entwirfst, fixst Korrektheit, tuanst Performance, polierst. Dieses Muster gibt jeden Durchlauf an einen darauf zugeschnittenen Agenten.

Wann du es nicht nutzt: Jeder Job, der auf einen Schlag landen muss, wo schichtweise Verbesserung nicht im Angebot ist. Auch sinnlos bei einfacher Arbeit, wo der erste Entwurf bereits die Latte reißt.

Das Watchdog-Muster

Ein Hintergrund-Agent sitzt und beobachtet eine Bedingung. Wenn sie auslöst, berichtet oder handelt der Watchdog. Er läuft neben deiner Hauptarbeit, nie im Weg.

Wann du es nutzt: Lange Sitzungen, bei denen Drift sich einschleicht. Ein Auge auf die Kontext-Gesundheit behalten, Regressionen während eines Refactors aufspüren oder Builds beobachten, die rot werden, während deine Aufmerksamkeit woanders ist.

Wie es in Claude Code funktioniert: Hintergrunde einen Watchdog mit Ctrl+B und mach weiter mit dem, was du gemacht hast. Der Agent prüft seinen Auslöser rhythmisch. Wenn etwas auslöst, tauchen Ergebnisse direkt in deiner Task-Liste auf.

Background task: Monitor the test suite while I refactor the auth module.
Every time I complete a change, run the test suite for src/auth/.
If any test fails, immediately create a task with:
- Which test failed
- The assertion error
- Which file I likely broke based on the test name

Ein gutes Beispiel lebt im Context-Recovery-Hook. Er ist ein Watchdog, der in die Infrastruktur selbst verdrahtet ist, die Kontextnutzung verfolgt und Recovery auslöst, sobald das Fenster sich zu füllen beginnt. Agent-Health- und Progress-Hooks funktionieren genauso.

Watchdogs zahlen sich am meisten aus, wenn sie mit async Workflows kombiniert werden, wo hinterlegte Agenten eigenständig laufen und Ergebnisse vor dir aufpoppen, wenn du bereit bist.

Wann du es nicht nutzt: Kurze Sitzungen, wo die Kosten des Beobachtens mehr sind als der Wert des Beobachteten. Ein Zwei-Minuten-Task plus ein Watchdog, der alle dreißig Sekunden pollt, ist ein Nullsummenspiel.

Muster kombinieren

Echte Projekte bleiben fast nie in einem einzigen Muster. Ein nicht-triviales Feature endet oft so verdrahtet:

1. Orchestrator liest das Spec und entwirft den Plan
2. Spezialistenrouting gibt Tasks an Domain-Experten weiter
3. Fan-out führt die unabhängigen Teile parallel aus
4. Validierungsketten prüfen die Arbeit jedes Spezialisten
5. Progressive Verfeinerung poliert das zusammengeführte Ergebnis
6. Watchdog behält die ganze Zeit ein Auge auf die Test-Suite

Die Fähigkeit liegt nicht darin, die Liste auswendig zu lernen. Es geht darum, den Task vor dir zu lesen und ihn der richtigen Form zuzuordnen. Greif zum einfachsten Muster, das die Last tragen kann. Füge mehr Struktur nur hinzu, wenn das eine zusammenbricht.

Drei Kombinationen, die gut funktionieren

1. Orchestrator + Spezialistenrouting

Am besten für:

• Full-Stack-Features
• Cross-Layer-Refactors
• Änderungen, die ein koordinierendes Gehirn brauchen

Warum es funktioniert: Der Orchestrator hält den Plan, während Routing jede Implementierungsaufgabe in den richtigen Händen hält.

2. Fan-out + Validierungskette

Am besten für:

• Breite Audits
• Sicherheits- oder Qualitäts-Sweeps
• Review-lastige Workflows

Warum es funktioniert: Unabhängige Agenten sammeln Befunde parallel, dann fängt ein separater Validator schwache Schlussfolgerungen ab, bevor irgendetwas als vertrauenswürdig gilt.

3. Progressive Verfeinerung + Watchdog

Am besten für:

• Lange Content-Workflows
• Architektur-Entwürfe
• Alles, wo Qualität über mehrere Durchläufe steigt

Warum es funktioniert: Eine Kette verbessert das Artefakt, während der Watchdog den umgebenden Systemzustand, Tests oder Regressionen im Blick behält.

Nächste Schritte:

• Agent Fundamentals, für wie Sub-Agenten und Slash-Commands zusammensitzen
• Sub-Agent Best Practices, für parallele versus sequenzielle Routing-Aufrufe
• Team Orchestration, für den vollständigen Builder-Validator-Kreislauf
• Task Distribution, um Multi-Agenten-Arbeit organisiert zu halten
• Custom Agents, zum Schreiben eigener Spezialistendefinitionen