The five waves at a glance

▸MODULE 2 / THE WAVE LOGIC

In Module 1 you decided whether orchestration is worth it for your task at all: large, multi-step, decomposable into disjoint parts. If you said yes three times, the real work begins now, namely how the coordinator breaks this task into waves, distributes it, and puts it back together. That is exactly what this module builds up, station by station.

A deep session is not a heap of agents that all start running at once. It is an assembly line with five stations that are passed through in a fixed order. Each station has a role, each role has a clear assignment, and only once a station has delivered its result does the line move on to the next. This very order is the reason an orchestration works instead of ending in chaos. That the five-part form wins out in the vast majority of deep sessions (the exact shares with provenance are in Module 1, lesson "What orchestration actually solves", as of 2026-06) is no accident, but a pattern that established itself on its own, because these five roles split the work cleanly.

The coordinator orchestrates, it does not build itself

Before we talk about the waves, the most important sentence of this module: the coordinator orchestrates, it does not build itself. That is the orchestrator-worker pattern, which the Anthropic engineering blog also describes. (Source: Anthropic Engineering) The coordinator is the instance you have in front of you in the chat. It reads your assignment, breaks it into tasks, briefs subagents, gathers their results back in, and decides when the next wave may start. What it deliberately does not do: edit files itself while the agents are running.

That feels wrong at first. You have a capable coordinator in front of you, and it is supposed to keep its hands still? That is exactly the point. When the coordinator builds itself, it loses the overview of what the agents are doing right now, and it can no longer merge things cleanly. Its job is the overview, not the handwork. A good conductor does not play first violin at the same time.

This role logic is not tied to a single tool. As of June 2026, Codex describes similar building blocks with its own language: Subagents for parallel subtasks, Skills as reusable SKILL.md workflows, and Plugins as installable bundles of skills, app integrations, and MCP servers. (Codex Skills, Codex Plugins, Codex Subagents) The surface changes, the working contract stays: first understand, then build separately, then check, then merge in one hand.

The five roles as an assembly line

The five waves each have their own job, and they build on one another. Here is the assembly line from front to back:

Wave one, discovery. Read-only. Several agents read the code, map who does what, and deliver clean contracts for the building agents. They change nothing. Why first and why read-only? Because nobody should build anything before it is clear what is already there. Discovery is the blueprint before the first hammer blow.

Wave two, core implementation. This is where the actual logic comes into being. The building agents implement the main functions, each in its own file scope, on the basis of the contracts from discovery.

Wave three, implementation polish. What the core wave laid down gets connected and rounded off here: edges, special cases, the wiring of the parts to one another.

Wave four, quality. Tests, typecheck, lint. This wave checks whether what was built holds. It writes no new features, it inspects.

Wave five, finalization. Here the coordinator brings everything together and commits. And that is the second iron rule: the coordinator commits, never the agents. The agents deliver files, the version control stays in one hand. That way there are no half commits, no collisions in the history, one clean line.

Assigning a task to the right wave

The acid test: take any subtask of your project and ask yourself which wave it belongs to. "Understand how the existing login works" is discovery. "Build the new registration form" is core implementation. "Connect the form to the confirmation email" is polish. "Write tests for the registration" is quality. "Bring everything together and commit" is finalization. If you cannot place a task unambiguously, it is usually still too large and has to be broken down.

You can remember the structure of a wave as a fill-in list. You can hand it to your coordinator the same way:

Plan my task as five waves. Fill in for each wave:
Role: (Discovery / Core impl / Polish impl / Quality / Finalization)
What happens: (one sentence on what this wave concretely does)
Output: (what must be in place at the end of the wave before the next starts)
Discovery is read-only and comes first. The finalization commits,
not the individual agents. If a task fits into no wave,
it is too large: break it down before you go on.

This list is your scaffold for every session. It forces you to think it through to the end before the first agent, instead of noticing mid-run that the order is wrong.

Why the order is not negotiable

One could be tempted to skip waves. Leave out discovery, because you know the code anyway. Push quality to the back, because it feels faster. Both come back to bite you. Without discovery the core wave builds on guesses, and guesses about unfamiliar code are expensive. Without a separate quality wave, building and checking get mixed together, and an agent that inspects its own work is a weak inspector.

The order is therefore not a ritual, but a dependency chain: each wave needs the result of the previous one as clean ground. That is why the five-part form established itself on its own in more than four out of five deep sessions. It is not prescribed, it is what is left over when you split the work honestly.

The honest assessment

Five waves are a standard case, not an obligation. A small task may need two waves, a large one can have more agents per wave. The median was 10 agents, the range reached from 4 to 34, depending on the size of the task. The number of waves adapts to the work, not the other way around. What stays is the principle: first understand, then build, then check, then merge, and the coordinator keeps the overview instead of lending a hand itself. If you take only that with you, you have already understood the core of the wave logic, and the rest of this module just fills in the individual stations.

Sources

• Anthropic Engineering: How we built our multi-agent research system: orchestrator-worker pattern, coordinator orchestrates instead of building itself
• OpenAI Codex Skills: skills as reusable workflows with SKILL.md, optional scripts, references, and assets
• OpenAI Codex Plugins: plugins as distribution for skills, app integrations, and MCP servers
• OpenAI Codex Subagents: parallel subagent workflows and custom agents in Codex