Refiner, Implementer, Verifier: A Practical Multi-Agent Workflow
In the last article of this series I described a spec as the contract that should exist before an agent writes a single line of code. What I didn't cover is how to actually run the three roles that use that contract — Refiner, Implementer, Verifier — as something more than three good intentions you try to hold in your head during one long session.
Labeling sections of one prompt isn't the same as separating roles
For a while, I ran all three roles inside a single conversation: "refine this into a spec, then implement it, then verify it." Same context window, same continuous thread, just three headers in one long prompt.
It didn't work the way I expected. The refine step rushed — the model clearly wanted to get to the part where it wrote code, so it treated the spec as a formality instead of properly reasoning through the request. And the verification step, run right after the same agent had just finished implementing, was suspiciously agreeable. It had every incentive, structurally, to conclude its own work was fine.
The fix wasn't better wording. It was giving each role its own separate context — a fresh subagent invocation, not a new paragraph in the same conversation. The moment the Refiner had no idea what the implementation would eventually look like, and the Verifier had no memory of how hard the implementation had been, both got noticeably more honest.
Refiner Agent: only reads and writes the spec
The Refiner gets the original request and whatever project context it needs to understand what's being asked for — not how it'll be built. Its only output is the spec described in the last article: goal, acceptance criteria, edge cases, dependencies, constraints, out of scope.
What it should never do is quietly propose an implementation approach. "I'll use a repository pattern here" is not the Refiner's call to make. If the request is genuinely ambiguous — two valid readings, no way to tell which one is meant — its job is to say so explicitly, not pick the more plausible one and move on.
This is exactly why the human approval gate belongs right after this step: catching an ambiguity here costs a sentence. Catching it three steps later costs a rewrite.
Implementation Agent: reads the spec, never rewrites it
Once a spec is approved, the Implementation Agent gets it along with the harness — the AGENTS.md, the relevant skills, the architecture and permissions already in place. Its job is to build exactly what's specified.
If the spec looks wrong or incomplete once implementation starts — which happens — the right move isn't to quietly reinterpret it and keep going. It's to stop and flag it back. An Implementation Agent that "helpfully" expands scope or fills a gap in the spec on its own has just recreated the exact problem Spec-Driven Development exists to prevent, one level downstream.
Verification Agent: never trusts the Implementation Agent's own account
This is the role where separate context matters most. The Verifier gets the spec and the actual diff — not the Implementation Agent's summary of what it did, not its explanation of why a shortcut was fine.
It checks the output against each acceptance criterion individually, runs or proposes the tests that matter, and looks specifically for risk, technical debt, and edge cases the spec called out. It has no memory of how difficult the task was, no stake in the implementation being good — which is exactly what makes it useful. An agent that remembers writing the code has already decided, on some level, that the code is fine.
Keeping the roles from bleeding into each other
The three failure patterns I run into most:
- The Refiner sneaking in implementation opinions instead of staying scoped to what's being asked.
- The Implementation Agent silently "fixing" or narrowing the spec's edge case list instead of flagging the mismatch.
- The Verifier going easy because it has context on how hard the work was — which it shouldn't have in the first place.
None of these get fixed by asking more politely. They get fixed by scoping each agent's context to only what its role needs, and writing explicit boundaries — not just what each role should do, but what it's not allowed to decide.
You don't need all three every time
These roles are useful standalone, not just as pipeline stages.
Sometimes I run just the Refiner — to turn a messy, half-formed idea into something reviewable before I hand it to anyone, human or agent. Sometimes I run just the Verifier — to audit existing code nobody fully trusts, without touching a single line of it. Neither needs the other two to be worth running.
Conclusion
A harness defines the environment. An orchestrator defines the sequence. This is the part that actually does the work inside each stage — and it only holds up if each role has its own context, its own boundaries, and no access to the shortcuts the others took.
In the next article of this series I'll focus on the piece that ties all of this together: Human-in-the-Loop AI Development — when to let the pipeline run on its own, when to insist on stopping it, and how to tell the difference before it costs you something.
Until then, the question worth asking about your own setup isn't:
Do I have a Refiner, an Implementer, and a Verifier?
It's:
Does any of them still know things it shouldn't?
If you're running something like this, I'd like to know where the boundaries between your agents actually leak — feel free to reach out.