Running a Codex team of agents without a mess

The test for whether parallelism helps

Before you run a Codex team of agents on a problem, ask whether you could hand the pieces to three contractors who never speak to each other. If yes, parallel works. If the pieces need to agree on an interface that does not exist yet, you will spend more time reconciling than you saved.

This piece covers running fully separate Codex sessions by hand. Codex also ships a native subagents feature that dispatches similar work to worker agents automatically, using worktrees internally, and it is worth checking first if you want less manual setup. The manual pattern below still matters when you need more direct control over isolation than the built-in dispatch gives. Devin Workshop is part of Harness Institute.

Work that splits cleanly: a dependency upgrade across six services, adding a missing test file per module, a rename that touches many packages, porting a pattern you have already established once. Work that does not: designing the API those services will share, anything where the second task's correct behaviour depends on a decision made in the first.

Isolation is not optional

Two agents in one working tree will overwrite each other, and the failure is quiet. One finishes, the other's edits land on top, tests pass because they touch different files, and a week later you find the missing half.

Give each agent its own tree. Git worktrees are the cheapest way:

git worktree add ../repo-upgrade-auth -b upgrade-auth

Repeat per task, run one agent per directory, review the branches independently. The cost is disk space and a slower first build in each tree. Worth it.

• One agent, one branch, one working tree. No exceptions, even for a quick fix.
• Write the brief for each task before starting any of them, so you notice the hidden dependency while it is still cheap.
• Merge in an order you chose deliberately, not in the order they finish.
• Rerun the full suite after each merge, not once at the end. Interaction bugs between parallel branches are exactly what a single final run hides.

Where the ceiling is

Three concurrent tasks is where most engineers stop being able to supervise honestly. Past that, you are not reviewing, you are skimming, and the output starts arriving faster than judgement can be applied. The bottleneck was never generation.

Watch for the specific failure of divergent solutions to the same sub-problem. Two agents both needing a date-formatting helper will write two different ones, in two different places, with two different edge-case behaviours. Neither is wrong on its own branch. Together they are technical debt you paid to create. Preempt it by naming the shared utilities in the brief, or by doing that piece yourself first.

Cost is worth a sentence too. Parallel sessions multiply token spend and you may be waiting on rate limits rather than on the work. Measure before you assume three agents finish in a third of the time.

What to do next

Find a genuinely parallel task in your backlog, something like a lint rule rollout across packages, and run it three ways in three worktrees. Note how long the merge and reconciliation took, not just the generation. That number decides whether this pattern belongs in your week.

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