Agenten-Flotten als Arbeitsform: Dispatch & Review

Die einzelnen Case-Studys dieser Website zeigen Systeme. Dieser Text zeigt die Arbeitsform, mit der sie entstehen — denn die ist inzwischen selbst das interessanteste Artefakt: Ich arbeite nicht mit einem Assistenten, sondern mit einer Flotte. Und die Flotte darf nichts mergen, was nicht geprüft wurde.

Das Muster in einer Zeile

Backlog clustern → Flotte dispatchen → isoliert bauen lassen → adversarial reviewen → einzeln mergen → Strittiges eskalieren.

Als Diagramm, am Beispiel einer Kampagnen-Nacht:

                    Backlog (36 Befunde, ground-getruthed)
                                   │
                          Cluster-Zuschnitt (6 Themen)
                                   │
        ┌─────────┬─────────┬─────┴────┬─────────┬─────────┐
        ▼         ▼         ▼          ▼         ▼         ▼
     Agent 1   Agent 2   Agent 3    Agent 4   Agent 5   Agent 6
    worktree  worktree  worktree   worktree  worktree  worktree
    branch    branch    branch     branch    branch    branch
        │         │         │          │         │         │
        └─────────┴─────────┴────┬─────┴─────────┴─────────┘
                                 ▼
                  EIN Review über alle Branches
                  (Standards-Achse + Spec-Achse)
                                 │
                 ┌───────────────┴───────────────┐
                 ▼                               ▼
        6 einzelne Merges                NEEDS-DOMINIC-Liste
        (kein Auto-Merge)                (4 Entscheidungsvorlagen,
                                          Owner entscheidet morgens)

Drei Eigenschaften machen das Muster tragfähig:

Isolation ist nicht optional. Jeder Agent arbeitet in einem eigenen Git-Worktree auf einem eigenen Branch. Sechs Agenten parallel, null Merge-Konflikte untereinander — und ein missratener Lauf wird verworfen, statt das Repo zu verschmutzen.
Review ist eine eigene Instanz, nicht ein Nachsatz. Wer baut, urteilt nicht über sich selbst. Das Review läuft zentral über alle Branches, mit zwei getrennten Achsen: Hält der Code die dokumentierten Konventionen ein (Standards)? Und tut er, was der Auftrag verlangte (Spec)?
Unsicherheit wird geparkt, nicht geraten. Was eine Owner-Entscheidung braucht, landet als Entscheidungsvorlage in einer Liste — nicht still im Diff.

Beleg 1: die 6×6-Kampagnen-Nacht

Der Kampagnen-Report dokumentiert den Ablauf im Detail. Die Kurzfassung: 36 mechanische Audit-Befunde, sechs Agenten, sechs Branches, eine Review-Runde, sechs Merges in einer Nacht — 43 geänderte Dateien, vier geparkte Entscheidungsvorlagen, Testsuite grün. Inklusive des ehrlichen Teils: Der geplante Werkzeug-Unterbau (Codex-Subagenten) fiel an der Windows-Sandbox aus, die Mechanik lief unverändert mit Claude-Subagenten weiter. Die Arbeitsform ist werkzeugneutral.

Beleg 2: der Observatory-Build — 15 Agenten, zwei blinde Reviews

Die Live-Demo auf /observatory — ein Replay echter, vollständig sanitisierter Agenten-Telemetrie — entstand selbst über das Muster, diesmal mit Betonung auf der Review-Seite:

Die Design-Spec wurde adversarial geprüft, bevor eine Zeile Code entstand: zwei unabhängige Reviewer (ein Claude-Subagent und Codex), gleicher Prompt, blind gegeneinander. Beide fanden unabhängig denselben kritischen Blocker — die Content-Security-Policy der Site hätte die geplante Einbettung komplett verhindert, und die Sanitisierungs-Allowlist war von der falschen Quelle abgeleitet. Zwei blinde Reviews, die konvergieren, sind ein stärkeres Signal als jede Selbstprüfung.
Der Bau lief als Flotte von 15 Agenten (Verstehen → Bauen → Prüfen als getrennte Wellen), gefolgt von fünf Bug-Runden, in denen jede Behauptung live im Browser verifiziert wurde statt im Diff geglaubt.
Die Daten-Seite ist der Ernstfall des Musters: Kein String aus der echten Event-Datenbank wird unverändert ausgeliefert — der Export baut jedes Event aus einer Allowlist neu auf, statt Einzelfelder zu redigieren. Das war ein direktes Ergebnis der adversarialen Reviews.

Die Verdikt-Bilanz in Zahlen

Damit das nicht bei Erzählung bleibt — die Quoten der beiden Läufe, aus Run-Reports und Git-Log:

Lauf	Dispatcht	Akzeptiert & gemergt	Eskaliert / geparkt	Referenz
6×6-Kampagne	35 Befunde in 6 Clustern	6/6 Kampagnen-Branches (Merges `03d5391`…`848d8ff`)	4 NEEDS-DOMINIC-Vorlagen (umgesetzt als `e480e03`)	Run-Report 2026-07-01
Observatory-Build	1 Spec, 15 Bau-Agenten	Live-Embed (u. a. `340e6b8`) nach 5 Bug-Runden	2 blinde Spec-Reviews → 1 kritischer Blocker vor Baubeginn gefunden	Design-Spec 2026-06-30

Das Site-Repo ist privat — die Hashes stehen hier als überprüfbare Referenz für einen Walkthrough, nicht als Klick-Link.

Auch dieser Text entstand so

Kleinste Ausbaustufe desselben Musters, vom selben Tag: Der SEO-Batch dieser Website ging nach dem Bau durch einen Codex-Verifier (read-only, voller Diff plus Spec im Prompt). Verdikt: FAIL, genau ein Befund — ein fehlendes dateModified im Blog-Schema. Der Befund wurde gegen den Code ground-getruthed, per Test-first-Fix geschlossen, gepusht. Ein einzelnes ehrliches FAIL ist mehr wert als zehn freundliche PASS.

Was das Muster nicht ist

Kein Autopilot. Merges und strittige Entscheidungen bleiben beim Owner; die Flotte bereitet Entscheidungen vor, sie trifft sie nicht.
Keine Skalierungs-Show. 15 Agenten sind kein Ziel, sondern eine Zuschnittsfrage — der Verifier-Lauf oben war ein einzelner Agent, und das war richtig so.
Nicht selbstbewertend. Jede Zahl in diesem Text stammt aus Run-Reports, Git-Log oder Spec-Dokumenten im Repo — nicht aus der Erinnerung eines Agenten an die eigene Leistung.

Welchen Teil deines Backlogs würdest du einer Flotte geben — und welchen bewusst nicht? Wenn dich das Dispatch-Protokoll im Detail interessiert, schreib mir.