Agent Teams Workflow

Problem: Agent Teams ist eingeschaltet. Du hast dein erstes Team ausgeführt. Spawning funktioniert. Aber die Ausgabe ist ein Haufen halb-integrierter Teile, die du am Ende selbst zusammennähst. Die Lücke zwischen "Agent Teams laufen" und "Agent Teams liefern Produktionscode" ist ein Prozess, kein Feature-Flag.

Quick Win: Ein Workflow, der Agent Teams zuverlässig macht, läuft in zwei Phasen. Planung entfernt Annahmen und fixiert die Contracts zwischen Domains. Ausführung spawnt dann Agents in Wellen und gibt jeder Welle die Contracts, die sie braucht, damit parallele Arbeit sauber zusammenpasst. Der vollständige Workflow ist unten.

Das ist der Begleit-Guide zum Agent Teams-Überblick. Wenn du das Feature noch nicht eingeschaltet oder ein erstes Team ausgeführt hast, fang dort an. Für Steuerung und Konfiguration, sieh Advanced Controls. Für Copy-Paste-Vorlagen, sieh Use Cases.

Parallele Claude-Sessions spawnen zu können, die miteinander sprechen, ist eine Fähigkeit. Agentische Workflows brauchen mehr als eine Fähigkeit. Rohes Spawning ohne einen Prozess ist wie fünf Auftragnehmern die Schlüssel zu einer Baustelle ohne Blaupausen zu geben: alle bauen, nichts passt zusammen.

Zwei Fehlermuster tauchen auf, wenn es keinen Workflow gibt:

1. Annahmen-Drift. Jeder Agent wählt seine eigenen Datenformen, Namensgebung, Fehlerformate und Randfälle. Das Backend gibt { notif_type: "comment" } zurück und das Frontend liest { type: "COMMENT" }. Unit-Tests bestehen auf beiden Seiten. Integration explodiert.

2. Fehlende Validierung. Jeder Agent meldet Erfolg, also markiert der Lead die Aufgaben als erledigt. Niemand hat den vollständigen Ablauf getestet. Die App bricht beim ersten Klick und vergrabene Fehler tauchen auf.

Eine Pipeline behebt beide:

1. Brain Dump deiner Anforderungen (unstrukturiert, unordentlich, das ist in Ordnung)
2. Recherche und Q&A, wo Claude deine Codebase untersucht und dir Klärungsfragen stellt
3. Strukturierter Plan mit Team-Mitgliedern, Abhängigkeitsketten und Akzeptanzkriterien
4. Frischer Kontext, wo du eine neue Session nur mit dem Plan startest
5. Contract Chain-Analyse, wo der Lead Interfaces aus dem Abhängigkeitsgraphen des Plans ableitet
6. Wave-Ausführung, wo Agents parallel gegen injizierte Contracts bauen
7. Validierungsschleife, wo der Lead End-to-End-Prüfungen gegen Akzeptanzkriterien ausführt

Jeder Schritt existiert, weil das Überspringen einen spezifischen Fehler produziert. Der Rest dieses Beitrags geht sie einen nach dem anderen durch.

Schritt 1: Brain Dump

Poliere den Input nicht. Schreib, was du willst, in normaler Sprache. Schließe alles ein, was dir in den Sinn kommt, auch wenn es unordentlich, halbfertig oder widersprüchlich ist. Ziel: Deinen Kopf auf die Seite leeren.

Das ist kein Spec. Es ist Rohmaterial. Der ganze Sinn des Brain Dumps ist, Absicht und Kontext einzufangen, der in dem Moment stirbt, wenn du versuchst, einen formalen Spec aus deinem Kopf zu zwingen.

Ein Brain Dump verdoppelt sich als Umfangsprüfung. Wenn du nicht in ein paar Absätzen skizzieren kannst, was du willst, ist das Feature zu groß für eine einzelne Agent Teams-Session. Zerteile es zuerst.

Schritt 2: Recherche und Q&A

Das ist der Schritt, den die meisten überspringen, und er ist der wichtigste. Das Ziel: Annahmen reduzieren, bevor Code geschrieben wird.

