More agents is not more throughput. It is more throughput only when the work splits along lines that genuinely do not touch, and the cost of splitting it is lower than the time saved.
Most tasks fail that test. Knowing which is the skill.
What parallelism costs
Before the benefits, the bill, because it is usually underestimated.
Deciding the split. Somebody has to read enough of the codebase to know where the seams are. That is real work, and it is the same work whether you do it or an orchestrator does.
Writing briefs. Each agent sees only its brief and the repository. A brief that assumes context the agent does not have produces confident work in the wrong direction. Three good briefs take longer to write than one.
Contracts. If two agents need the same type, somebody must write it first and tell both, or you get two incompatible versions of it and a merge that is really a rewrite.
Merging. Three branches, three merges, and any conflict is between two pieces of code neither of which you wrote.
Money. Three agents cost roughly three times as much, plus the orchestration on top.
When one agent is right
- The work is a chain. Each step needs the previous step's result. Splitting a chain gives you agents waiting on each other, with a coordination bill on top.
- It is small. Under an hour of work for one agent is not worth a squad.
- It is exploratory. You do not know what the change looks like yet. Parallelising an unknown shape means splitting on a guess, and every wrong guess is three branches to throw away.
- It is concentrated. Everything happens in two files. Two agents in two files is the shared directory problem with extra steps.
Most everyday work is one agent, and treating that as the default is not a failure of ambition.
When a squad pays
The condition is a seam: a boundary where two pieces of work touch only through an interface that can be written down in advance.
Good seams:
- By layer. Schema and API in one, the interface in another, against a type written up front.
- By subsystem. Billing and notifications, which happen to be in the same release and share nothing.
- By surface. Three independent screens over an existing API.
- By mechanical scope. Migrate 200 call sites; split by directory. Tedious, parallel, low risk.
- Build against test. One writes the implementation, one writes the test suite from the same specification, and neither sees the other's answer.
Bad seams that look good:
- "One agent writes it, one agent reviews it." Reviewing is a turn, not a parallel workstream.
- "Frontend and backend" when the API is not defined yet. That is not a seam, it is two agents inventing the same contract twice.
- "Split by file" in a codebase where a change to any file changes three others.
The honest test
Before spawning three agents, write the three briefs. Just write them.
If you can write each one so that it names what it owns, what it must not touch, and which interfaces are fixed, and none of them has to say "coordinate with the other agent about X", then the seam is real.
If you cannot, the seam is not there yet, and the fix is usually to do the shared part first, in one session, and then split.
What an orchestrator adds
An orchestrator does the paragraph above for you: reads the repository, picks the seams, writes the briefs, reviews what comes back against the diff rather than the agent's own account of it, merges as work lands, and verifies the combined result.
It also means the coordination is a thing you can watch and correct, rather than something you hold in your head while switching between four windows.
It is not free. It is another agent, and it spends tokens reading and reviewing. The trade is worth it when the work is genuinely divisible and worth several agents' time. It is a waste on a task one agent could do in twenty minutes.
Where Fleet fits
Fleet does both, and switching is not a migration: a squad's agents are ordinary Fleet sessions in ordinary worktrees.
The orchestrator's default instructions explicitly tell it to choose the agent count from the work rather than from habit, and that one agent is a perfectly good answer for a small feature. Its round delivers one integration branch and one pull request, so however many agents were involved, you read one diff.
See squads overview and rounds and pull requests.