Multi-agent AI coding sounds straightforward on paper. Give a programming task to several agents, let them split the work, and hope that parallelism makes the team faster or more reliable than a single model. In practice, the interesting part is not whether several agents can write code. It is what happens between them while they are doing it. Who talks to whom? How much time and token budget gets spent just figuring out responsibilities? Do agents actually follow the communication structure we give them, or do they quietly invent their own? And when a team fails, is the problem bad code, bad reasoning, or simply an interface that nobody really owns? The paper “When Agents Coordinate: Measuring Coordination in Multi-Agent AI Coding” offers a useful way to think about these questions through a large-scale study of 1,902 instrumented coding runs. Instead of treating a run as nothing more than “tests passed” or “tests failed,” it represents the whole process as a temporal network. Agents are nodes, but so are files. A direct message becomes an agent-to-agent edge, writing a file becomes an agent-to-file edge, and reading a file becomes a file-to-agent edge. Every event keeps its timestamp, size, and estimated token cost. That small change in perspective turns coordination from something vague into something you can actually measure.
Multi-Agent Coding Is Not Just About How Many Agents You Have
One of the first surprises is that adding more coding agents does not simply create a larger version of the same team. The communication pattern itself changes. In one experimental setup, the agents worked on a distributed-knowledge task. They had to implement a Python function called process_orders, but the specification was split into several pieces. One agent might know the input and output format, another the validation rules, another the discount calculation, and another the sorting rule. Nobody had the whole specification, so the only way to build the correct function was to reconstruct the missing information through coordination. The second setup was very different. Instead of sharing pieces of one specification, agents owned consecutive stages of a processing pipeline. One agent handled parsing, another validation, another aggregation, and another formatting. Here the challenge was not “tell everyone everything.” It was “make sure the output of my stage correctly fits the input expected by the next stage.” Those two task shapes ended up producing very different communication networks.
At smaller team sizes, direct messaging grows alarmingly fast. If every agent has to establish contact with every other agent, the number of possible communication relationships grows roughly with n². The measurements initially look very close to that picture. On the chained task, the fitted message-growth exponent was about 1.92, where an exponent of 1 would mean linear growth and 2 would mean quadratic growth. In one representative distributed-task condition, average messages per run jumped from 6.1 with two agents to 28.5 with four and 71.3 with eight. If you stopped there, the obvious conclusion would be that large multi-agent coding teams are going to drown in communication overhead.
But the timestamps tell a more interesting story. Most of that growth is not sustained all-to-all collaboration. It is an opening handshake. Agents enter the run, discover who else exists, introduce what they know, ask who owns which part, and establish communication channels. Once that initial phase is over, each pair actually talks less as the team becomes larger. In some conditions, around 90% of all sender-recipient pairs that will ever appear in a run have already appeared by roughly the first fifth of the normalized messaging timeline. After that, activity concentrates on a smaller core of relationships. In other words, a graph that looks dense if you count “did these two agents ever talk?” can be much sparser if you ask “did these two agents maintain a meaningful working relationship?”
The effect becomes even clearer when the team grows beyond eight agents. To avoid the obvious problem of putting sixteen agents on a task with only four pieces of work, the researchers built longer processing chains so that every agent still had something to do. In the sixteen-step chain, average messages rose from 21.4 at four agents to 47.0 at eight agents, then essentially stopped at 46.8 with sixteen agents. The message-growth slope from eight to sixteen was effectively zero. The reason was not that the agents stopped coordinating. They changed the way they addressed the team. Named one-to-one messages fell sharply, while broadcasts increased. With sixteen agents, twelve of twenty runs in the allowed-file condition coordinated through broadcast alone. Instead of continuing to send a separate message to every peer, the agents increasingly “spoke to the room.” That is a useful warning for anyone designing a multi-agent communication architecture: theoretical pairwise connectivity does not automatically translate into sustained pairwise traffic. Agents may reorganize their own communication strategy as the team gets larger.
The Task Shapes the Agent Network More Than the Prompt Does
Another important result is that there is no single natural communication topology for multi-agent AI coding. The task itself strongly influences the network that emerges. To measure this, the researchers ignored one-off greetings and built a sustained communication graph. Two agents were considered connected only when at least one direction between them carried two or more messages. They then looked at properties such as mean degree—roughly, how many ongoing partners each agent has—and clustering, which tells us whether an agent’s partners also tend to communicate with one another.
The distributed-knowledge task naturally formed something close to a mesh. At eight agents, the mean sustained degree was 5.47, compared with 7 for a complete eight-node graph, and the clustering coefficient was 0.81. That makes sense. If everybody owns a different fragment of the same global specification, information from almost anyone can matter to almost anyone else. The team has a real reason to keep a broad set of communication channels alive. The chained task looked completely different. At eight agents the mean degree was only 2.99 and clustering was 0.38. At sixteen agents, the average sustained named-peer degree collapsed to 0.28 against a complete-graph value of 15, and clustering fell to 0.03. A pipeline does not need every stage owner to repeatedly talk to every other stage owner. Most coordination is local, around interfaces between neighboring pieces of work.
This matters because a lot of multi-agent system design still starts with the topology rather than the task. We decide in advance that a system should be a star, a mesh, a hierarchy, or a chain, then fit the problem into it. The measurements here suggest the opposite way of thinking may be more useful. Start with the information dependencies in the task. If the task requires reconstructing a shared global state, dense communication may be justified. If the task is naturally decomposed into local interfaces, forcing all-to-all discussion may only create noise and cost. A topology should reflect the information structure of the work, not just an architectural preference.
This also explains why simply naming one agent “the coordinator” did surprisingly little. In the coordinator condition, only one thing changed: one agent was told in its prompt that it was the coordinator. If that label really created leadership, communication should have concentrated around that agent, creating a hub. It did not. The measured networks remained essentially leaderless. Even when the researchers filtered for unusually strong communication channels, almost no structural backbone centered on the nominated coordinator appeared. Success rates also showed no reliable improvement. In some cells the coordinator looked slightly better, in others it looked worse, and the apparent advantages did not consistently survive pooling or sealed replication.
There is a simple engineering lesson here: a role label is not a topology. Writing “You are the coordinator” in a system prompt does not guarantee that other agents route decisions through that agent, consult it before committing changes, or give it ownership of disputed interfaces. If you genuinely want a hierarchical or star-shaped multi-agent coding system, the routing probably needs to be enforced by the runtime, workflow, or permissions. Structural leadership comes from the interaction pattern, not the job title.
Shared Files Are a Communication Channel, Not Just an Output Format
The treatment of files is probably the most practically useful idea in the study. We often think of communication between AI agents as messages, but in software engineering, files are communication too. A message is usually one-to-one: Agent A sends something to Agent B. If seven agents need the same information, the content may be repeated seven times. A file behaves differently. One agent writes a specification, plan, interface description, or intermediate result once, and multiple other agents can read it later. The information persists even after the original sender is no longer active. From a coordination perspective, that makes a shared file both persistent memory and a one-to-many channel.
The experiment tested this directly by using three file policies: shared coordination files could be forbidden, allowed, or mandatory. On the message-heavy distributed-knowledge task, forcing the agents to use shared files caused direct-message token usage to collapse. At eight agents, tokens associated with direct messaging fell from roughly 10,500 per run under the default allowed policy to around 1,700 under the mandatory-file policy. More importantly, total model output tokens fell by about 42% at eight agents, with the two collection sessions showing reductions between roughly 36% and 49%. Cached context throughput also fell substantially. The reason is not mysterious: the team was repeatedly sending the same global information through one-to-one channels, and a persistent shared artifact removed a lot of that repetition.
That does not mean “always force agents to use files.” On the chained task, mandatory files increased output tokens—around 17% at four agents and 10% at eight. In the sixteen-agent scaling case, the mandatory-file condition used roughly 578,000 tokens per run compared with 333,000 under the normal allowed condition, with identical success. Why? Because files were already naturally carrying the pipeline state. Each stage produced something the next stage needed to consume. Adding extra file-based coordination did not replace redundant messaging; it created additional overhead on top of a workflow that was already file-mediated.
That gives us a much better rule than “files are cheaper than messages.” If the team is repeating shared information through many direct messages, move that information into a persistent artifact. If the task already passes state naturally through files, do not add another file protocol simply because it sounds structured. The cheapest communication channel depends on the shape of the work.
This is especially relevant for modern coding-agent systems because the shared artifact does not have to be a source-code file. It could be a specification document, an interface contract, a task ledger, a list of unresolved questions, or a structured state file. The broader idea is to separate information that needs persistent one-to-many visibility from information that genuinely belongs in a conversational exchange.
More Communication Does Not Automatically Fix Coordination Failures
One of the clearest failure cases shows why measuring coordination structure matters. In an eight-step processing chain, the system succeeded in nine out of ten runs with two agents and nine out of ten with four agents. With eight agents—one agent per step—it failed all ten runs. The problem appeared at exactly the same boundary every time: one stage calculated tax and another formatted the final invoices. The specification implied that tax values should remain unrounded until the final formatting stage. When fewer agents were used, one agent sometimes owned both stages, so it could reconcile that rule internally. At eight agents, the convention was split across two different owners. Neither agent individually owned the whole interface.
The most revealing part is that the agents did talk about rounding. Every failed eight-agent run contained discussion of the issue, and those teams actually sent more messages than the four-agent teams. The failure was not caused by silence. It was caused by missing ownership. Each agent could make its own component locally correct while the interface between the components remained globally inconsistent.
That is a valuable lesson for multi-agent software engineering: every interface needs an owner. More messages are not a substitute for responsibility. If two agents each own one half of a convention, but nobody owns the contract connecting those halves, you can get a team where everybody is locally correct and the system is globally wrong. This is very similar to human engineering organizations. Bugs often live at boundaries—between services, modules, teams, or assumptions—rather than inside components that clearly belong to one person.
This also helps explain why network metrics alone are not good predictors of success. More messaging can mean healthy coordination, but it can also mean the team is repairing confusion. More file writing can represent efficient shared-state management, or it can represent duplicated effort. The communication graph tells us what happened during the run, but causality still depends on the task and the meaning of those interactions. In the reported analysis, simple network properties explained only a modest part of the variance in success. The graph is better at revealing the structure of the process than at giving a universal formula for “more communication equals better performance.”
Why One Multi-Agent Run Is Not Enough
There is another result that should probably get more attention in AI agent benchmarking. The exact same configuration can produce substantially different coordination behavior on different runs. The study deliberately collected the flat-team condition twice with byte-for-byte identical prompts and the same pinned model. On the chained task, the results were highly reproducible. On the distributed task, they were much less stable. Some matched configurations produced very different message counts across collection sessions. The difference was not simply generic measurement noise; reproducibility depended on how much freedom the task gave the agents to organize themselves.
That means a single impressive agent trace should be treated carefully. Watching one run where four coding agents beautifully divide responsibilities, share a specification, and merge their work does not prove that the configuration reliably behaves that way. It proves that the configuration can behave that way. A meaningful evaluation should treat coordination as a distribution of possible behaviors. Run the same configuration repeatedly, measure the resulting networks, and report the variation.
This point becomes even more important for automatic multi-agent topology design. A topology generator may output what looks like an efficient graph, but execution can still produce a different emergent communication structure. The declared architecture and the actual architecture are not always the same thing. If we want to optimize multi-agent coding systems seriously, the loop should probably be: propose a coordination structure, execute it several times, measure the actual communication graph, observe cost and success, then adapt the structure.
What This Means for the Future of Multi-Agent AI Coding
The bigger takeaway is that multi-agent coding should not be treated as “single-agent coding, but with more agents.” Adding agents changes the communication system. At first, teams pay an introduction cost that can look almost quadratic. As teams grow, they may switch toward broadcast. Different tasks naturally generate different sustained topologies. Shared files can act as scalable one-to-many communication channels, but only when they replace repeated messages rather than duplicate an already file-based workflow. A coordinator label does not create a coordinator network. And when coordination fails, the root cause may be an interface that no agent truly owns, not a lack of communication.
These findings also change how we should think about automatic agent architecture. A good multi-agent system should not simply minimize the number of messages or maximize the number of connections. It should match the coordination mechanism to the dependency structure of the task. A shared-specification problem may genuinely benefit from broad communication and persistent shared state. A pipeline may work best with sparse local interfaces. A system that needs leadership should enforce decision routing instead of hoping a prompt creates authority. And a system that repeatedly sends the same information to many agents should probably promote that information into a shared artifact.
The most useful mental model is therefore not “How many agents should I use?” but “What information needs to move, who needs it, how long should it persist, and who owns the boundaries?” Once those questions are answered, the right multi-agent coding topology becomes much easier to reason about.
Multi-agent AI coding is likely to become more common as coding systems move from single autonomous agents toward teams that plan, implement, test, review, and debug in parallel. But more agents will not automatically mean better engineering. The teams that scale well will be the ones whose coordination structure fits the work. That means measuring the communication that actually happens, not just the topology we intended to create—and not just whether the final test suite happened to turn green.