Agent teams add another scaling dimension

Cohere has published controlled experiments on how teams of coding agents should divide work. Dated 14 October, the research follows large demonstrations in which parallel agents built compilers, browsers and software ports. Those projects showed that agent teams can produce working code, but their different models, roles and tasks made it difficult to know which organisational choices actually mattered.

Cohere built a minimal test harness in which every agent uses a bash tool inside one shared workspace. A lead receives the task and delegates a defined subtask; workers see only their assignment and report results back. This allowed the researchers to vary team structure while measuring reward, inference cost and elapsed work on the same benchmarks.

More agents help, but the bill rises quickly

Well-organised teams improved ProgramBench reward by as much as about ten percentage points over solo agents. The gains required three to seven times more inference cost. That makes agent count a poor optimisation target by itself. A team that solves slightly more tasks may be commercially worse if it spends many times more tokens and takes longer to finish.

The study separates planning, implementation and verification. Delegating all stages sounds thorough, but on ProgramBench the largest bottleneck was discovering what a program does. Sending workers primarily into exploration and planning matched broader delegation at roughly half the cost. On another benchmark, Commit0, implementation work contributed more, showing that the right structure depends on the task.

A strong lead can coordinate cheaper workers

A Sol lead coordinating 16 Luna planning workers achieved 61.8 per cent reward at a reported cost of US$155. An all-Sol team delegating every stage reached 63.2 per cent at US$510. The mixed team therefore approached frontier performance for about 30 per cent of the cost. Cheap workers were useful when a capable lead decided how to use them.

Holding Luna workers constant while upgrading the lead raised reward from 42.5 to 51.6 and then 60.5 per cent as the lead moved from Luna to Terra to Sol. Each team beat a solo agent using the lead model, but a Terra-led team still underperformed a solo Sol agent. Coordination quality could not be recovered simply by adding inexpensive workers.

The controller needs to recognise the bottleneck

The best fixed delegation pattern will not transfer to every repository. A future controller needs to recognise whether progress is blocked by understanding, implementation, testing or integration and allocate workers dynamically. Cohere connects this result with Meta research showing that a stronger controller gained more from the same workers and budget than a simpler controller.

Teams also need mechanisms for conflicting edits, stale assumptions and duplicated work in a shared workspace. The minimal harness makes coordination measurable, but production systems require source-control isolation, merge strategies, security scanning and review. Parallel code generation can multiply defects as easily as it multiplies useful exploration.

Evaluate accepted outcomes, not agent activity

Engineering teams should compare cost per accepted change, review time and regression rate rather than celebrating the number of agents or lines produced. A mixed-model team may be attractive for exploratory planning, while a single strong agent may remain better for a tightly scoped patch. Benchmarks should include the cost of failed runs and human correction.

Cohere’s most useful conclusion is that topology is an optimisation variable. Models, roles and delegation stage can be chosen separately. Agent teams are not automatically more intelligent because they are larger; they perform well when a strong coordinator directs extra inference towards the actual bottleneck. That creates a practical path to higher capability without paying frontier-model prices for every worker.

What to watch next

The published numbers come from specific models, prices and benchmarks and will change as inference costs and model capability move. Teams should reproduce the comparison with their own repositories and include orchestration overhead. Even so, the experimental design provides a durable lesson: spend expensive reasoning where coordination has the most leverage, then use cheaper parallel workers for bounded tasks whose output a strong lead can evaluate.

Practical implications

Latency matters alongside token spend. Sixteen workers may explore in parallel, but the lead still has to read reports, resolve disagreement and integrate results. A cheaper team that takes much longer may be unsuitable for interactive development, while it could be attractive for overnight migration or test generation. Workload economics should include both compute and developer waiting time.

Security boundaries should follow delegated scope. A planning worker may need repository read access but no ability to install packages or modify branches. An implementation worker can operate in an isolated worktree, and a verification worker can receive test artefacts without production credentials. Role-specific permissions make the organisational design enforceable rather than merely described in a prompt.

The results also caution against assuming homogenous frontier teams are the premium default. A capable lead can concentrate expensive judgement while bounded workers provide breadth. As models improve, the optimal mix will change, but measuring marginal reward against marginal cost remains the right discipline for deciding whether another agent deserves a place on the team.