One agent doing everything is a solo founder doing every job. It holds up until it does not. The fix is not a bigger agent, it is more agents, each doing less, each handing clean work to the next.
9.8.1Signs one agent isn't enough
You feel it before you can name it. The agent starts strong and loses the thread on a long task. It plans, builds, and reviews in one breath, and the review is soft because the same mind that wrote the code is grading it.
Its context fills up, and quality sags on anything with more than a few moving parts. Those are the signals that the work has outgrown a single seat.
9.8.2Planner, builder, reviewer
The first and strongest split is by phase. One agent plans the work, another builds it, a third reviews it with fresh eyes.
This mirrors how real teams work, and for the same reason: the reviewer catches what the builder cannot see, precisely because it did not write the thing. Separation of roles is separation of blind spots.
It also costs roughly three times one pass, because each seat reads the context again and every token is money and waiting. So split by phase where the review actually catches things, not everywhere. Put the mechanical roles on cheap small models, which is the real reason to route your agents through one provider that reaches many. And cap the spend before you put any of this on a schedule.
9.8.3Specialized agents
Beyond the phases, you spin up specialists: a security reviewer, a test writer, a researcher. Each is a role file of its own, with its own skills and its own narrow standard of good.
A specialist beats a generalist on its home turf, because its whole configuration is bent toward one kind of excellence. You assemble a team, not a hero.
9.8.4Handoffs between them
A team is only as good as its handoffs. One agent's output has to become the next one's input with nothing lost in the gap. The cleanest handoff is a file: agent A writes it, agent B reads it.
The builder writes that, the reviewer reads it and stamps handled_by so it is never picked up twice. The file is the contract between agents, so no context lives only in one agent's head.
Someone has to run the team, and it is simpler than it sounds. One lead agent spawns the others with a clear brief each, waits, then reads back their summaries to decide what happens next. The children do not talk to each other. Reads fan out freely; writes to the same file stay with one agent, so two never edit it at once and clobber each other.
Keeping that rule needs a mechanism, and you already have it. Agents that run at the same time each get their own working copy, a separate branch or a git worktree. Their work comes back through the normal review and merge path. Anything you cannot separate that way runs one after the other instead.
9.8.5Split your first team
This prompt turns your one agent into a small team:
Do this now: paste the prompt, set up the builder and reviewer, and run one change through both so you see the reviewer catch what the builder missed.
