Builder-Validator-Agenten-Teams

Problem: Parallele Claude Code Agenten sind schnell. Ohne klare Rollen liefern sie aber ungleichmäßige Ergebnisse zurück, und du prüfst am Ende jede Zeile selbst. Was du willst: Agenten, die gegenseitig ihre Arbeit kontrollieren.

Du suchst native Agent Teams? Claude Code hat jetzt eine eingebaute Agent-Teams-Funktion für die Multi-Agenten-Zusammenarbeit. Dieser Beitrag zeigt den DIY-Ansatz mit Task-Tools, der ohne experimentelle Features funktioniert.

Schneller Einstieg: Füge diese Builder-Validator-Kette in deine nächste Aufgabe mit mehreren Dateien ein. Der Validator läuft im Lesemodus, direkt nachdem der Builder fertig ist:

TaskCreate(subject="Build auth middleware", description="Create JWT validation middleware in src/middleware/auth.ts. Export verifyToken and requireAuth functions.")
TaskCreate(subject="Validate auth middleware", description="Read src/middleware/auth.ts. Verify: exports exist, error handling covers expired/malformed tokens, no hardcoded secrets. Report issues only. Do NOT modify files.")
TaskUpdate(taskId="2", addBlockedBy=["1"])

Task 2 wartet, bis Task 1 abgeschlossen ist. Der Validator liest, schreibt nie. Zwei Agenten. Eine Ausgabe, der du vertraust.

Warum Paare besser sind als Einzelagenten

Die Grundlagen der Agenten haben erklärt, was Sub-Agenten sind. Task-Verteilung hat erklärt, wie man sie parallel für mehr Geschwindigkeit nutzt. Sub-Agenten-Best-Practices haben das Routing behandelt. Hier geht es um etwas anderes: Agenten Rollen geben und sie zu Teams zusammenstellen.

Einzelagenten haben einen einfachen Fehler. Ein Agent, der den Code geschrieben hat, ist die schlechteste Wahl, um ihn zu prüfen. Gleiche blinde Flecken, gleiche Annahmen, gleiche Abkürzungen. Bring einen unabhängigen Validator rein und du fängst, was der Builder übersehen hat, weil der Validator frisch startet.

Das ist der gleiche Grund, warum menschliche Teams den Autor nicht als einzigen Reviewer lassen. Du holst dir ein zweites Augenpaar.

Das Builder-Validator-Muster

Builder schreiben Code. Validatoren lesen Code. Die Aufgaben überlappen sich nie.

Builder-Prompt - fokussiert auf Erstellung:

You are a builder agent. Your job:
 
1. Read the task description carefully
2. Implement the solution in the specified files
3. Run any relevant tests
4. Mark your task complete
 
Rules:
 
- Only modify files listed in your task
- Do not modify test files (validators handle test verification)
- If you hit a blocker, document it in the task description and mark complete

Validator-Prompt - fokussiert auf Überprüfung:

You are a validator agent. Your job:
 
1. Read all files the builder created or modified
2. Check against the acceptance criteria in the task description
3. Run the test suite
4. Report findings as a new task if issues exist
 
Rules:
 
- Do NOT modify any source files
- Do NOT create new implementation code
- You may only create or update task entries to report issues
- Use Read and Bash (for tests) only - never Edit or Write

Die wichtigste Einschränkung: Validatoren dürfen keinen Code schreiben. Das zwingt sie, echte Probleme aufzuzeigen, statt sie still zu beheben und die Prüfung zu überspringen. Wenn ein Validator ein Problem findet, erstellt er einen neuen Task, der zurück zu einem Builder geht. Du kannst das auf Tool-Ebene mit benutzerdefinierten Agentendefinitionen plus disallowedTools absichern, was Edit und Write komplett aus Validatoren herausnimmt.

Abhängigkeitsketten für Build-Then-Validate

Der addBlockedBy-Parameter bei TaskUpdate ist das, was dieses Muster zusammenhält. Validatoren warten auf ihren Builder ohne zusätzliche Verkabelung:

// Phase 1: Parallel builders
TaskCreate(subject="Build user API routes", description="Create CRUD endpoints in src/api/users.ts...")
TaskCreate(subject="Build user database schema", description="Create migration in src/db/migrations/...")