Die meisten Agent Teams-Fehler kommen nicht von schlechtem Code. Sie kommen von Fehlausrichtung. Der Agent liefert etwas, das nicht das ist, was du wolltest, weil er falsch geraten hat. Fix: Lass Claude deine Codebase lesen und dir Fragen stellen, bevor es irgendetwas plant. Strukturierte Team-Planung ersetzt die Ad-hoc-Gewohnheit, "in den Plan-Modus zu wechseln".

Nicht 2 oder 3 Fragen. Mindestens 10. Jede weitere Frage, die Claude stellt, ist eine Annahme weniger, die in den Plan eingebacken ist.

Claude kommt mit Fragen wie:

• Soll die Abrechnungsseite unter dem Dashboard-Layout sein oder eigenständig?
• Welche Token-Pakettiers und Preise willst du?
• Sollen wir ChargeB's gehostetes Checkout oder in-app eingebettet verwenden?
• Was soll in der Chat-UI passieren, wenn ein Nutzer null Tokens hat?
• Hast du bereits ein ChargeB-Konto und einen Webhook-Endpoint konfiguriert?

Jede Frage ist eine potenzielle Weggabelung in der Implementierung. Ein Agent, der "eingebettetes Checkout" annimmt und anfängt zu bauen, schrottet alles, sobald du ihm sagst, du wolltest das gehostete. Zehn Minuten Q&A eliminiert Stunden von Nacharbeit.

Das AskUserQuestion-Tool in Claude Code macht das schnell. Die meisten Antworten sind Multiple Choice. Klick durch, wo Claude's Wahl richtig ist. Tippe eine benutzerdefinierte Antwort, wo du Präzision brauchst.

Für strukturiertere Ansätze zur Planungsphase, sieh auto-planning strategies.

Schritt 3: In einen strukturierten Plan umwandeln

Mit abgeschlossenem Q&A, bake alles in einen strukturierten Plan. Dieser Plan wird das einzige Artefakt, das den gesamten Team-Run antreibt. Er muss tragen:

• Aufgabenbeschreibung und Ziel, damit das Team weiß, wie Erfolg aussieht
• Relevante Dateien, damit Agents wissen, was existiert und was erstellt werden soll
• Team-Mitglieder mit benannten Rollen, Agent-Typen und einzelnen Verantwortlichkeiten
• Schritt-für-Schritt-Aufgaben mit Abhängigkeitsketten (Depends On-Felder) und Datei-Eigentumsgrenzen
• Akzeptanzkriterien, die spezifisch und messbar sind
• Validierungsbefehle, die ausgeführt werden können, um die Arbeit zu verifizieren

Hier ist die Struktur, die Team-Orchestrierung zum Laufen bringt:

Der Plan macht drei Jobs gleichzeitig: er zeichnet Datei-Eigentumsgrenzen (keine Konflikte), codiert eine Abhängigkeitskette (damit die Ausführung weiß, was zuerst zu bauen ist) und schreibt Akzeptanzkriterien nieder (damit Validierung etwas Konkretes zum Anzielen hat).

Schau dir die Depends On-Felder an. Sie sind keine Docs. Sie bilden die Contract Chain, die die Ausführungsphase nutzt, um zu entscheiden, welche Agents zuerst gespawnt werden und welche Interfaces zwischen den Wellen gezogen werden.

Schritt 4: Frisch mit dem Plan starten

Das fühlt sich falsch an und ist trotzdem wichtig. Öffne eine neue Claude Code-Session nur mit dem geladenen Plan. Mach nicht in demselben Kontextfenster weiter, wo du den Brain Dump und das Q&A gemacht hast.

Warum? Planungsgespräche verbrennen Kontext. Sie sind vollgestopft mit explorativen Fragen, toten Ideen und Hin-und-Her, das jetzt irrelevant ist. Der Plan ist die destillierte Version. Er enthält bereits, was das Team braucht. Das Planungs-Geplapper ist totes Gewicht, das den Build verdrängt.

Das bedeutet auch, dass Pläne wiederverwendbar sind. Eine Session, die auf halbem Weg scheitert, startet von derselben Plan-Datei neu. Keine Planungsarbeit wird wiederholt.

Schritt 5: Contract Chain-Analyse

Bevor ein Agent gespawnt wird, geht der Lead den Abhängigkeitsgraphen des Plans durch und zieht die Contract Chain heraus. Das ist der Schritt, der Agent Teams vertrauenswürdig für Produktions-Builds macht.

