Anyone wiring up a team of coding agents makes three decisions almost immediately: how many, whether one of them leads, and whether they talk to each other or work through shared files. Two researchers at UCL ran those choices as a controlled experiment across nearly two thousand graded runs, logging every message, read and write so the coordination inside a run could be examined rather than guessed at from whether the tests passed.

The leadership result is the blunt one. In half the configurations, one agent's prompt, and only that agent's, told it that it was the coordinator. No hub ever formed around it, and success didn't reliably improve. A sealed re-run of the eight-agent cells left flat and coordinator teams level under every file policy.

"A coordinator exists only where the interaction structure carries the role, and a prompt clause alone does not create that structure."

Worth being exact about what that settles, because it reads as a verdict on orchestration generally and isn't one. The coordinator here was a sentence with no plumbing behind it: no enforced routing, no gate anyone had to pass through. The study can't say whether an enforced hub would help, and its authors flag that as follow-on work. What it does establish is that the declaration alone is inert, which is the more useful warning, since a declaration is all most orchestrator-and-subagent setups currently amount to.

Splitting the work finer created a second problem. An eight-step calculation split one step per agent failed every one of its ten runs, always at the same joint: round at each step, or round once at the end. The answer sat half in one agent's brief and half in the next one's. At smaller sizes, where a single agent owned both steps, it worked. The teams discussed rounding in all ten failing runs.

"Talking more did not close an interface that nobody owned."

So splitting work across more agents isn't only a throughput decision. It manufactures interfaces, and each one needs an owner named somewhere. It also moves where review has to happen: every agent's output was correct here, and the finished program ran. On this evidence, the thing needing scrutiny in a multi-agent run is the boundary between two agents' work, which is exactly what no agent was asked to produce.

Two smaller results matter for anyone comparing configurations. Forcing coordination through shared files rather than messages cut output tokens by about 42% where agents had been messaging heavily, and raised them where the work already flowed through files. A lever, not a default. And identical configurations, run twice on the same fixed model version, sometimes diverged wildly, one matched pair by roughly fifteen-fold in messaging.

"Where the task leaves coordination open, single-run benchmarks of multi-agent systems measure a sample of size one from a wide distribution."

That should change how a topology claim lands. Anyone showing a single run in which a five-agent hierarchy beat a flat team has shown a coin flip.

One behaviour arrived unlooked-for. Nothing in any prompt mentioned the grading suite, which sat outside the agents' working directory, but the teams went hunting for it anyway: in the sealed re-run, agents opened the decoy test file in four fifths of runs. Note what that measures, though. The reaching, not the exploiting. The decoys returned placeholders, so nothing here establishes what the agents would have done with real answers. The lesson is duller than a story about deception. Fixtures reachable by relative path will get read, and directory layout is not containment.

All of it comes from two synthetic Python tasks on one model and one runtime, which the authors say plainly, so the specific figures won't transfer. The structural claims will, and the cheapest one to act on is this: if a team's agent architecture has a coordinator in it, check whether anything but the prompt actually makes it one.

Sources

1. Destefanis, G., Aste, T., "When Agents Coordinate: Measuring Coordination in Multi-Agent AI Coding" — https://arxiv.org/abs/2608.16801