Agent teams in Codex and when the extra agents pay off

The rule that predicts success

Running agent teams in Codex works when the subtasks do not need to agree with each other. If two agents must converge on the same interface, the same data shape, or the same naming, you have created a coordination problem that used to be one agent's internal state. Coordination between agents is expensive and unreliable in a way coordination inside one session is not.

So the question to ask before splitting: could two different engineers do these pieces in separate weeks without talking? If yes, split. If they would need a fifteen minute conversation first, do not.

What splits cleanly

• Mechanical migrations across many files. Renaming a deprecated call, updating an import path, moving forty test files to a new assertion style.
• Independent bug fixes in unrelated modules.
• One agent writing code and a separate one reviewing it afterwards, which is really a pipeline rather than a team.
• Research fan-out. Several agents reading different parts of a large codebase and reporting back, with no edits at all.

That last one is underused. Read-only agents are cheap and safe, and answering "where is this concept implemented" across a monorepo is exactly the job where parallelism wins with no merge risk.

What does not split

A new feature that touches the API, the database, and the frontend. People try this constantly. Three agents, three layers, sounds tidy. What comes back is an endpoint returning snake_case, a client expecting camelCase, and a migration that added a nullable column the API assumes is populated. Each piece is individually defensible. Together they do not run.

The fix, when a team insists on trying, is to have one agent define the contract first and write it to a file, then let the others work against that file. That is a real technique and it works. It is also slower than just doing the feature in one session, which is why most teams go back to one session.

The operational cost nobody budgets for

Every parallel agent needs its own working directory. Two agents in one checkout will clobber each other, so the setup is a worktree per agent:

Then you have three branches to merge, three diffs to review, and no single place where the whole change is visible. Review is the bottleneck, and parallel agents make more of the thing that was already your bottleneck. We have seen teams double their output of pull requests and halve the fraction that gets a real read. That is a loss, however good the throughput number looks in a slide.

What to do next

Try it on one mechanical migration where the files are genuinely independent, with a worktree per agent. Time it against doing the same thing in one session. Then look at your review capacity before you scale it up, because that is what will break first. If your team already has pull requests sitting for two days, adding agents makes your problem worse, not better.

If you want help putting this into practice, talk to us.