Die fünf Wellen im Überblick

▸MODUL 2 / DIE WELLEN-LOGIK

In Modul 1 hast du entschieden, ob sich Orchestrierung für deine Aufgabe überhaupt lohnt: groß, mehrstufig, in disjunkte Teile zerlegbar. Sagst du dreimal Ja, beginnt jetzt die eigentliche Arbeit, nämlich wie der Koordinator diese Aufgabe in Wellen zerlegt, verteilt und wieder zusammensetzt. Genau das baut dieses Modul Station für Station auf.

Eine Deep-Session ist kein Haufen Agenten, die gleichzeitig losrennen. Sie ist ein Fließband mit fünf Stationen, die in einer festen Reihenfolge durchlaufen werden. Jede Station hat eine Rolle, jede Rolle hat einen klaren Auftrag, und erst wenn eine Station ihr Ergebnis abgeliefert hat, läuft das Band weiter zur nächsten. Genau diese Ordnung ist der Grund, warum eine Orchestrierung funktioniert und nicht im Chaos endet. Dass sich die Fünferform in den allermeisten Deep-Sessions durchsetzt (die genauen Anteile mit Beleg stehen in Modul 1, Lesson „Was Orchestrierung wirklich löst", Stand 2026-06), ist kein Zufall, sondern ein Muster, das sich von selbst eingestellt hat, weil diese fünf Rollen die Arbeit sauber teilen.

Der Koordinator orchestriert, er baut nicht selbst

Bevor wir über die Wellen reden, der wichtigste Satz dieses Moduls: Der Koordinator orchestriert, er baut nicht selbst. Das ist das Orchestrator-Worker-Pattern, das auch der Anthropic-Engineering-Blog beschreibt. (Quelle: Anthropic Engineering) Der Koordinator ist die Instanz, die du im Chat vor dir hast. Er liest deinen Auftrag, zerlegt ihn in Aufgaben, beauftragt Subagenten, sammelt deren Ergebnisse ein und entscheidet, wann die nächste Welle starten darf. Was er bewusst nicht tut: selbst Dateien editieren, während die Agenten laufen.

Das fühlt sich am Anfang falsch an. Du hast einen fähigen Koordinator vor dir, und der soll die Hände stillhalten? Genau das ist der Punkt. Wenn der Koordinator selbst baut, verliert er den Überblick über das, was die Agenten gerade tun, und er kann nicht mehr sauber zusammenführen. Seine Aufgabe ist die Übersicht, nicht die Handarbeit. Ein guter Dirigent spielt nicht gleichzeitig die erste Geige.

Diese Rollenlogik ist nicht an ein einzelnes Werkzeug gebunden. Stand Juni 2026 beschreibt Codex ähnliche Bausteine mit eigener Sprache: Subagents für parallele Teilaufträge, Skills als wiederverwendbare SKILL.md-Workflows und Plugins als installierbare Bündel aus Skills, App-Integrationen und MCP-Servern. (Codex Skills, Codex Plugins, Codex Subagents) Die Oberfläche ändert sich, der Arbeitsvertrag bleibt: erst verstehen, dann getrennt bauen, dann prüfen, dann in einer Hand zusammenführen.

Die fünf Rollen als Fließband

Die fünf Wellen haben jeweils eine eigene Aufgabe, und sie bauen aufeinander auf. Hier ist das Fließband von vorne nach hinten:

Welle eins, Discovery. Read-only. Mehrere Agenten lesen den Code, kartieren, wer was tut, und liefern saubere Verträge für die Bau-Agenten. Sie verändern nichts. Warum zuerst und warum read-only? Weil niemand etwas bauen sollte, bevor klar ist, was schon da ist. Discovery ist der Bauplan vor dem ersten Hammerschlag.

Welle zwei, Implementierung Kern. Hier entsteht die eigentliche Logik. Die Bau-Agenten setzen die Hauptfunktionen um, jeder in seinem eigenen Dateibereich, auf Basis der Verträge aus der Discovery.

Welle drei, Implementierung Feinschliff. Was die Kern-Welle gelegt hat, wird hier angeschlossen und abgerundet: Ränder, Spezialfälle, das Verdrahten der Teile miteinander.

Welle vier, Qualität. Tests, Typecheck, Lint. Diese Welle prüft, ob das Gebaute hält. Sie schreibt keine neuen Features, sie kontrolliert.

Welle fünf, Finalisierung. Hier führt der Koordinator alles zusammen und committet. Und das ist die zweite eiserne Regel: Der Koordinator committet, nie die Agenten. Die Agenten liefern Dateien ab, die Versionsverwaltung bleibt in einer Hand. So gibt es keine halben Commits, keine Kollisionen in der Historie, eine saubere Linie.

Eine Aufgabe der richtigen Welle zuordnen

Die Probe aufs Exempel: Nimm irgendeine Teilaufgabe deines Projekts und frag dich, in welche Welle sie gehört. „Verstehe, wie das bestehende Login funktioniert" ist Discovery. „Baue die neue Registrierungs-Maske" ist Implementierung Kern. „Verbinde die Maske mit der Bestätigungs-Mail" ist Feinschliff. „Schreibe Tests für die Registrierung" ist Qualität. „Führe alles zusammen und committe" ist Finalisierung. Wenn du eine Aufgabe nicht eindeutig einordnen kannst, ist sie meist noch zu groß und muss zerlegt werden.

Den Aufbau einer Welle kannst du dir als ausfüllbare Liste merken. Genau so kannst du es auch deinem Koordinator vorgeben:

Plane meine Aufgabe als fünf Wellen. Fülle für jede Welle aus:
Rolle: (Discovery / Impl-Kern / Impl-Feinschliff / Qualität / Finalisierung)
Was passiert: (ein Satz, was diese Welle konkret tut)
Output: (was am Ende der Welle vorliegen muss, bevor die nächste startet)
Discovery ist read-only und kommt zuerst. Die Finalisierung committet,
nicht die einzelnen Agenten. Wenn eine Aufgabe in keine Welle passt,
ist sie zu groß: zerlege sie, bevor du weitermachst.

Diese Liste ist dein Gerüst für jede Session. Sie zwingt dich, vor dem ersten Agenten zu Ende zu denken, statt mittendrin zu merken, dass die Reihenfolge nicht stimmt.

Warum die Reihenfolge nicht verhandelbar ist

Man könnte versucht sein, Wellen zu überspringen. Discovery weglassen, weil man den Code ja kennt. Qualität nach hinten schieben, weil es schneller wirkt. Beides rächt sich. Ohne Discovery baut die Kern-Welle auf Vermutungen, und Vermutungen über fremden Code sind teuer. Ohne eine eigene Qualitäts-Welle vermischt sich Bauen und Prüfen, und ein Agent, der seine eigene Arbeit kontrolliert, ist ein schwacher Prüfer.

Die Reihenfolge ist also kein Ritual, sondern eine Abhängigkeitskette: Jede Welle braucht das Ergebnis der vorigen als sauberen Boden. Deshalb hat sich die Fünferform in mehr als vier von fünf Deep-Sessions von selbst durchgesetzt. Sie ist nicht vorgeschrieben, sie ist das, was übrig bleibt, wenn man die Arbeit ehrlich teilt.

Die ehrliche Einordnung

Fünf Wellen sind ein Standardfall, keine Pflicht. Eine kleine Aufgabe braucht vielleicht zwei Wellen, eine große kann mehr Agenten pro Welle haben. Der Median lag bei 10 Agenten, die Spanne reichte von 4 bis 34, je nach Größe der Aufgabe. Die Zahl der Wellen passt sich der Arbeit an, nicht umgekehrt. Was bleibt, ist das Prinzip: erst verstehen, dann bauen, dann prüfen, dann zusammenführen, und der Koordinator hält dabei die Übersicht statt selbst Hand anzulegen. Wenn du nur das mitnimmst, hast du den Kern der Wellen-Logik schon verstanden, und der Rest dieses Moduls füllt nur noch die einzelnen Stationen aus.

Quellen

• Anthropic Engineering: How we built our multi-agent research system: Orchestrator-Worker-Pattern, Koordinator orchestriert statt selbst zu bauen
• OpenAI Codex Skills: Skills als wiederverwendbare Workflows mit SKILL.md, optionalen Scripts, References und Assets
• OpenAI Codex Plugins: Plugins als Distribution für Skills, App-Integrationen und MCP-Server
• OpenAI Codex Subagents: Parallele Subagent-Workflows und Custom Agents in Codex