The Orchestrator: CI/CD Thinking Applied to AI Agents
In the last article of this series I described a harness as the environment an agent operates in — instructions, Skills, MCPs, hooks, permissions, tests, human review gates, all working together instead of loose, one-off interactions.
But a harness answers what an agent knows and what it's allowed to touch. It doesn't answer a different question: in what order does the work happen, and who's responsible for which part of it?
That's the piece I want to add now: orchestration.
One agent doing everything is grading its own work
I've run sessions where a single agent, in a single context, interpreted an ambiguous request, decided what "done" meant, wrote the code, and then told me it was done — all without a single independent check in between.
When the spec was ambiguous, it filled the gap with its own assumption instead of flagging it. When the implementation was finished, the same agent that wrote it was also the one judging whether it met the (assumed) requirements. A second opinion was never forced, because there wasn't a second anything — just one continuous stream of decisions with no seam where I could intervene.
That's not a model problem. It's a structure problem. Ask any engineer to write a feature, define what "done" means, and sign off on their own PR, all with nobody checking anything in between, and you already know how that goes.
This pattern already has a name: CI/CD
Nobody would trust a single script called ship_it.sh that builds, tests, and deploys with no gates in between. That's exactly why CI/CD pipelines exist:
Pull branch/tag
↓
Build
↓
Run unit tests
↓
Run integration tests
↓
Generate version
↓
Deploy
Every step has one job. Every step can fail independently. Nothing skips ahead just because the previous step "seemed fine."
An agent workflow can be structured the same way:
Read request
↓
Refine spec
↓
Human approval
↓
Implement changes
↓
Run checks
↓
Verify output
↓
Human approval
↓
Deliver
This isn't a metaphor I'm stretching to sound clever. It's the same underlying problem: work that's too important to trust to a single unchecked pass benefits from being split into stages, each with a clear responsibility and a clear exit condition.
Three roles, three agents
Once the pipeline exists, the roles inside it become obvious:
- Refiner Agent — reads the original request and turns it into a clear spec: dependencies, edge cases, constraints, acceptance criteria. Its only job is to remove ambiguity, not to write code.
- Implementation Agent — builds the solution against that spec. It respects the architecture, conventions, and technical limits already defined in the harness. It doesn't get to decide what the requirements are — that decision already happened.
- Verification Agent — reviews the output against the spec, runs or proposes checks, and looks specifically for risk, technical debt, edge cases, and regressions. It has no stake in the implementation being "good"; its only job is to find out if it actually is.
None of these needs to be a smarter model than the others. The value isn't in intelligence, it's in not letting the same pass of work ask the question, answer it, and grade the answer.
The orchestrator is the router, not a fourth brain
It's tempting to think the orchestrator is the "smart" piece that ties everything together. It isn't, and treating it that way defeats the point.
The orchestrator's job is mechanical: decide the order of execution, pass the right output from one agent as input to the next, define the condition that has to be true before a step is allowed to start, and stop the pipeline at the points where a human needs to look at it.
If the orchestrator starts making judgment calls about the actual work — deciding whether an implementation is good enough, for instance — you've just recreated the single-agent problem with extra steps.
Human approval gates: where the pipeline pauses on purpose
The two gates that matter most are the ones right after the spec and right after verification.
Approving the spec before implementation starts means disagreements get caught while they're still cheap — a sentence to edit, not a pull request to rewrite. Approving the verification before calling something delivered means the last word on "is this actually done" belongs to a person, not to the agent that built it.
This is exactly the trade-off I care about: keeping the speed of the pipeline without losing technical control over the two moments that matter most.
Why this doesn't all belong in one CLAUDE.md
There's a temptation, once you have a good harness, to just put everything in one instructions file and let a single agent read all of it for every task.
But a Refiner doesn't need implementation-level architecture details, and an Implementation Agent doesn't need to see how verification scores technical debt. Stuffing all of it into one shared context doesn't make the agent smarter — it just makes it slower to find the parts that actually matter for the step it's on.
Orchestration is also a scoping decision: each agent gets the slice of the harness relevant to its role, not the whole thing by default.
Conclusion
A harness defines the environment an agent works in. An orchestrator defines the sequence that environment gets used in, and where a human has to sign off before the next step starts.
Neither one replaces judgment. Both exist to make sure judgment — yours, and the agent's — gets applied at the right moment instead of all at once, or not at all.
In the next article of this series I'll get specific about what actually goes into that first gate: Spec-Driven Development: Let AI Write the Code, Not the Requirements — and why the Refiner step is the one most teams skip first, and pay for last.
Until then, the question worth asking isn't:
Did the agent finish the task?
It's:
Which step actually took charge of checking that it was the right task, done the right way?
If you're running something like this — even informally — I'd like to hear how you split the roles. Feel free to reach out.