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.
Der Workflow gliedert sich in drei Ebenen:
Alle Übergaben sind artifact-basiert — Worker kommunizieren über Dateien, nicht über geteilten Kontext.
Bevor irgendetwas geplant wird, verschafft sich W1 einen Überblick über die bestehende Codebasis: welche Teile zusammenhängen, wo die zentralen Bausteine liegen und was die Aufgabe berührt. Daraus entsteht eine geordnete Karte des Projekts, die nachfolgende Agenten leicht durchsuchen und Menschen nachlesen können. Die Planung setzt damit auf Fakten auf, nicht auf Vermutungen.
W2 übersetzt das Ziel auf Basis dieser Karte in eine verbindliche Spezifikation und zerlegt sie in klar umrissene Arbeitspakete mit prüfbaren Kriterien. Bei Änderungen an bestehender Arbeit ergänzt W2 nur das Nötige, statt alles neu zu schreiben. Die Spezifikation ist der Vertrag für alle folgenden Phasen — Widersprüche landen wieder hier, nicht beim Implementierer.
W3 setzt die Arbeitspakete um, mit einem internen Test-First-Loop: Ein Test-Agent leitet zuerst Tests aus den Kriterien ab, ein Coder-Agent implementiert, bis alle bestehen. Ist eine Anforderung nicht erfüllbar oder widersprüchlich, meldet W3 das, statt die Spezifikation eigenmächtig zu verbiegen. Zum Schluss hält W3 fest, was gebaut wurde, und übergibt an die Validierung.
W4 prüft das zusammengesetzte System gegen die ursprünglichen Akzeptanzkriterien, mit Smoke-, Integrations- und End-to-End-Tests. Am Ende steht ein klares Urteil: bestanden, nachbessern oder zurück an die Spezifikation. Nachbesserungen gehen an W3, höchstens dreimal; danach wird das Problem als Spezifikationsfrage an W2 eskaliert.
Zwischen den Workern gibt es keine losen Absprachen, sondern feste Übergabepunkte. Jede Rolle liefert ihr Ergebnis in einem vorab definierten, strukturierten Format ab, und der Dispatcher prüft an jedem Gate, ob es vollständig ist, bevor die nächste Phase startet. So weiß jeder Worker genau, was er bekommt und was er abliefern muss — und jede Übergabe bleibt im Nachhinein nachvollziehbar.
Vier Stellen, an denen Fehler abgefangen werden, bevor sie sich fortpflanzen:
Kein Worker liest die Implementierung eines anderen, kein Worker überschreibt Entscheidungen aus einer anderen Phase. Fehler bleiben dort, wo sie entstanden sind.
Ü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.
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.
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.