Working with a single agent produces something that looks finished. But knowing whether it is correct is harder. Over the past few weeks I have been designing a multi-agent workflow in Claude Code, building on the ideas in my previous post on how the team I led uses AI. An engineer’s most valuable contribution shifts: away from writing code, toward directing agents, reviewing their output, and deciding what their disagreements mean.
The problem with shared context Link to heading
When the same agent handles two related steps in the workflow, both outputs share the same context, the same assumptions, and the same blind spots. An agent that drafts a specification and then grounds it will verify what it already believes. An agent that implements a feature and then writes the unit tests will write tests that verify what it built, not what was specified.
The unit test case is the most familiar example of this. Unit tests are usually written by the same engineer who wrote the code, in the same session, with the implementation fresh in mind. When an AI agent does this, the problem is the same but sharper: if the agent resolved an ambiguity one way while implementing, the tests will reflect that resolution. They pass. The ambiguity goes unnoticed.
Multiple agents help when their work is genuinely independent: separate agents for separate roles, working from the same specification but without one another’s context, conclusions, or artifacts. A fresh agent dispatched from the specification alone, without access to the implementation, will interpret the acceptance criteria on its own terms. Where the two outputs disagree, the specification was ambiguous on that point. Where they agree on something the specification did not pin down, an assumption was smuggled in.
Independence has to be designed into the workflow, not requested in a prompt.
The working environment must prevent an agent from seeing another agent’s output by accident. Otherwise the agents can appear separate while quietly inheriting the same answer. You lose those signals when the same agent does both jobs, or when supposedly independent agents can see one another’s work.
This is the same principle as code review: a review by the person who wrote the code will still miss what they have not thought about.
Five roles, one specification Link to heading
The workflow has five roles. The first is different from the rest.
Orchestration is the agent the engineer works with directly, in a persistent session, throughout the work. It does not implement, ground, or test. Its role is to compile each specialist agent's work order from the specification, dispatch the agent, receive the output, and bring it back for the engineer to review. It is the interface between the engineer and the rest of the team.
The remaining four are specialist agents, each dispatched fresh with no knowledge of what the others produce:
Drafting turns a rough brief into a structured specification that every downstream agent will work from. The brief might be a finding from production, a requirement from a planning session, or a decision that needs implementing. This is a role in its own right, not a byproduct of the engineer's thinking. The Drafting agent will ask clarifying questions, surface what is still undecided, and produce a draft that makes the decisions explicit. The engineer reviews and owns it; the agent writes it. The result is a specification the implementer did not write.
Grounding establishes the premises a specification depends on before implementation begins. A fresh agent reads the specification and checks whether its premises are true. Does the dependency actually work the way the specification assumes? Does the integration behave as described? Does the external service have the constraint the specification treats as given? The Grounding agent reviews the engineer's work, not another agent's. It is the only one that does. An error it surfaces now costs a conversation; the same error surfaced after implementation costs a rewrite.
Implementation and Harness run simultaneously, dispatched from the same specification, with neither agent seeing what the other produces. The Implementation agent builds. The Harness agent compiles the acceptance criteria into an executable test suite independently. When their outputs disagree, the engineer adjudicates. The cause may be an ambiguous specification, a defect in the implementation, or a defect in the harness. The value of the split is not that it identifies the cause automatically. It makes the disagreement visible before it becomes a merged change. If the amendment changes a premise, Orchestration and the engineer re-triage before the next dispatch. If it is a clarification only, Implementation and Harness run again directly.
After the engineer approves the specification, Orchestration and the engineer triage it: does the work depend on assumptions about software, integrations, external services, or other facts outside the code being changed? If so, Grounding runs before implementation. If the criteria concern only behaviour in code the team controls, Implementation and Harness can proceed directly.
The discipline that matters most here is that Orchestration does not absorb a specialist role. If grounding needs to happen, it dispatches a fresh Grounding agent; it does not investigate itself. The independence of each specialist role is the mechanism that makes disagreements meaningful. An Orchestration agent that shortcuts by doing the work inline produces correct-looking results with the independence quietly removed, and nothing in the output records that it is missing.
Agreement is evidence, not proof.
Implementation and Harness can both faithfully compile the same omission from the specification. This is where Orchestration earns its place: before merging, it runs the checks that already exist against the candidate and confirms the harness can fail against the unchanged baseline and against a deliberately wrong version of the change. After merging, it runs them again. A green report from either agent is not verification.
The specification is everything downstream Link to heading
In practice, the disagreement is often a specification gap made visible. In one case, a specification that said the deployment should validate the configuration file produced two independent readings: Harness compiled a requirement that the deployment script must invoke the validator; Implementation built the check into the application’s startup path. Thirteen of fifteen tests failed when the outputs were compared. Neither agent had made an error. The specification had not said when validation should occur, and each agent had resolved that silence on its own terms. The engineer amended the specification; both ran again and agreed.
The most important shift this workflow creates is that the specification is the thing every agent works from. An error in it propagates into every artifact and is invisible to every downstream check.
This is what makes specification-writing the most consequential act in the process. Not implementation. Not test coverage. The specification.
A good specification requires engineering judgment to write: knowing what to pin down and what to leave flexible, knowing which assumptions need verification before any work begins, knowing what the specification does not say and what happens if an agent fills that gap on its own. Code that is wrong can be corrected in review.
A premise that is wrong contaminates everything built on top of it.
A specification is not perfect. It cannot settle a fact nobody knew to include, or replace the domain judgment needed to understand how a requirement applies in a particular system. Grounding checks the premises the specification states; it cannot identify every premise it omitted. That is why the engineer still reviews the specification, adjudicates the output, and asks what the workflow has not covered.
A specification that lives only in a session transcript is lost when the session ends. Committing it to the repository alongside the code it describes treats it as what it is: a versioned artifact with a history. When a premise is amended during adjudication, the amendment is committed. The code and the reasoning behind it evolve together, and the record of why a decision was made is recoverable later.
What the engineer does now Link to heading
The engineer’s role in a multi-agent workflow looks less like programming and more like managing a team.
Before any work begins: write the brief well enough to draft from. Review the draft critically. What did it decide that should have been left open? What did it leave open that will cause an agent to decide on your behalf? Decide everything that agents are not equipped to decide, and make those decisions explicit.
During the work: dispatch, do not investigate. Grounding investigates. Implementation builds. Harness checks. The engineer’s job is to read the results, adjudicate contradictions, and decide what a disagreement means.
After the work: verify mechanically rather than by reading what agents report about themselves. The checks tell you what passed. The agents’ prose tells you what they believe passed, which is a different thing.
The experience and judgment an engineer brings shape all three phases. The ability to write code is one small part of what a senior engineer knows. Domain knowledge, system-level intuition, the ability to see what a specification leaves uncovered: that is exactly what this workflow runs on.
What changes and what does not Link to heading
The before-and-after from the previous post still holds. Repetitive implementation work is handled by agents; engineers focus on what requires their judgment. Code review happens on every change. The workflow gives problems more chances to surface before code ships.
What multi-agent orchestration adds is a layer above that:
| Single-agent workflow | Multi-agent orchestration |
|---|---|
| One agent implements; the engineer reviews | Separate agents implement and verify independently; disagreements surface ambiguities and defects |
| Assumptions in the brief may not be checked | Grounding checks premises before implementation begins |
| Unit tests are written by the same agent that built the feature | Harness builds an independent test suite from the specification rather than the implementation |
| The engineer directs one agent at a time | The engineer manages a workflow in which multiple agents run in parallel |
| Work on one task blocks until the agent is done | Multiple tasks move through the pipeline simultaneously; the engineer moves between them as agents run |
The shift this creates is cumulative. Each role catches a different class of error. Each independent artifact narrows the gap between what was specified and what was built. The engineer’s contribution at each gate is smaller in volume and higher in consequence.
The pattern, plainly stated Link to heading
The engineer’s job in this model is to write specifications well, keep agents separated, and decide what their disagreements mean. Writing code is one output of that process, produced by an agent. The judgment behind what gets built, and whether it was built correctly, is the engineer’s.
That judgment compounds. An engineer who has shipped ten systems understands which assumptions are load-bearing, which edge cases matter, and which disagreements between agents reflect a real ambiguity versus a trivial one. That understanding is what the workflow runs on. It is not replaced by the agents. It is what makes the agents useful.