Eine Contract Chain gruppiert Aufgaben nach ihren Abhängigkeiten in Wellen, dann benennt die Outputs, die jede abschließende Welle produziert und die die nächste Welle braucht:

Hier ist die zentrale Erkenntnis: Kein Agent beginnt Arbeit, bis seine Contracts existieren. Der Datenbank-Agent läuft zuerst. Wenn er fertig ist, sendet er dem Lead die echten Schema-Definitionen, Tabellen-Typen und Beziehungen. Diese Outputs SIND der Contract. Der Lead fügt dann diese konkreten Schemas direkt in die Spawn-Prompts für die API- und Frontend-Agents ein, damit beide gegen echte Interfaces bauen statt ihre eigenen zu erfinden.

Deshalb endet paralleles Agenten-Code mit Code, der tatsächlich integriert: Sie raten nicht unabhängig Datenformen. Sie schreiben alle gegen denselben Contract, und dieser Contract kam aus Arbeit, die bereits geliefert wurde.

Was als Contract injiziert wird

Contracts sind keine abstrakten Specs. Sie sind die tatsächlichen Outputs vorgelagerter Arbeit:

• Datenbank abgeschlossen -> Schema-Contract: exakte Tabellendefinitionen, Spaltentypen, Fremdschlüssel, TypeScript-Typen
• API abgeschlossen -> API-Contract: Endpoint-Routen, Request-/Response-Formen, Status-Codes, Auth-Anforderungen
• Shared Types erstellt -> Typ-Contract: Interfaces, Enums, Konstanten, die mehrere Agents referenzieren

Jeder nachgelagerte Agent bekommt die passenden Contracts in seinen Spawn-Prompt eingefügt. Nicht "geh und lies, was der Datenbank-Agent getan hat." Den rohen Inhalt. Das eliminiert den Fehlermodus, wo ein Agent veraltete Dateien liest oder die Ausgabe eines anderen Agents falsch liest. Subagent-Muster lassen jeden Agent in seiner eigenen Ecke raten. Ein richtiger agentischer Workflow verkabelt jeden Agent mit einem verifizierten Interface.

Schritt 6: Wave-Ausführung

Mit der ausgelegten Contract Chain spawnt der Lead Agents in Wellen.

Welle 1 (Fundament): Der Datenbank-Agent geht zuerst. Er handhabt grundlegende Arbeit: Schemas, shared Types, Config. Der Lead wartet auf den Abschluss und nimmt den Contract in Empfang.

Welle 2+ (Parallel): Sobald der Schema-Contract landet, spawnen API- und Frontend-Agents zusammen. Jeder bekommt den Schema-Contract in seinen Prompt eingefügt, zusammen mit seiner Aufgabenzuweisung und Datei-Eigentumsgrenzen.

Teammitglieder-Spawn-Prompts folgen dieser Struktur:

Die lastentragenden Teile: Datei-Eigentumsgrenzen (keine zwei Agents berühren dieselben Dateien), vorgelagerte Contracts (tatsächlicher Inhalt, keine Referenzen), und nachgelagerte Contract-Verpflichtungen (was dieser Agent für andere produzieren muss).

Schalte den Delegate-Modus ein, damit der Lead koordiniert statt selbst Code zu schreiben. Während der Ausführung ist die Aufgabe des Leads, die Aufgabenliste zu beobachten, Contract-Mismatches zu sortieren und Agents zu nudgen, die anfangen abzudriften.

Brownfield-Codebases

Die meiste echte Arbeit passiert innerhalb einer bestehenden Codebase. Brownfield Agent Teams brauchen Konvention-Konsistenz. Drei Agents, die gleichzeitig dasselbe Projekt bearbeiten, müssen trotzdem den Mustern folgen, die bereits da sind.

Fix: Dokumentiere deine Projektkonventionen in CLAUDE.md (Benennung, Fehlerbehandlung, Datei-Layout, Test-Ansatz). Agent Teams lesen CLAUDE.md als gemeinsamen Laufzeitkontext, also startet jedes Teammitglied von Zeile eins aus ausgerichtet. Überspring das und ein Agent liefert camelCase API-Antworten, während ein anderer snake_case liefert, weil jeder eine Konvention im Flug gewählt hat.

Schritt 7: Post-Build-Validierung

