Eight agents, three human gates, one delivery loop
The full version of how the machine works, including the failure paths. Written to be forwarded to the colleague who thinks this sounds like a bad idea.
Specialisation is the point
One general-purpose agent asked to build a feature end to end does every job adequately and none of them well. It reviews its own work, which is worth roughly what you'd expect, and it has no reason to be sceptical about code it just wrote.
Splitting the work changes that. The agent reviewing a change didn't produce it and isn't invested in it. The agent testing the feature interacts with the running software rather than reading the diff. Each one gets a narrow job, a defined input and a defined output, and the handoffs between them are where the quality comes from.
The eight agents
01 · Requirements
Reads the brief, the codebase and the open tickets, then produces a structured requirement set with acceptance criteria. Its most useful output is the list of things it couldn't resolve: contradictions between the brief and the existing behaviour, and decisions nobody has made yet. Those go to a person.
Human gate: your product owner settles the ambiguities and signs off.
02 · Architecture
Takes the approved requirements and maps a target design onto the system you already have, then works out a sequence that keeps production stable at every step. It outputs the design, the sequence, and the trade-offs it considered.
Human gate: your architect approves the design before implementation starts.
03 · Decomposition
Cuts the approved plan into tasks small enough to verify on their own, each with its own done-criteria traceable back to a requirement. Task size is the main lever on how well the rest of the loop works: too large and failures are ambiguous, too small and the coordination overhead swamps the work.
04 · Development
Developer agents work tasks in parallel, in the conventions the surrounding code already uses. They read the neighbouring code first, so the output matches what's there rather than an idealised house style.
05 · Code review
A separate agent checks each change against the architecture decisions and the task's done-criteria. It rejects back to step 04 with specifics. This rejection path runs without anyone being notified, which is the point: the loop absorbs its own rework.
06 · Security and vulnerability analysis
Static analysis, dependency audit and vulnerability scanning on every change. Per diff rather than per release, so a vulnerability surfaces the day it's introduced rather than during a pre-launch audit when the schedule has no room left.
07 · Real-browser testing
A testing agent runs the software in a real browser and verifies the feature by using it, then does a regression pass on adjacent functionality. Not a snapshot comparison — an actual interaction with the running application.
08 · Report back and loop
Findings return to the developer agents and the cycle runs again until the output matches the requirement. Only then does a pull request open.
Human gate: your team reviews and merges. Nothing reaches main without a human signature.
The failure paths
The happy path is the least interesting thing about this system. What determines whether it's usable is what happens when a step fails.
- Review rejects a change. It goes back to development with the specific objection. No human is involved and none needs to be.
- Browser testing fails. The failure, with what was observed and what was expected, goes back to development. This is the loop the whole design exists to close.
- Requirements come back ambiguous. Work stops at the gate. Nothing gets built against a guess.
- A task won't converge. Each task has a retry budget. When it's exhausted the task stops and escalates to a person with the full history of every attempt. Non-convergence is reported, not hidden, and it usually means the requirement was contradictory.
Working inside your setup
The fleet works in your repositories, your tracker and your CI. It reads the conventions already present in the code rather than imposing a house style. Integrations cover the usual ground: Jira, Linear, GitHub Issues and Azure DevOps for tickets; GitHub and GitLab for code; whatever CI is already running. Nothing here asks you to adopt a new tool to get started.
Where your team's time actually goes
Three commitments. Settling requirement ambiguities at the start, approving the target architecture, and reviewing pull requests throughout. The first two are front-loaded and finite. Pull request review is the ongoing one, and it's the genuine constraint on throughput, which is why intake gets sized to what your team can absorb rather than to how fast work can be produced.
Questions we get
How is this different from a developer using Copilot?
A coding assistant makes one developer faster at writing code. It sits in the editor, works on the open file, and a human drives every step. The fleet is an orchestration: separate agents with separate jobs, defined handoffs, and a verification loop that closes. The reviewing agent didn't write the code it's reviewing. The testing agent opens a real browser and uses the feature. Work continues when nobody's at a keyboard. The unit of output is a reviewed pull request with evidence attached, not a faster keystroke.
What if the agents loop forever?
The loop is bounded. Each task carries a retry budget, and when it's exhausted the task stops and escalates to a person with the full history of what was attempted and why each attempt failed. In practice a task that won't converge usually means the requirement was ambiguous or the acceptance criteria contradict something already in the codebase — which is useful information, and it's exactly what gets handed back.
How much of my team's time does this consume?
Requirement sign-off and architecture approval up front, both finite. Pull request review throughout, which is the ongoing commitment and the real constraint on throughput.
Related capabilities
Bring the sceptical colleague
The questions that survive this page are the ones worth a call.