The loop is three steps. The first step determines the quality of everything that follows. That's the part most teams skip.

Spec

The Spec stage is where the phase is defined. The Spec Owner writes the phase entry — what's in scope, what done looks like — and the Product Owner signs off. Then the Developer writes the Command: the file that encodes that intent in a form the agent can act on.

In our experience, nothing should start without both. Starting without a spec entry and a Command tends to mean the agent infers scope rather than acts on it. "I'll write it up after" and "we talked about it" are the two most common ways a phase loses its trace before it even starts.

The Command is the moment you find out if the ticket is actually clear.

If you can't write a Command that encodes the intent precisely, the ticket isn't ready. The friction you feel writing the Command is friction the agent would have felt trying to interpret an ambiguous scope. Better to hit it now.

Build

The Developer executes the Command. The agent builds within the scope defined in the Spec File. The Developer is in the session — not just to watch, but because they're accountable for everything the agent produces. If the agent goes out of scope, the Developer stops it. If something unexpected comes up that changes the scope, the Developer stops the session and updates the Spec File before continuing.

External agents may run during Build — test runners, spec divergence checkers, scaffolding scripts. These run autonomously. No human presence required. They report back into the session when they're done.

Build ends when the completeness criterion is met — that's the point of writing it down. "Feels about right" is harder to hand off.

After a phase closes with a clean Review, the Developer can immediately run the next phase's Command in the same session. A ticket with three phases can complete in one continuous sitting — the loop repeats until the ticket is done. The phase boundary exists to create a verifiable checkpoint, not to force a session break.

Review

The agent leads the Review. The Developer doesn't present what was built — the agent asks about it. That's a meaningful distinction. A presentation lets the developer cover what they know. Questions surface what they don't.

The agent asks until it has a clear picture of what the Developer understands and what they don't. For anything the Developer can't answer, the agent logs it as unresolved. The phase can still close — gaps don't block indefinitely. They get escalated.

What the agent checks

The Review has three purposes. First: verify the Developer understands what was built. Second: check for divergences between what was built and what the Spec File said would be built. Third: record both the understanding and the gaps as a Review Record in the Spec File.

The phase is not done until the Review Record is written. The Review Record is what closes the loop.

In practice

Here's a complete Review — the agent checking the Developer's understanding, surfacing a gap, and closing the phase.

The agent didn't surface any gaps the Developer couldn't answer. The known limitation was documented rather than escalated — the Developer understood it and could explain it. That's a clean close.

Not every Review is that clean. When gaps do surface, they get logged. The mechanism that handles them is the Escalation Ceremony — covered in Module 2.