Parallele Codex-Workflows: So teilst du ein Feature auf mehrere Agenten auf

Parallel heißt nicht: fünf Agenten bekommen dieselbe Aufgabe

Parallele Codex-Workflows funktionieren, wenn jeder Agent einen klar getrennten Teil des Problems besitzt. Sie scheitern, wenn fünf Agenten dieselben Dateien anfassen, unterschiedliche Pläne erfinden und am Ende einen riesigen Merge-Konflikt liefern.

Das Ziel: ein Feature in sichere Workstreams zerlegen, Codex auf getrennten VPS-Agenten laufen lassen und erst nach Tests und Review zusammenführen. Office Claws hilft dabei, weil jeder Agent eigenen Host, Branch, Terminalzustand und einen sichtbaren Platz in der Desktop-App hat. Die Produktentscheidungen bleiben bei dir; die Agenten übernehmen Warten, Testen und mechanische Änderungen.

Die Regel: nach Schnittstellen teilen, nicht nach Wunschlisten

Ein schwacher Split klingt so:

• Agent A: Feature implementieren
• Agent B: Tests schreiben
• Agent C: Doku aktualisieren

Das wirkt parallel, aber Agent B kennt die Schnittstelle noch nicht und Agent C dokumentiert Verhalten, das sich gleich ändert.

Besser ist ein Split entlang technischer Grenzen:

• Agent A: Migration und Repository-Schicht
• Agent B: API-Route und Validierung
• Agent C: UI-State für leer, lädt und Fehler
• Agent D: Doku und Release Note, sobald die Schnittstelle stabil ist

Wenn zwei Agenten dieselbe Datei brauchen, ist der Schnitt wahrscheinlich falsch.

Ein praktischer Vier-Branch-Ablauf

1. Erst einen Vertrag schreiben

Vor dem Start steht ein kurzer Vertrag im Hauptbranch: Typen, Endpoint-Form, Dateinamen und Testbefehl.

Endpoint: POST /api/runs/:id/retry
Request: { mode: "failed-only" | "all" }
Response: { runId: string, queuedTasks: number }
Tests: npm run test -- retry
Bestehende RunStatus-Werte nicht umbenennen.

Langweilig, aber genau das trennt Parallelität von Chaos.

2. Ein Branch pro Agent

Benutze Namen nach Zuständigkeit:

• feat/retry-runs-api
• feat/retry-runs-ui
• feat/retry-runs-tests
• docs/retry-runs-release-note

In Office Claws läuft jeder Codex-Agent auf eigenem VPS und Branch. Fehlgeschlagene Experimente bleiben dort, wo sie entstanden sind.

3. Enge Prompts schreiben

Du besitzt nur API-Route und Validierung für Retry Runs.
Keine UI-Dateien ändern. Keine shared status enums umbenennen.
Vor Abschluss ausführen: npm run test -- retry
Gib Zusammenfassung, geänderte Dateien und nötige Vertragsänderungen zurück.

Die Verbote sind Merge-Konflikt-Prävention.

Die Merge-Reihenfolge ist wichtig

Merge zuerst die Grundlage: Datenmodell, dann API, dann UI, dann Doku. Nach jedem Merge werden die übrigen Branches rebased, damit alle Agenten den aktuellen Vertrag sehen.

1. Repository- oder Datenbank-Branch nach grünen Tests mergen
2. API-Branch rebasen, Drift beheben, mergen
3. UI-Branch rebasen und an den echten Endpoint anschließen
4. Tests und Doku zuletzt abschließen

Warte nicht mit allem bis zum Ende. Das versteckt Designänderungen.

Wann sich parallele Codex-Workflows lohnen

Sie helfen bei natürlichen Grenzen:

• Backend + Frontend + Doku
• Migration + Adapter + Tests
• Ein Package refactoren, während ein anderer Agent Call Sites aktualisiert
• Drei Fix-Ideen untersuchen und nur die beste behalten
• Dasselbe Muster auf mehrere unabhängige Integrationen portieren

Für einen 20-Zeilen-Bugfix ist ein einzelner Codex-Lauf schneller.

Wo Office Claws passt

Man kann das mit SSH-Tabs und tmux bauen. Schwierig ist, im Kopf zu behalten, welche Maschine, welcher Branch und welches Terminal welchen Teil besitzt. Office Claws ist die Kontrollfläche dafür: mehrere Codex-Agenten auf VPSs, sichtbar in einer Desktop-App.

Wenn du aus der OpenClaw-Welt kommst, lies zuerst den OpenClaw-vs-Codex-Vergleich. Wenn du direkt Codex-Agenten betreiben willst, zeigt die Preisseite die Self-Hosted- und Managed-Optionen.

Checkliste

• Gibt es einen schriftlichen Vertrag?
• Besitzt jeder Agent andere Dateien?
• Sagt jeder Prompt klar, was verboten ist?
• Gibt es einen Validierungsbefehl pro Branch?
• Steht die Merge-Reihenfolge fest?
• Akzeptiert ein Mensch Vertragsänderungen?

Parallele Codex-Workflows sind stark, weil Agenten eng bleiben. Sie sollen keine autonomen Manager werden; sie sollen nicht aufeinander warten, während du die Architektur behältst.