// Phase 2: Validators blocked by their builders
TaskCreate(subject="Validate API routes", description="Read src/api/users.ts. Verify REST conventions, error handling, input validation...")
TaskCreate(subject="Validate database schema", description="Read migration files. Verify column types, indexes, foreign keys...")

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

Tasks 1 und 2 laufen parallel, weil sie verschiedene Dateien anfassen. Tasks 3 und 4 warten jeweils auf ihren eigenen Builder. Parallele Geschwindigkeit in der Build-Phase. Unabhängige Prüfung jeder Ausgabe.

Übergreifende Prüfungen, die alles erst gebaut brauchen, stapeln einfach mehrere Blocker:

TaskCreate(subject="Integration validation", description="Verify API routes correctly reference the database schema. Check that all referenced tables and columns exist.")
TaskUpdate(taskId="5", addBlockedBy=["1", "2"])

Ein Meta-Prompt, der den ganzen Plan aufbaut

Tasks manuell zu verketten wird mühsam. Ein Meta-Prompt in CLAUDE.md kann eine Feature-Anfrage auf der Stelle in einen vollständigen Team-Plan verwandeln:

## Team Plan Generation
 
When I say "team plan: [feature]", generate a task structure:
 
For each component:
 
1. TaskCreate a builder task with specific files and acceptance criteria
2. TaskCreate a validator task scoped to read-only verification
3. TaskUpdate to chain validator behind its builder
 
After all component pairs, add one integration validator blocked by ALL builders.
 
Format each task description with:
 
- **Files**: exact paths to create or read
- **Criteria**: measurable acceptance conditions
- **Constraints**: what this agent must NOT do

Jetzt sagst du einfach: "team plan: Stripe-Webhook-Handler hinzufügen." Claude gibt den vollständigen Abhängigkeitsgraphen zurück, paart jede Komponente mit ihrem Validator und setzt am Ende einen Integrations-Validator. Du liest den Plan, sagst los, Agenten starten.

Das ist das Orchestrator-Muster in Aktion. Deine Claude-Hauptsitzung koordiniert. Sie schreibt den Plan, verdrahtet die Blocker und schickt die Agenten raus. Den Anwendungscode selbst schreibt sie nicht.

Wenn eine Validierung fehlschlägt

Der Kreislauf geht weiter, wenn ein Validator ein Problem meldet:

Validator erstellt einen Fix-Task, der beschreibt, was kaputt ist
Ein Builder-Agent nimmt den Fix-Task auf
Ein neuer Validator-Task wird hinter dem Fix eingereiht

// Validator found missing error handling
TaskCreate(subject="Fix: add error handling to user API", description="The GET /users/:id endpoint returns 500 on invalid ID format. Add input validation and return 400 for malformed IDs.")
TaskCreate(subject="Re-validate user API error handling", description="Verify GET /users/:id returns 400 for non-UUID strings, 404 for valid UUID not found, 200 for valid existing user.")
TaskUpdate(taskId="7", addBlockedBy=["6"])

Jeder Durchlauf schärft den Fokus. Der erste Builder behandelt das gesamte Feature. Spätere Builder behandeln je einen Bug. Der Kreislauf bringt den Code auf korrekt, ohne dass du die mittleren Schritte selbst debuggen musst.

Für härtere Prüfungen können Hooks automatische Regeln bei jeder Dateiänderung ausführen, sodass Probleme gefunden werden, bevor der Validator-Agent überhaupt aufwacht. Du kannst noch weiter gehen, indem du die Validierung direkt in Agentendefinitionen einbaust, was die Qualitätsprüfung zum Teil der Identität des Agenten macht.

Mit einem Paar anfangen

Wirf nicht deinen ganzen Workflow um. Wähle das nächste Feature, das zwei oder mehr Dateien berührt. Erstelle einen Builder-Task. Erstelle einen Validator-Task mit addBlockedBy. Schau zu, wie der Validator etwas markiert, das der Builder übersehen hat.

Wenn du gesehen hast, dass es funktioniert, steck mehr rein: parallele Builder mit verketteten Validatoren, Meta-Prompts, die den Plan schreiben, Integrations-Validatoren, die alles zusammenbinden. Bau dein Agenten-Setup um klare Rollengrenzen. Lass das Task-System die Reihenfolge regeln. Die Entscheidungen behältst du.