Teammitglieder, die ihre Aufgaben beenden, bedeutet nicht fertig. Parallele Builds produzieren Komponenten, die für sich bestehen, aber an den Nähten aufbrechen. Validierung fängt diese Fehler.

Die Akzeptanzkriterien und Validierungsbefehle des Plans treiben diesen Schritt an. Der Lead (oder ein dedizierter Quality-Engineer-Agent) geht jedes Kriterium einzeln durch:

Das False-Positive-Problem

Das gruseligste Post-Build-Szenario: Jeder Agent markiert seine Aufgaben als abgeschlossen und meldet Erfolg, aber vergrabene Fehler sitzen da. Das passiert, weil Agents dazu angehalten werden, Aufgaben zu schließen, und manchmal ihre eigene Arbeit absegnen.

Begegne dem, indem du nach Beweisen, nicht Bestätigung verlangst. Frag nie "hat alles funktioniert?" Frag nach spezifischen Outputs:

Beweise zu fordern zwingt den Lead, tatsächlich zu verifizieren statt auf einem Vibe zu pattern-matchen. Gleiche Idee wie Code-Review: Du liest den Diff, du fragst den Autor nicht einfach, ob es funktioniert.

Der Fix-Retest-Zyklus

Wenn Validierung ein Problem findet, ist die Schleife einfach:

1. Lead identifiziert den Mismatch (z.B. Webhook-Handler gibt falschen Status-Code zurück)
2. Lead sendet Nachricht an das verantwortliche Teammitglied oder spawnt einen gezielten Fix-Agent
3. Fix wird angewendet
4. Lead führt die betroffenen Validierungsprüfungen erneut aus

Die meisten Runs konvergieren in 1 oder 2 Iterationen, wenn Contracts richtig eingerichtet wurden. Ohne Contracts dreht sich die Fix-Retest-Schleife, weil jeder Fix einen weiteren Annahmen-Mismatch aufdeckt. Diese Spirale ist genau der Grund, warum die Contract Chain existiert.

Für strukturierte Fix-Schleifen, die auf Abhängigkeitsketten aufgebaut sind, formalisiert das Builder-Validator-Muster das als Aufgabenabhängigkeiten, bei denen Validatoren automatisch nach Buildern laufen.

Schritte 1-3 (Planung) dauern 15 bis 30 Minuten interaktiver Arbeit. Schritte 4-7 (Ausführung) laufen größtenteils unbeaufsichtigt, sobald die erste Welle raus ist.

Das Verhältnis ist der Punkt: 30% deiner Zeit für Planung und Contracts hebt die 70% Nacharbeit auf, die du sonst damit verbringen würdest, Integrationsfehler aus einem schlecht geplanten parallelen Build aufzuräumen.

Alle sieben Schritte können manuell mit rohen Prompts durchgeführt werden. Aber die repetitiven Teile (Plan-Formatierung, Contract Chain-Ableitung, Wave-Ausführung, Validierungssequenzierung) sind mechanisch genug, um in wiederverwendbare Befehle einzuwickeln.

Die Konzepte hier (Annahmen-Reduktion durch Q&A, Contract Chains zwischen Wellen, evidenzbasierte Validierung) gelten unabhängig davon, ob du sie mit Befehlen, rohen Prompts oder einer benutzerdefinierten Orchestrierungsschicht ausführst.

Wähle ein Feature, das mindestens zwei Schichten überschreitet (Frontend + Backend oder API + Datenbank):

1. Brain Dump, was du willst
2. Lass Claude dir 10 Klärungsfragen stellen
3. Baue einen strukturierten Plan mit Team-Mitgliedern und Abhängigkeitsketten
4. Starte frisch und lass den Lead die Contract Chain ableiten
5. Schau Agents dabei zu, wie sie in Wellen gegen gemeinsame Contracts bauen
6. Validiere die Integrationspunkte mit Beweisen, nicht Bestätigung

Der erste Run dauert länger, weil du das Muskelgedächtnis aufbaust. Beim dritten Feature wird der Workflow zur zweiten Natur und das Compounding setzt ein: Pläne werden zu wiederverwendbaren Vorlagen, Contracts werden zu standardisierten Interfaces, und Validierungskriterien stapeln sich zu einer projektweiten Qualitäts-Baseline.