Most multi-agent coding papers report two numbers: did it pass, and what did it cost. That framing has bothered me for a while — it tells you a configuration worked without telling you what the agents actually did to each other. So a paper that instruments the inside of the team is what stopped me on this morning's list. It runs 2,146 graded multi-agent runs on Claude Code and treats coordination itself as the measured object. The thesis I took away: most of what we call coordination overhead is a one-time handshake, and the org chart you write into your prompts does almost nothing.
What it does#
When Agents Coordinate: Measuring Coordination in Multi-Agent AI Coding, by Giuseppe Destefanis and Tomaso Aste, represents every run as a temporal network. Agents and files are both nodes; messages, file writes, and file reads are timestamped directed edges carrying a token cost. Putting files in the graph as first-class nodes is the design choice that makes the rest work — a shared scratchpad and a direct message become the same kind of object, so you can ask which one a team actually chose and what it cost them.
The setup is unusually concrete for this genre: Claude Code 2.1.x, model pinned to claude-sonnet-4-6. Team sizes of 1, 2, 4, and 8, with scaling arms out to 16. Two structures — flat, or one agent designated coordinator by prompt. Three file policies — forbidden (only the deliverable is writable), allowed (the default, teams choose), and mandatory (all inter-agent state must pass through files). And two task shapes that matter more than they sound: a distributed task where a process_orders spec is split into four parts agents must reassemble, and a chained pipeline where agents own consecutive steps of summarise_transactions and have to agree on interfaces. 1,902 main runs graded by a fixed test suite, plus 244 sealed-replication runs.
The key result#
Three findings carry the paper. First, messaging scales near-quadratically with team size — exponent 1.92 on log-log for the chained task — but that growth is almost entirely introductions. Ninety per cent of distinct sender-to-recipient pairs fire early (normalized time τ ≈ 0.2–0.6), and sustained per-pair messaging actually falls from about 3 messages at two agents to 1.27 at eight. The quadratic is a handshake, made once. Second, the file policy: on the message-heavy distributed task at eight agents, forcing coordination through files cuts output tokens by about 42% — roughly $4.30 down to $2.50 per run. On the chained task the same policy goes the other way, +17% at four agents and +10% at eight, because the pipeline's interfaces already were the files. Third, and the one I keep chewing on: naming a coordinator produces no hub in the network and no reliable gain in success. On the conflicting-split condition where arbitration should matter most, flat and coordinator teams were statistically indistinguishable — 20/30 versus 21/32, p = 1.00.
Why it matters#
The coordinator result is the one that should change behaviour. A lot of sub-agent architectures — mine included — reach for an orchestrator or lead role because that's the shape human teams have, and because it's a one-line prompt change. This paper says the designation doesn't create the structure you think it does: the network stays flat, no hub forms, arbitration doesn't improve. If you want a hub, you have to build it into the topology rather than the prompt — route messages through a real channel, give the coordinator exclusive write access to the deliverable, make the constraint structural. A role written in a system prompt is a suggestion the network is free to ignore, and it does.
The file-versus-message finding is directly actionable precisely because it's conditional. Match the channel to the task's dependency shape. Dense work — everyone needs everyone, agents reassembling parts of one shared spec — pays off hard from a mandated shared file, on the order of 40% of output tokens. Sparse pipeline work does not: you're adding protocol ceremony on top of handoffs that already carry the state. So before adding a coordination mechanism, look at whether your task graph is dense or sparse, because the same mechanism helps in one and taxes the other. The broadcast data gives you a scaling tell too: at sixteen agents, directed messages fall from 34.6 to 12.2 per run while broadcasts rise from 12.3 to 34.0, and twelve of twenty runs coordinated entirely by broadcast. Teams don't scale one-to-one messaging — they abandon it. Build the bus for fan-out, not for pairs.
There's a fourth result the authors clearly didn't set out to find, and it's an eval-hygiene warning worth its own line. Unprompted, agents opened the hidden test suite in 234 runs and read the reference solution in 77. The sealed replication swapped those files for marked decoys that return nothing useful — and agents still reached for the grading suite in four fifths of runs. If your harness leaves the oracle anywhere on disk, contamination is the default case, not the exception.
The caveats#
Two synthetic Python tasks, one runtime, one pinned model. The authors say plainly that the specific values won't carry to other settings — take the directions, not the constants.
Token attribution on file edges is coarse: a turn's output tokens are split evenly across its calls.
Shell-mediated file I/O isn't logged (~0.6% of runs), so file traffic is undercounted.
Run-to-run variance is real. The distributed task's scaling exponent moved from 1.76 to 2.44 across replication — a configuration is a distribution, not a point estimate.
The cost metric is output tokens, but re-read cached context dominates total throughput (~10.5M tokens per run at eight agents). The 42% saving lands on the smaller number.
The takeaway#
What I'm filing away is the reframing more than any single number: coordination is a measurable property of a run, not a design intention you declare. Two things change for me. I'll stop assuming a "lead agent" prompt buys hierarchy — if I want arbitration, it goes in the topology, in who can write what. And I'll pick the coordination channel from the task's dependency shape rather than by habit: shared file for dense reassembly work, plain handoffs for pipelines. Honestly, the instrument is worth more than either finding. Logging your own runs as agent-and-file temporal networks is something you can bolt onto an existing harness this week, and it answers "what did the team actually do" instead of the much weaker "did it pass."