I run several coding agents against one codebase, each with a defined job, a routing layer that picks which one gets the work, and a set of gates that will not let a bad change reach production. The agents are the least interesting part. The rules around them are what makes the setup usable.
Why one agent stops being enough
A single agent given a whole project drifts. It starts on the task, notices something adjacent, fixes that too, renames a few things on the way past, and hands back a diff you now have to review line by line because you no longer trust the boundaries.
Splitting the work fixes most of that, for the same reason it works with people. An agent whose brief is "design this, do not write code" produces a design. An agent with read-only tools cannot quietly refactor anything while it searches. Scope is enforced by what the agent can reach, rather than by asking it nicely in a prompt.
The squad
The coding-agent squad has seven defined roles plus the session driving them, which is where the count of eight on the Kove Events rebuild comes from. Each has its own tool list and its own model, because paying for a frontier model to grep a codebase is money set on fire.
| Role | Job | Can write? |
|---|---|---|
| architect | System design, data models, trade-off calls | Design docs only |
| backend | APIs, data access, integrations, jobs | Yes |
| frontend | UI implementation, state, wiring to APIs | Yes |
| design | Layout, hierarchy, spacing, UX decisions | Specs only |
| growth | Copy, positioning, outreach | Yes |
| reviewer | Security and correctness pass on a diff | No, read-only |
| explore | Codebase search on a small fast model | No, read-only |
The read-only ones matter more than they look. A reviewer that cannot edit gives you an opinion you can disagree with, instead of a diff that has already been applied by the time you read the reasoning.
Routing, so I am not the dispatcher
A dispatch layer classifies each request before anything runs. Trivial work stays in the main thread. Standard work goes to one teammate automatically. Anything large stops and asks me before it spawns, because a wrong call on a big job is expensive and a wrong call on a small one costs nothing.
That threshold is the whole trick. Confirming everything makes the setup slower than doing the work yourself. Confirming nothing means finding out about a decision after twenty files have changed.
The gates are the actual product
Every change to this site runs a pre-push hook before it can leave the machine. It validates the structured data on all 77 pages, checks every internal link and flags orphans, blocks anything with a key-shaped string in it, blocks em dashes, checks every published price against a single ledger file, and confirms the content security policy hashes still match the inline scripts. A GitHub Action runs the same checks again plus Lighthouse budgets.
Every one of those checks assumes the agent got it wrong, which is the point. An agent that writes a broken canonical tag is fine, as long as the thing that would have shipped it stops first. The gates get stricter every time something slips through: this month a title rewrite went live with the page heading left untouched, so there is now a check comparing the title, the heading, the share card and the structured data against each other.
The rule I would give anyone starting this: for every failure that reaches production, write the check that would have caught it, in the same session. Otherwise you are relying on remembering, and the whole reason for the setup is that you will not.
State files, because context does not survive
Every project keeps a STATE file that is a dashboard rather than a diary: current state, next steps, open bugs, key files, about sixty lines. Session history goes into a separate log that is never read at the start of a session. Ideas go into a backlog file so they stop being regenerated in chat every time someone asks what could be improved.
The reason is boring and unavoidable. An agent starts every session knowing nothing, and the alternative to a state file is twenty minutes of re-reading the repository to rediscover what was decided last week. Writing the decision down once is cheaper than deriving it every time.
There is a judgement layer alongside it holding scoring anchors, known risks per system, and rulings on questions that have already been settled. Decided questions stay decided unless I reopen them, which stops a fresh session relitigating something from three months ago with less information than the original call had.
What the squad is good at, and where it falls over
It is very good at breadth. Fifty pages needing the same audit, a sweep for one pattern across a codebase, three variations of a design to compare, a review pass nobody wants to do by hand. Work that is wide and shallow, where the cost is attention rather than insight.
It is poor at deciding what is worth doing. Every judgement call about priority, taste and what a client will care about is still mine, and the times this setup has produced something bad, it was because I let it choose the goal rather than the route.
It is also slower than it looks for small tasks. A one-line fix does not need routing, a brief and a review. Knowing when to skip the whole apparatus is part of running it.
What it costs
Model choice does most of the cost work. Search runs on the cheapest capable model, implementation on a mid-tier one, and design and architecture on the expensive one, because those are the calls that are costly to get wrong. Prompt caching bills the repeated part of a long session at a fraction of the normal rate, which makes one long session far cheaper than five short ones covering the same ground.
The rest is discipline. Not connecting and disconnecting tools mid-session, not reading whole files when a line range will do, and naming the file and line in a brief instead of asking an agent to go and find it.
Common questions
How many coding agents do you run at once?
Seven defined roles, though rarely all at the same time. Each has its own tool list and its own model, and two of them are read-only so they can review or search without changing anything.
Does running several agents make the work faster?
For wide, shallow work such as auditing fifty pages, yes. For a small fix it is slower than doing it directly, because the routing, briefing and review overhead costs more than the task.
Want this pointed at your problem?
This is the same setup behind every build on this site, and I go through it in more depth on the system behind the work. If you have a project where the bottleneck is attention rather than ideas, book a free 30-minute call.