Deep Dive
Der Atomic Orchestrator Workflow
Der Atomic Orchestrator ist eine Multi-Agent-Pipeline mit vier spezialisierten Worker-Rollen, die jeweils eine klar abgegrenzte Phase übernehmen. Übergaben zwischen Phasen sind gate-gesichert und artifact-basiert — kein Worker interpretiert den Gesamtzustand selbst.
Das Prinzip
Der Workflow gliedert sich in drei Ebenen:
- Dispatcher — steuert den Ablauf und prüft Gates. Schreibt keinen Code, trifft keine inhaltlichen Entscheidungen.
- Worker-Ebene — vier spezialisierte Rollen (Exploration, Spezifikation, Implementierung, Validierung), jede mit einem klar abgegrenzten Zuständigkeitsbereich.
- Sub-Agent-Loops — innerhalb von W3: ein Test-Agent schreibt zuerst fehlschlagende Tests, ein Coder-Agent implementiert, bis sie bestehen.
Alle Übergaben sind artifact-basiert — Worker kommunizieren über Dateien, nicht über geteilten Kontext.
W1 — Exploration Agent
W1 kartiert die Codebasis, bevor eine Spec geschrieben wird.
- Traversiert Dateiabhängigkeiten und identifiziert zentrale Symbole
- Baut einen maschinenlesbaren Codegraphen (
graph.json) - Erstellt eine menschenlesbare Zusammenfassung (
GRAPH_REPORT.md) - Gibt W2 eine geordnete Karte statt einer rohen Dateiablage
W2 — Spec & Task Architect
W2 liest die Exploration-Artefakte und übersetzt das Ziel in eine verbindliche Spezifikation.
- Erstellt ein vollständiges BUILD_SPEC bei neuer Arbeit
- Im PATCH_MODE: nur Delta-TaskCharters, kein Neu-Schreiben des bestehenden Specs
- Die Spezifikation ist der Vertrag — W3 kann sie nicht einseitig ändern
- Widersprüche werden als Eskalation zurück an W2 gemeldet
W3 — Implementation Worker
W3 implementiert gegen die Spezifikation — mit einem internen TDD-Loop.
- Test-Agent schreibt zuerst fehlschlagende Testfälle basierend auf den TaskCharter-Kriterien
- Coder-Agent implementiert, bis alle Tests bestehen
- Erstellt ImplementationReport.md und HANDOVER.md für W4
- Eskaliert an den Dispatcher, wenn Anforderungen nicht erfüllbar oder widersprüchlich sind
W4 — Integration & System Testing
W4 testet das zusammengesetzte System gegen die ursprünglichen Akzeptanzkriterien.
- Führt Smoke-Tests, Integrations- und End-to-End-Checks durch
- Gibt eines von drei Verdikten zurück: VALIDATION_PASS, FIXES_REQUIRED oder ESCALATE_TO_WORKER2
- Bei FIXES_REQUIRED: Arbeit geht zurück an W3 — maximal drei Zyklen
- Nach drei Rückläufen erzwingt die Pipeline eine Eskalation an W2
Warum es funktioniert
Rollenisolation verhindert Fehlerakkumulation. Kein Worker liest die Implementierung eines anderen, kein Worker überschreibt Entscheidungen aus einer anderen Phase. Fehler bleiben dort, wo sie entstanden sind.
Artifact-basierte Übergaben ersetzen geteilten Kontext. Übergaben über Dateien sind explizit, inspizierbar und versionierbar. Kein Agent trägt die vollständige Projektgeschichte in sein Kontextfenster — das reduziert Token-Verbrauch und begrenzt Drift.
Knowledge Capture läuft kontinuierlich im Hintergrund. Ein separater KC-Agent protokolliert Learnings während W3 und W4 arbeiten — nicht erst in einer Nachbetrachtung. Das System wird über Runs hinweg besser, ohne die Hauptpipeline zu belasten.
Der Zyklendeckel erzwingt Klarheit statt Endlosschleife. Drei Fix-Zyklen reichen für echte Implementierungsfehler. Übersteigt ein Problem diese Grenze, ist es ein Spezifikationsproblem — die Pipeline erzwingt dann Eskalation statt weiterer Iteration.