Agent orchestration works when the senior engineer stays responsible for the system shape.
Agents are strongest when they receive narrow missions with clear acceptance criteria. They are weakest when asked to invent product direction, own ambiguous architecture, or reconcile competing business constraints without context.
The useful pattern is simple: frame the work, split the surface area, review the returns, and integrate deliberately.
What follows is the specific shape that takes — six patterns that hold up under real delivery pressure, and four that look sophisticated and quietly cost you more than they save.
The Constraint Everything Follows From
One engineer can review roughly as much code as one engineer could ever review.
This is the binding constraint of agentic delivery and it is easy to miss, because generation capacity is effectively unlimited. You can produce ten thousand lines in an afternoon. You cannot understand ten thousand lines in an afternoon, and unreviewed code is not an asset.
Every pattern below is a strategy for keeping generated volume inside the review budget — either by making the output smaller, by making it more predictable, or by making it verifiable without line-by-line reading.
Orchestration is not about maximising throughput. It is about maximising the amount of reviewed, correct work per unit of human attention.
Pattern 1: The Vertical Slice
Give one agent a complete thin path through the system rather than a horizontal layer.
Not “build the API endpoints” and separately “build the UI.” Instead: “make it possible for an admin to deactivate a user — route, handler, permission check, database change, UI control, test.”
This works because the agent holds the full context of one coherent behaviour. Integration issues surface inside its work rather than between separate agents’ work. And the result is reviewable as a story: does this correctly implement deactivating a user? That is a question a person can answer.
Horizontal splits are the intuitive decomposition and they generate the most integration pain. The frontend agent assumes a response shape the backend agent did not build.
Use when: the feature decomposes into independent user-visible behaviours. Which is most of the time.
Pattern 2: Spec-First Fan-Out
Write the contract yourself, then parallelise against it.
The engineer defines the interface — types, schema, API shape, error cases — as an actual artefact in the repo. Multiple agents then work simultaneously against that fixed contract.
The contract is the thing that makes parallelism safe. Without it, agents make locally reasonable and mutually incompatible assumptions, and you pay for it at integration. With it, the interface is not up for negotiation and the work genuinely composes.
This is the pattern that most resembles managing a team, and it has the same prerequisite: the interface has to be right, because it is expensive to change once several workstreams depend on it. That is engineer work, not agent work.
Use when: several substantial pieces must interoperate and the boundary between them is clear.
flowchart TD
A[Engineer writes contract:<br/>types, schema, errors] --> B[Agent: service layer]
A --> C[Agent: persistence]
A --> D[Agent: client]
A --> E[Agent: test fixtures]
B --> F[Engineer integrates<br/>and reviews]
C --> F
D --> F
E --> F
F --> G{Contract held?}
G -->|No| A
G -->|Yes| H[Merge]Pattern 3: The Reference Implementation
Build the first one by hand. Have agents build the next nine.
When a task repeats with variation — twelve API resources following the same shape, thirty components with the same structure, a migration applied across many modules — the engineer implements one carefully. That implementation becomes the specification.
The instruction then becomes “do this, for that,” which is the narrowest possible mission and the easiest possible review. You are checking conformance to a known-good example rather than evaluating novel design.
The failure mode is starting the fan-out before the reference is genuinely settled. If the pattern changes at item three, you have nine things to redo.
Use when: the work is repetitive with structural variation. This is a large fraction of enterprise delivery.
Pattern 4: The Adversarial Pair
One agent implements. A second agent, with no visibility into the first’s reasoning, tries to break it.
The second agent gets the specification and the resulting code, and is asked to find where it fails: edge cases, unhandled errors, race conditions, security holes, spec violations.
This works because the failure modes are uncorrelated in a useful way. An agent that misunderstands a requirement will write code and tests that share the misunderstanding — its tests will pass. A separate agent reading only the spec does not inherit that error.
It does not replace human review. It filters, so the engineer’s attention lands on substantive design questions rather than on the class of bug a careful second reader would catch.
Use when: the code is security-sensitive, has complex edge cases, or the cost of a defect is high.
Pattern 5: The Blast Radius Box
Constrain what an agent can touch before you constrain what it should do.
Every mission specifies its boundary explicitly: these files, this module, no schema changes, no new dependencies, no changes to the public interface.
This is less about trust than about review economics. A change confined to a known boundary can be reviewed by reasoning about that boundary. A change that touches thirty files across six modules requires reconstructing the whole system in your head.
The box also makes damage recoverable. A bad change inside one module is a revert. A bad change that quietly altered a shared utility is an investigation.
Use when: always. This one is not situational.
Pattern 6: Integration Last, And By Hand
The engineer does the joining.
Agents produce components. Wiring them together — resolving the interface mismatches, deciding what the error propagation actually does, choosing where the transaction boundary sits — is where the system’s real behaviour is decided, and it is the step that most rewards holding the whole thing in one head.
It is tempting to hand integration to an agent too, since it is fiddly and unglamorous. The result is usually code that compiles and runs and encodes decisions nobody made deliberately.
Use when: always, for anything that will be maintained.
The Anti-Patterns
These look like sophisticated orchestration. They are how teams lose the gains.
Agent as architect. Asking an agent to design the system, then implementing its design. You get something plausible, conventional, and unmoored from the constraints that actually matter — the team’s operational maturity, the migration you are mid-way through, the regulator. Architecture is a judgment about consequences.
The telephone chain. Agent A’s output becomes agent B’s input becomes agent C’s input, with no human between them. Small misunderstandings compound. By the third hop you are reviewing something whose relationship to your intent is unclear, and diagnosing where it went wrong costs more than starting over.
Unbounded autonomy on a vague goal. “Improve the performance of the checkout flow.” You will receive a large diff touching many files, mixing genuine improvements with speculative changes and at least one thing that breaks a behaviour nobody tested. The diff is too large to review properly, so it gets skimmed, and skimmed code is unreviewed code with extra steps.
Review theater. Approving diffs at a rate that is not physically compatible with reading them. This is the most dangerous one, because it is invisible from the outside and produces excellent velocity metrics right up until the incident. If the review budget is the constraint, the honest response is to generate less, not to review faster.
flowchart LR
A[Generation capacity:<br/>effectively unlimited] --> B[Review capacity:<br/>fixed and human]
B --> C{Volume exceeds<br/>review budget?}
C -->|Yes| D[Review theater]
C -->|No| E[Reviewed, correct work]
D --> F[Velocity metrics look great]
D --> G[Defects accumulate silently]How To Tell It Is Working
Two signals, watched together.
Review time per change stays flat or falls. If it is climbing, the missions are too broad. Narrow them.
The engineer can still explain any part of the system from memory. This is the real test. If someone asks why the retry logic works the way it does and the answer is “let me look” — the fleet has outrun its orchestrator, and the accountability that justifies the whole model has quietly evaporated.
When that happens the fix is not more agents or better prompts. It is smaller scopes.
The Bottom Line
The patterns that work share one property: they keep the amount of code needing human understanding inside what a human can actually understand.
Vertical slices over horizontal layers. Contracts before parallelism. A reference implementation before a fan-out. An adversarial reader on anything that matters. A hard boundary on every mission. Integration by hand.
The anti-patterns share the opposite property. They all increase generated volume faster than they increase reviewed volume, and the gap is where defects live.
One mind, a fleet underneath. The mind is the constraint, and designing around it honestly is the whole discipline.