Paper deep dive
When Agents Coordinate: Measuring Coordination in Multi-Agent AI Coding
Giuseppe Destefanis, Tomaso Aste
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 8/23/2026, 2:52:49 AM
Summary
This study introduces a temporal network instrument to measure coordination in multi-agent AI coding systems, analyzing 1,902 runs across varying team sizes, structures, and file policies. Key findings include that direct messaging grows quadratically initially but levels off via broadcasts in large teams; shared files can reduce token costs by 42% in message-heavy tasks but add overhead otherwise; and designating a coordinator agent yields no significant communication hub or success improvement. The research also highlights an unprompted tendency for agents to seek hidden grading materials.
Entities (7)
Relation Signals (6)
Temporal Network Instrument ā measures ā Coordination
confidence 98% Ā· We introduce an instrument to measure this coordination. Each run is represented as a temporal network...
Temporal Network Instrument ā analyzes ā 1,902 runs
confidence 95% Ā· We apply this instrument to 1902 runs, each evaluated with a fixed test suite...
Coordinator Agent ā doesnotimprove ā Success Rate
confidence 92% Ā· Naming one agent as coordinator creates no communication hub and provides no reliable improvement in success.
Shared Files ā reduces ā Output Tokens
confidence 90% Ā· Shared files can replace repeated 1-to-1 communication, cutting output tokens by about 42% at eight agents on message-heavy work
Direct Messaging ā scales ā Quadratically (initially)
confidence 90% Ā· Direct messaging initially increases close to quadratically with the number of agents
Agents ā seek ā Hidden Grading Material
confidence 88% Ā· We also observe an unprompted tendency for agents to seek out hidden grading material.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:We study how teams of AI coding agents coordinate while solving programming tasks. Current evaluations usually report whether the agents complete the task and how much the run costs, leaving the coordination inside the team largely unmeasured. We introduce an instrument to measure this coordination. Each run is represented as a temporal network in which agents and files are nodes, and messages, file writes, and file reads are timestamped directed edges with an associated cost. We apply this instrument to 1902 runs, each evaluated with a fixed test suite, across configurations that vary the team size, the team structure, and the file policy. The resulting networks show how coordination changes as teams grow and as the work changes. Direct messaging initially increases close to quadratically with the number of agents, with much of this growth coming from an early round of introductions. As the teams grow further, this increase levels off in the largest teams we study, where agents increasingly communicate through broadcast messages. The task also shapes the network that emerges. Work built around a shared specification produces dense, highly connected teams, while pipeline tasks produce sparse networks organised around local interfaces. Shared files can replace repeated 1-to-1 communication, cutting output tokens by about 42% at eight agents on message-heavy work, while adding overhead when files already carry the coordination. Naming one agent as coordinator creates no communication hub and provides no reliable improvement in success. We also observe an unprompted tendency for agents to seek out hidden grading material. We repeat the key experimental conditions in a sealed environment, replacing the hidden material with marked placeholder files. Across 244 additional runs, agents still reach for it in four fifths of runs, while the coordinator and file-channel findings reproduce.
Tags
Links
- Source: https://arxiv.org/abs/2608.16801v1
- Canonical: https://arxiv.org/abs/2608.16801v1
Trouble viewing inline? Open PDF directly ā
Full Text
92,572 characters extracted from source content.
Expand or collapse full text
When Agents Coordinate: Measuring Coordination in Multi-Agent AI Coding Giuseppe Destefanis Thanks: Corresponding author: g.destefanis@ucl.ac.uk Tomaso Aste Affiliation: Department of Computer Science, University College London, UK Abstract We study how teams of AI coding agents coordinate while solving programming tasks. Current evaluations usually report whether the agents complete the task and how much the run costs, leaving the coordination inside the team largely unmeasured. We introduce an instrument to measure this coordination directly. Each run is represented as a temporal network in which agents and files are nodes, and messages, file writes, and file reads are timestamped directed edges with an associated cost. We apply this instrument to 1,902 runs, each evaluated with a fixed test suite, across configurations that vary the team size, the team structure, and the file policy. The resulting networks show how coordination changes as teams grow and as the work changes. Direct messaging initially increases close to quadratically with the number of agents, with much of this growth coming from an early round of introductions. As the teams grow further, this increase levels off in the largest teams we study, where agents increasingly communicate through broadcast messages. The programming task also shapes the network that emerges. Work built around a shared specification produces dense, highly connected teams, while pipeline tasks produce sparse networks organised around local interfaces. Shared files can replace repeated one-to-one communication, cutting output tokens by about 42% at eight agents on message-heavy work, while adding overhead when files already carry the coordination. Naming one agent as coordinator creates no communication hub and provides no reliable improvement in success. We also observe an unprompted tendency for agents to seek out hidden grading material. We repeat the key experimental conditions in a sealed environment, replacing the hidden material with marked placeholder files. Across 244 additional runs, agents still reach for it in four fifths of runs, while the coordinator and file-channel findings reproduce. Repeated runs also show that coordination measurements can vary substantially under the same configuration and pinned model, especially when the task leaves agents more freedom in how to organise. A single run therefore gives only one sample of the coordination behaviour of a configuration. These results show that coordination among AI coding agents can be measured directly, exposing structures, behaviours, and costs that task success and aggregate token counts leave hidden. Keywords: multi-agent systems, AI agents, large language models, software engineering, network analysis, empirical study 1 Introduction Multi-agent AI coding systems assign a programming task to several agents that work in parallel in a shared workspace. Whether the team succeeds, and what the run costs, depends on how the agents coordinate: how they divide the work, what they tell each other, which files they share, and how they resolve the interfaces between their contributions. Almost none of this survives into the final code. A run can pass every test while leaving no trace of how much coordination it required, and two runs that pass the same tests can differ severalfold in messages, file activity, and tokens. A developer configuring such a system must decide the team size, whether to name one agent coordinator, and whether the team should coordinate through direct messaging or through shared files. The effects of these choices are still poorly understood. Evaluations typically report task success and the final code or patch, with computational cost increasingly considered as an additional evaluation dimension [19, 32, 1], or prescribe which agents may communicate with which [29, 16, 39]. These measures do not show the coordination structure that emerges during a run. We make that structure measurable. Each run is represented as a temporal network in which agents and files are nodes. A direct message is an agent-to-agent edge, a file write is an agent-to-file edge, and a file read is a file-to-agent edge; every edge carries a timestamp, a byte size, and a token cost. Treating files as nodes is central to the instrument. A file persists after it is written; one write can be read by many agents in any order; and its contents remain in the shared workspace across agent processes and outlive the session that wrote them. Files therefore provide persistent shared state as well as a one-to-many communication channel. Representing them as nodes allows file-mediated coordination and direct messaging to be measured on the same timeline. Every edge corresponds to a logged event, so the temporal network records the coordination that occurred during the run. We apply the instrument to 1,902 runs, each evaluated with a fixed test suite, across two experiments using synthetic Python tasks. In Experiment 1, the distributed task, each agent holds a different part of a specification and the team must reconstruct the whole. In Experiment 2, the chained task, each agent owns consecutive steps of a processing chain and the team must agree the interfaces between them. Across these runs we vary three factors: the team size, from one to eight agents in the main experiments and up to sixteen in a scaling arm11 1 A scaling arm is a pre-registered extension of the chained task with more steps, so that a larger team still has work for every agent.; the team structure, with either a flat team or one agent named coordinator; and the file policy, with shared files forbidden, allowed, or mandatory. Section 3 defines the experimental design in full. One question organises the study: how does coordination scale and reorganise as these teams grow, under different team structures and file policies? The answer speaks to each of the three configuration choices above, and in each case the coordination we measure behaves differently from what the runās outputs alone would suggest. ā¢ Team size. Messaging does grow near-quadratically with the team, which suggests a cost that will keep growing. The timestamps show otherwise: the growth is a one-off round of introductions early in each run, what persists afterwards is far smaller, and on the largest teams messaging growth levels off as the teams shift towards broadcast (Section 4). ā¢ Communication channel. A direct message reaches one agent; a file is written once and can be read by many. Requiring teams to coordinate through shared files cuts a large share of the output-token cost on one task and adds cost on the other. This difference shows that the effect of the channel depends on the task (Section 6). ā¢ Leadership. Naming one agent the coordinator in its prompt produces no hub and no reliable gain in success, and a sealed replication finds flat and coordinator teams level at eight agents. A team is organised by the structure that emerges in its interactions, and a prompt label alone creates none of it (Sections 7 and 9). Underneath all three choices is the shape of the network itself, and the task sets that shape. The distributed task builds a dense, tightly clustered mesh that rides the all-to-all line as the team grows; the chained task builds a sparse network whose gap to all-to-all widens with team size, until at sixteen agents scarcely any named-message network forms at all (mean degree 0.28 against a clique of fifteen). Neither shape has a leader. Left to organise themselves, the teams do not converge on a single coordination span; they let the task dictate the structure (Section 5). A further result concerns the instrument itself. Under a pinned model, the chained task reproduces across collection sessions almost exactly, while the distributed task does not: the same configuration, collected twice under the same pinned model, gave two incompatible growth rates. A configuration is therefore characterised by a distribution of runs, and any single run is one sample from it; where matched sessions exist we report the headline number with its cross-session range (the scaling arms and the sealed replication are single batches; Section 8). The measurements also expose failures that the final code hides. An eight-step calculation split one step per agent failed in all ten runs, every time on the same question: round at each step, or once at the end. The convention sat on the boundary between two agents, and no agent owned it. The teams discussed rounding in every one of those runs and still never agreed. Success rates do not reveal this failure mechanism. The temporal network shows the structural condition behind it: the failing interface lies between two different owners (Section 7). A last result is a behaviour we did not anticipate. Each task is graded by a hidden test suite, and no prompt tells the agents to look for it. Yet the teams went looking, and a validity check found them reading it, together with the reference solution, where the main runs had left both reachable. We re-ran the load-bearing cells in a sealed environment, with decoys in place of the hidden files: the two findings these cells test reproduce, and the teams still reach for the hidden test suite in four fifths of runs even though it returns nothing, an unprompted search for the answer key that a grade cannot see (Section 9). The paper contributes: (i) a temporal-network representation of multi-agent coding runs with agents and files as first-class nodes; (i) an instrumentation pipeline that turns a runās logs into that network; (i) a released dataset of 1,902 graded, fully instrumented runs across a controlled grid of configurations, together with a sealed replication of a further 244 runs (Section 9); and (iv) the three findings above, each pre-registered where confirmatory and reported with its reliability, two of them (the coordinator null and the file-channel substitution) re-tested in the sealed replication, together with a task-resolved topology result showing that the task sets the shape of the coordination network (Section 5). 2 The Instrument: a Run as a Temporal Network a1a_1a2a_2a3a_3a4a_4spec.mdsolution.py12673845messagefile writefile read1order in time Figure 1: One small run drawn as the measured object. Agents (circles) and files (rectangles) are both nodes; every logged event is a typed edge carrying a timestamp, a byte size, and a token cost, and the circled numbers give the order in time. Here a1a_1 opens with two messages (1, 2), a2a_2 writes the specification once (3), two agents read it (4, 5), a3a_3 and a4a_4 agree an interface by message (6, 7), and a4a_4 writes the deliverable (8). What to notice: the files take part in the network as nodes of their own, and one write (3) serves two readers (4, 5); a direct message reaches one recipient. Formally, we model each runās temporal network as a heterogeneous graph G=(V,E)G=(V,E). The vertices V=AāŖFV=AāŖ F are the agents A and the files F touched during the run. The edges are typed and timestamped: an agent-to-agent edge is a direct message, an agent-to-file edge is a write or an edit, and a file-to-agent edge is a read. Every edge carries a timestamp, a byte size, and a token cost. Figure 1 shows a small instance. Making files nodes, with their own identity and their own edges, is the design choice everything else rests on. The file channel behaves unlike the message channel in three ways. A file persists after it is written. One write can be read by many agents, in any order and after any delay. And a file crosses process and credential boundaries that an in-memory channel cannot. Giving files separate read and write edges puts file-mediated coordination on the same footing as direct messaging, which is what makes the channel comparison of Section 6 possible at all. The network is a direct record: every edge corresponds to a logged tool-call event, a message sent through a dedicated messaging tool or a file operation performed with the runtimeās file tools, so the counts and identities of those events are exact. One blind spot follows from this: a file read or write issued through the shell leaves no edge, so file activity is a slight undercount (Section 10). The one coarse quantity is the token cost on file edges: the runtime reports tokens per turn, and a turn can make several tool calls, so we divide a turnās output tokens evenly across its calls. The authoritative per-turn usage is stored alongside, so any finer attribution can be applied later without re-parsing. Task libraryTask generator(one configuration)Run setup(workspace, prompts)N agent processes(parallel)Verifier on workspaceresult.jsonMCP server(message log)session +message logsParserper-run CSVs:nodes, edges, turns, runs Figure 2: From a run to a network. The generator deals the taskās units to the agents, the agents run as parallel processes and message each other through a logging server, a verifier grades the workspace, and a parser turns the logs into four CSV tables: nodes, edges, turns, and runs. What to notice: instrumentation is external to the agents, so the pipeline works for any runtime that logs tool calls. Figure 2 shows the pipeline. A generator produces a task instance for the requested configuration and deals its units out to the N agents. Each agent runs as a separate process, sends direct messages with a send_message tool, and collects them with check_messages; every message is logged with sender, recipient, size, and time. When the team finishes, a verifier runs a fixed test suite against the workspace, and a parser converts the session and message logs into four linked CSV tables that encode the network. One run yields one network and one binary outcome, and that pair is the unit of analysis. 3 The Experiment Experiment 1: distributed knowledgeprocess_orders, one function, spec cut into four partssignaturevalidationdiscountsortinga1a_1a2a_2a3a_3a4a_4each agent sees one part, never the whole:the team must reassemble the spec by coordinatingExperiment 2: sequential dependencysummarise_transactions, a four-step chainparsevalidateaggregateformat a1a_1a2a_2the interfaceeach agent owns consecutive steps, without knowing its position:the interface between owners must be agreed1248team sizeforbiddenallowedmandatoryshared filesteam structure: flat (collected twice, as collection A and B) or coordinatorEach experiment repeats this whole grid for each spec split (clean, overlapping, conflicting);combinations that make no sense are dropped (e.g. mandatory files at one agent).one cell == one configuration, run 10 timesevery run ā pass/fail from the test suiteevery run ++ one temporal networkExperiment 1: 8585 cells ā850ā 850 runs Experiment 2: 8787 cells ā870ā 870 runs scaling arms: 30+7030+70 runs (to n=16n=16) pilots, checks: 8282ā 1,902 graded runs released, model pinned to claude-sonnet-4-6 Figure 3: The dataset at a glance. Top: the two task shapes. In Experiment 1 the specification is cut into four parts and dealt out, so the team must reassemble knowledge; in Experiment 2 the task is a chain of steps owned by different agents, so the team must agree the interfaces between owners. Middle: every run sets three factors, team size, team structure, and the file policy; one choice of all factors is a configuration, and ten runs of a configuration in one collection form a cell (magnified). Bottom: the resulting run counts. What to notice: the dataset is one controlled grid, so any two cells differ only in the factors named here. Figure 3 summarises the experimental design. This section walks through it top to bottom and defines the terms used throughout the paper. The pre-committed hypotheses and the statistical machinery are in Appendix A. Two experiments. Work divides across a team in two canonical ways: into independent pieces of knowledge, or into dependent steps. We built one experiment for each, where an experiment is a task together with its variants. In Experiment 1, the distributed task (process_orders), the specification of one Python function, process_orders(orders, config), is cut into four parts: the function signature and return shape (a dictionary of the processed orders, their count, their summed total, and a count of rejected orders); the validation rules (an order is valid when its amount is a non-negative number and its quantity a positive integer); the discount calculation (a bulk discount when the quantity reaches a threshold, and a loyalty discount for listed customers, both applied to the orderās amount alone and never multiplied by its quantity); and the sort order of the output. No agent in a team is given the whole specification, and none is told who holds what, so the team can only recover it by coordinating. How the parts are dealt out is the split, with three values: clean, each part held by exactly one agent; overlapping, some parts duplicated across two agents; and conflicting, where two agents hold versions of the validation rule that disagree on a single point (whether a quantity of zero is valid), the test suite silently enforces one version, and neither agent is told which. The conflicting split therefore plants a disagreement that the team must first notice and then resolve the right way. In Experiment 2, the chained task (summarise_transactions), the task is a four-step processing chain, and each agent owns one or more consecutive steps. Every agentās prompt carries the same team-level knowledge, the name and signature of the pipeline function the team must deliver, together with its private piece: the full input-to-output contract of its own step and the name of the file it must produce. The chainās length, the agentās position in it, and the content of the other steps are withheld, and every step after the first names only the step immediately upstream. The interfaces between owners must therefore be agreed during the run, and the team must also decide who writes the pipeline file that assembles the chain. Experiment 2 crosses the same three splits (its conflicting split disagrees on whether an amount of zero is valid), and two longer chains appear in the scaling arms below. Three crossed factors. Every run fixes three factors. Team size is 1, 2, 4, or 8 agents. Team structure is either flat, all agents equal, or coordinator22 2 Labelled orchestrator in the released dataset and the pre-registration records., where one agentās prompt, and only that agentās prompt, names it the coordinator. File policy33 3 Recorded as artefact_policy in the released dataset and the pre-registration records. governs coordination through shared files: forbidden, only the deliverable itself may be written, so the file traffic that remains under this policy is only the deliverable being written and read back; allowed, the team does as it pleases, which makes this the default condition; or mandatory, all inter-agent state must pass through files. One choice of all factors, plus the split, is a configuration. Crossing the factors and dropping the combinations that make no sense (a mandatory file policy with a single agent, for example) leaves 58 distinct configurations per experiment. A cell is ten runs of one configuration in one collection, the unit at which we report results; the flat structure above one agent was collected twice (Section 8), so each of its 27 configurations contributes two cells, and the crossing gives 85 cells per experiment. Experiment 2ās released grid carries two further single-configuration baseline cells, both at four agents, flat, allowed, giving 87: the eight-step chain (compute_invoices) at a grid-interior configuration, and a variant of the main task (summarise_transactions_v2) whose output ordering depends on a constant defined in another, non-adjacent stepās specification, so the value can only arrive through coordination. The two experimentsā grids together contain 1,720 runs. One deliberate duplication. The flat structure was collected twice, with byte-for-byte identical prompts, in two collection runs we call collection A and collection B44 4 They appear in the released data under the topology labels solo and peer.; above one agent the two are wired identically and differ only in when they were collected). The two collections overlap in calendar time, so the divergence reported in Section 8 cannot be attributed to drift between distant sessions. The duplication is deliberate: it gives every flat cell an exact same-configuration twin, which is what lets Section 8 measure how well the whole instrument reproduces. When a result uses only one of the two sessions, we say which. Overstaffed cells. The grid holds each task fixed while the team grows, because a fixed task is what makes two cells comparable; the price is that an eight-agent team on a four-part task leaves four agents with no part of the specification to hold. We keep those cells because overstaffing is a normal state of real teams: projects routinely carry more people than the work needs, and the extra members keep joining the coordination while producing little. The overstaffed cells measure that cost directly, what adding agents does to the coordination network when the work cannot absorb them. The four agents without a part turn out to be the teamās most active coordinators: in the eight-agent Experiment 1 runs they send 62% of all messages, 13.7 per agent per run against 8.4 for the agents holding parts, because an agent that holds nothing must ask the others for everything. The one conclusion these cells cannot support is a scaling law, since above four agents growth in coordination cannot be separated from the team running out of work. The two scaling arms. A scaling arm is a chained task with more steps, so that a larger team still has work for every agent. There are two arms, both pre-registered: for each, we wrote down what we expected to find and exactly how we would test it before any runs were collected, and the released package contains those records. The eight-step chain (compute_invoices) runs at 2, 4, and 8 agents under the allowed policy (ten runs per cell, 30 runs); the sixteen-step chain (process_billing) runs at 4, 8, and 16 agents, the only part of the study that reaches sixteen agents. Figure 4 and hypothesis H7 use the armās own cells; the gridās baseline compute_invoices cell is separate. The sixteen-step arm carries twenty runs per cell under the allowed policy instead of ten, decided in advance: more runs per cell sharpen the test of whether messaging growth stops at large team sizes (hypothesis H8, Appendix A). A further ten-run mandatory cell at sixteen agents brings the arm to 70 runs. Steps are dealt in contiguous blocks, so along an arm each agent holds four consecutive steps, then two, then one as the team doubles. At the top of each arm every agent owns exactly one step, so nobody is idle and any slowing of coordination growth cannot be the team running out of work. The sixteen-step arm was collected as one interleaved batch over three days, with team sizes balanced within each day so the round-robin protects the size comparison, and it is not a cross-session replication. The remaining 82 runs are pilots (small trial batches run before the full schedules) and methodological checks, giving 1,902 runs in the main collection; a further 244 runs form the sealed replication of Section 9. Grading. Every task ships with a reference solution, and a fixed suite of behavioural input/output tests grades the teamās deliverable against outputs fixed in advance55 5 22 tests for Experiment 1ās task, 25 for Experiment 2ās main task; the longer chains carry their own suites.. The tasks are pure functions with no randomness, and comparison is exact. The test suite is placed outside each agentās working directory; in the main collection that placement was not otherwise access-controlled, and Section 9 reports what the teams did with the access and re-runs the load-bearing cells under a seal that removes it. A run succeeds only if every test passes, so success is unambiguous while the path to it varies. Environment and release. All runs use Claude Code (the 2.1.x series) with the model pinned to claude-sonnet-4-6 and logged, unchanged, on every turn. The dataset, the task generators, the pipeline, and every analysis script are released as a replication package. Statistical approach. The unit of analysis is the run: one graph, one pass/fail outcome. Success rates carry ClopperāPearson exact 95% intervals [8]; success contrasts use Fisherās exact test [12], continuous contrasts the MannāWhitney test [23], and each set of related contrasts is corrected with the BenjaminiāHochberg procedure [2], reported as pBHp_BH. Eight hypotheses (H1āH8) are stated in advance; six are pre-registered in both prediction and test (H1, H4āH8), while H2 and H3 carry qualifications set out in Appendix A. The appendix lists all eight with their outcomes, and the findings cite them by number. At ten runs a single cellās success rate carries a margin of roughly thirty percentage points, so single-cell readings are directional and the pooled contrasts carry the inferential weight. 4 Finding 1: the Quadratic Cost of Scale is Mostly a Handshake Table 1: Mean edges per run as the team grows (flat team, collection B, files allowed, clean split, Experiment 1; ten runs per row). Messages rise steeply and file writes barely move. The file-read count at eight agents (38.8) is not a coordination signal: most of these reads are outside the workspace, the agents opening the reference solution, the hidden tests, and other runsā files (Section 9); genuine reads of the teamās own workspace are about fifteen per run. Cells are drawn from collection B alone; Section 8 reports how far the two collections differ. agents success messages file writes file reads 2 10/10 6.1 3.0 2.5 4 10/10 28.5 4.5 3.3 8 10/10 71.3 6.9 38.8 If every agent must talk to every other, messaging scales as n2n^2 with team size, and the cost of coordination soon dominates the cost of the work. The first half of that picture holds in our data. Table 1 shows messages per run rising from 6.1 at two agents to 71.3 at eight. Throughout the paper we quantify such growth by fitting a line to message count against team size on log-log axes; the slope of that line is the growth exponent, 1 for linear growth and 2 for quadratic. On the chained task the exponent is 1.92, quadratic within error, and the two collection sessions agree to two decimal places (1.92 and 1.93). The pre-registered H1 test, a regression over the three cell means, gives 1.92 with an interval of [1.67,2.17][1.67,2.17] (Ā±1.96āSEĀ± 1.96\,SE, the pre-registered testās normal approximation); the per-run regression we use for scaling elsewhere in the paper gives the same 1.92 with a tighter interval, [1.80,2.05][1.80,2.05]. Both confirm quadratic scaling. On the distributed task the growth is also steep but not stable across sessions, a point Section 8 takes up. Figure 4 plots both experiments and the two scaling arms together. Figure 4: Messages per run against team size on log-log axes, with an n2n^2 reference (grey dashed); cells are drawn from collection B. What to notice: Experiment 2 tracks the quadratic reference (slope 1.92); the eight-step arm bends away from it after four agents; the sixteen-step arm goes flat between eight and sixteen. The quadratic growth ends within the measured range of team sizes. The second half does not hold, and the timestamps show why. The growth is a round of introductions, made once, early. We read this from timing and message counts, because the instrument does not capture message content; introduction here simply names a pairās first contact. Two measurements separate this opening handshake from the coordination that lasts. First, the messages per pair fall as the team grows, from about three messages per ordered pair at two agents to 1.27 at eight. The total rises only because there are more pairs; each pair talks less. Second, the introductions come early in the run; the sustained traffic comes later. We place each runās messages on a normalised timeline, with Ļ=0Ļ=0 the runās first message and Ļ=1Ļ=1 its last, and report the mean over runs of the time by which ninety per cent of a runās pairs have appeared. On the distributed task, in one collection session, ninety per cent of the distinct sender-to-recipient pairs a run will ever use have appeared by Ļā0.2Ļā 0.2 at every team size (Figure 5); in the other session the eight-agent handshake stretches to Ļā0.6Ļā 0.6, so how early it completes is itself session-dependent. The chained task completes its handshake early at four and eight agents in both sessions; at two agents, in one session, ninety per cent of pairs appear only around the middle of the run (Ļā0.46Ļā 0.46). What holds everywhere is the ordering, introductions first, then repeat traffic on a small established core, with the sustained channels running through the middle and second half of the run. Messages also get shorter as teams grow (mean size falls at every step in team size), so per-channel coordination thins on two axes at once. Figure 5: The handshake in time. Each curve averages, across timing-eligible runs that contain at least one named directed pair, the per-run cumulative fraction of the sender-to-recipient pairs a run eventually uses that have appeared by normalised time Ļ; one line per team size, one panel per experiment and collection session, the dotted line marking 90%. What to notice: most pairs appear early, though the mean per-run 90% arrival time varies from about 0.14 to 0.60 across team sizes and sessions, the session dependence Section 8 measures. The axis runs from the first message to the last, so it says nothing about where the run itself ends. The scaling arms close the argument, because each was collected as one interleaved batch with no idle agents and a decision rule fixed in advance. On the eight-step chain the slope falls from 1.82 between two and four agents to 0.72 between four and eight; at ten runs per cell the fall is in the predicted direction but not significant (hypothesis H7, Appendix A). On the sixteen-step chain the growth stops outright: mean messages are 21.4, 47.0, and 46.8 at four, eight, and sixteen agents, the slope between eight and sixteen is 0.00 (95% CI [ā0.34,0.34][-0.34,0.34]), and the break is significant (Ī=1.08 =1.08, 95% CI [0.61,1.55][0.61,1.55]), confirming hypothesis H8. Because that chain is fully divided only at sixteen agents, the plateau cannot be the team running out of work. Instead the team changes how it addresses itself: past eight agents, messages aimed at one named peer fall from 34.6 to 12.2 per run while broadcasts, messages sent to the whole team at once, rise from 12.3 to 34.0, and twelve of the twenty allowed sixteen-agent runs coordinate by broadcast alone. A large team stops addressing peers one at a time and speaks to the room. Summary. Adding an agent adds one more introduction, while the lasting per-agent coordination barely grows, and on the largest teams the messaging cost of growth falls to zero because the team switches to broadcast. The task sets the shape of the lasting traffic (Section 5). A budget or a topology designed for sustained all-to-all messaging provides for traffic the teams do not produce. 5 The Task Shapes the Network The handshake of Section 4 says how much messaging there is; it does not say what shape the messaging settles into. To read the shape we build, for each run, its sustained undirected graph: two agents are joined by an edge when at least one direction between them carried two or more messages during the run, so an edge marks a channel the pair used more than once; a single greeting does not count. We then measure two properties of that graph and average them over a cellās runs. The first is the mean degree, how many live partners the average agent keeps, read against the clique line nā1n-1 that all-to-all coordination would draw. The second is the global clustering coefficient (transitivity), the share of an agentās partner-pairs that are themselves joined; it lies near 1 when the live partners form one tightly interconnected group and near 0 when they do not link to each other. Appendix A.3 gives the exact definitions and thresholds. The shape is set by the task, and the two tasks settle on opposite shapes (Figure 6). Both quantities are averaged over every configured agent and every run in a cell, so an idle agent counts as degree zero, and a run with no named-message network counts as zero and stays in the average; Appendix A.3 gives the estimator. On the distributed task, where every agent holds a fragment of one shared specification, the graph rides the clique line and fills in. Mean degree is 0.90, 2.92, and 5.47 at two, four, and eight agents, against clique lines of 1, 3, and 7, and clustering is high once the team is larger than a pair (0.96 at four agents, 0.81 at eight). Reconciling one specification pulls the team towards talking to everyone, and those partners also interconnect, so the sustained graph is a near-complete, tightly clustered mesh. On the chained task, where each agent owns consecutive steps of a pipeline, the graph stays sparse. Mean degree is 0.90, 1.57, and 2.99 at the same sizes, so the gap to the clique line widens as the team grows, and clustering stays low (0.36 at four agents, 0.38 at eight). A pipeline needs each owner to agree interfaces only with its neighbours, and the sustained graph records that local structure. The sixteen-step chain, the only configuration that reaches sixteen agents, has the widest gap: the average agent sustains just 0.28 partners against a clique line of 15, and clustering falls to 0.03. Only 8 of the 20 sixteen-agent runs carry any named agent-to-agent messaging at all; in the rest the named-peer network has gone quiet: the messaging that remains is broadcast, sent to the whole team at once (Section 4), and the coordination that is not in messages has moved to files (Section 6). Growing the team does not grow the named-peer network towards all-to-all; it stretches a sparse, chain-shaped graph thinner until, at sixteen agents, almost none of it forms. Figure 6: The shape of the sustained network is set by the task, on the flat, allowed-policy, clean-split runs (both collection sessions pooled). Left: mean degree of the sustained undirected graph (a pair is joined once either direction has carried at least two messages) against the clique line nā1n-1 (black dashed), with standard-error bars; each two-, four-, or eight-agent point averages the two ten-run collection cells. Right: the global clustering coefficient of the same graph; at two agents it is zero by construction, since three agents are needed for a triangle. The open diamond is the chained sixteen-step scaling arm, the only sixteen-agent data. What to notice: the distributed task (blue) tracks the clique line and clusters tightly; the chained task (green) stays sparse and its gap to the clique line widens with team size; there are no sixteen-agent distributed runs. Neither shape has a leader. The distributed mesh is dense but flat: no agent holds a disproportionate share of the sustained edges. Filtering each runās message graph to the channels that carry significantly more than an even spread (a disparity-filter backbone, Ī±=0.05Ī±=0.05) leaves essentially no edges, 0 of 1,170 at eight agents on the distributed task and 2 of 1,077 on the chained task, and Section 7 shows that naming a coordinator does not change this. The dense graph is dense everywhere and the sparse graph is sparse everywhere; neither concentrates on a hub. Whatever the task, the structure the team builds is leaderless. A directed version of this measure gives a narrower picture. If one counts, for the average agent, the number of distinct peers it sends two or more messages to (a directed out-degree, normalised across all agents), the count is smaller and varies by experiment and session, roughly two to five at eight agents (Figure 7). It is a partial measure. On the chained task it stays around two; on the distributed task it is about three in one collection and five in the other, and in the second it comes close to the undirected degree of 5.5. The directed count describes how many peers an agent actively pushes to, which is generally fewer than the undirected connectivity, though it is a range, varying by experiment and session. Figure 7: Mean directed out-degree against team size when edges are filtered to ordered pairs where the sender pushed at least t messages, against the clique line nā1n-1 (black dashed). What to notice: on the distributed task the once-only graph (light, tā„1tā„ 1) tracks the clique; the sustained directed graph (tā„2tā„ 2 and above) grows more slowly, to between about two and five per agent at eight agents depending on experiment and session (5.0 and 3.0 on the distributed task, about two on the chained). The participant series normalises over the agents that sent any message, the team series over all N agents. This is an out-degree, and it sits below the dense undirected graph of Figure 6 on the chained task and in one distributed session, though it approaches it in the other. Summary. Left to organise themselves, the teams do not converge on one coordination span. The distributed task builds a dense, tightly clustered mesh that rides the all-to-all line; the chained task builds a sparse graph whose gap to all-to-all widens with team size; and neither has a hub. The shape of the coordination network is a property of the task, read directly off the graph. 6 Finding 2: Files are the Cheaper Channel, Where Messaging Would Dominate The shape of the network is one half of the coordination cost; the channel it runs on is the other. A direct message reaches one recipient, so telling the whole team something means repeating it. A shared file is written once and read by many. The file policy of Section 3 turns this difference into an experiment: the same tasks run with coordination files forbidden, allowed, or mandatory. Figure 8: Where the coordination tokens go, by channel and policy (both experiments; 90 runs per bar group). The bars are proxies on two different bases: the message bar is the message length (about four characters per token), the file bars are the originating turnās output tokens shared across its tool calls, and neither counts cached context. They therefore show only the direction of the channel shift; the run-level output-token totals in the text use the modelās reported figures. What to notice: under mandatory, message tokens collapse and file tokens grow in both experiments. Output falls overall only in Experiment 1; in Experiment 2 the files already carry the coordination, so the rule only adds overhead. Under forbidden the file bars are the deliverable itself, which the team must write: every write in those runs goes to the deliverable (270 of 270 multi-agent runs in Experiment 1), and the bars are non-zero because the same file is created and revised several times per run. Mandating files changes where the coordination happens. At eight agents on the distributed task, the tokens attributed to direct messages fall from about 10,500 per run under the allowed default to 1,700 under mandatory, while file-write and file-read tokens roughly double (Figure 8). The two figures are measured differently, the message tokens from message length and the file tokens as a share of the turnās output (see the caption), so the decomposition shows only the direction of the shift; the direction is corroborated by the message count itself, which collapses under the policy, and by the run-level totals below. On the distributed task under the mandatory policy the distinct files a run touches grow with the team, from 3.2 at two agents to 11.9 at eight, and the pre-committed main effect, that mandatory adds file coordination while forbidden and allowed look alike, holds in both experiments (hypothesis H4). The saving, however, belongs to one task shape, and we state it in the modelās output tokens, which the runās logs report directly. On the distributed task the mandatory policy cuts output tokens by about 25% at four agents and about 42% at eight below the allowed default, with all team structures and splits pooled at each size (the eight-agent cut spans 36% to 49% across the two collection sessions). Output is only part of what a run consumes: most of the token throughput is cached context re-read on every turn, about 10.5 million tokens per run at eight agents under the allowed policy over the flat cells, which the run totals do not price, and the runs were collected on a subscription, with no per-token metering. The saving is not an artefact of the output-only view, since mandating files cuts the cached throughput as well, to about 6.6 million tokens per run. At API list rates for output alone, the eight-agent cut corresponds to roughly $4.3 versus $2.5 per run, an illustration of the output saving. On the chained task the same rule raises output tokens, by about 17% at four agents and 10% at eight. The direction of the difference is the finding, and it makes the rule conditional: Experiment 1 teams left to themselves coordinate by one-to-one messages, so replacing that channel with files removes repetition; Experiment 2 teams already pass their work through files, each stepās output read by the next, so mandating more file traffic only adds overhead. The sixteen-agent arm marks the limit sharply: with files already carrying the coordination, the mandatory rule roughly doubles per-run tokens (578k against 333k) and more than triples file reads, for identical success (10 of 10 against 20 of 20). Figure 9: Coordination cost by channel against team size, log-log, under allowed (left) and mandatory (right), for the distributed task (top) and the chained task (bottom), all from collection B; the grey dashed line is n2n^2. Legend: M_dir == messages aimed at one named peer, W == file writes, R == file reads, C == all coordination edges together; the number after each is its fitted growth exponent. What to notice: directed messages track the quadratic wherever the teams use them; on the distributed task the mandatory policy moves the total from near-quadratic (exponent 1.70 to 2.11 across sessions) towards linear (1.12 to 1.32). The file-read channel itself is still super-linear there (ā1.7ā 1.7): the total is near-linear because directed messaging is switched off. Only the chained taskās file channel is linear by construction. The channel view explains the scaling as well as the totals (Figure 9). The near-quadratic growth of Section 4 belongs to the one-to-one message channel. Route the same coordination through shared files and the total-coordination exponent on the distributed task (all coordination edges, distinct from the messages-only exponent of Section 8) falls from 1.70ā2.11 across sessions towards linear, 1.12ā1.32; the cleanest reading, the eight-step chain at full decomposition where no agent is idle, gives n0.98n^0.98, linear within error. One caveat applies: on the distributed task the file-read channel alone still grows super-linearly (about 1.7), so the linearisation comes from removing the message channel, and the fully linear file regime is a property of chain-shaped work. The policy also sets the runās shape in time. Messaging leads file writing (comparing each runās mean message time with its mean file-write time) in 86% of allowed distributed-task runs, 62% under forbidden, and 17% under mandatory, where files must exist before anything can read them; a quarter of the mandatory runs (about a third at four and eight agents) send no message at all and drop out of this measure, so the 17% describes the minority that still message. The chained task writes files first under every policy (messaging leads in only 12% to 14% of runs), even though its prompt asks agents to coordinate through messages. A sequential task settles its interfaces by writing them down, whatever it is told. Summary. Files are not passive outputs; they are the one-to-many channel, and the cheaper one wherever one-to-one messaging would otherwise dominate. The practical rule is conditional, and the graph tells you which side of it a task sits on: if the teamsā own coordination is message-heavy, mandate files and save; if it already flows through files, leave it alone. 7 Finding 3: Naming a Coordinator Does Not Create Structural Leadership The simplest way to assign leadership to an agent team is a sentence in a prompt. In the coordinator condition one agent, and only that agent, is told it is the coordinator. If the label works, the communication graph should show it: traffic concentrating on the coordinator, and success rising on the tasks that need arbitration most. Neither happens. No hub forms under either condition: filtering each runās message graph to the channels that carry a disproportionate share of an agentās traffic (a disparity-filter backbone, Ī±=0.05Ī±=0.05) leaves 0 of 1,170 channels at eight agents on the distributed task and 2 of 1,077 on the chained task, and the same holds at four agents. A pre-committed null on the chained task also finds no difference in directed traffic at four agents in the pre-registered session (12.9 against 16.3 messages, p=0.29p=0.29). Whatever the prompt says, no communication hub emerges in either task. Nominal leadership does not become structural leadership. Table 2: Success on the conflicting split (Experiment 1), where two agents hold contradictory validation rules, by team size, policy, and structure; files-allowed and the other policies shown separately, ten runs per cell. Collections A and B are the same flat configuration collected twice. agents policy flat A flat B coordinator 4 forbidden 8/10 8/10 7/10 4 allowed 7/10 5/10 8/10 4 mandatory 7/10 5/10 8/10 8 forbidden 10/10 10/10 6/10 8 allowed 8/10 10/10 8/10 8 mandatory 9/10 9/10 9/10 Success tells the same story once the two flat collections are pooled (Table 2). The pre-registered prediction was that a coordinator helps on the conflicting split, where two agents hold rules that disagree and someone must arbitrate. Success on this split measures arbitration only imperfectly: the grader silently enforces one of the two rules, so a team that arbitrates cleanly still fails if it agrees on the other, and the outcome mixes arbitration with landing on the enforced convention (the reference uses the stricter rule, that a zero quantity is invalid). At four agents the coordinator looks better (8/10 against the collection Bās 5/10), but pooling the two flat collections dissolves the advantage (8/10 against 12/20, p=0.42p=0.42), and at eight agents the direction reverses: the flat team matches or beats the coordinator at every policy. The one contrast that survives correction across the six conflict cells is a reversal, flat 20/20 against coordinator 6/10 under forbidden (pBH=0.046p_BH=0.046). This contrast does not reproduce once the grading suite is placed out of the agentsā reach: the sealed replication of Section 9 runs the same eight-agent conflict cells and finds flat and coordinator teams level under every policy, so we treat the reversal as an artefact of the uncontained collection. On the chained task the coordinator with a free file channel is the weakest cell in the experiment (1/10). The pre-registered within-experiment comparison of the two topologies on the conflicting split is inconclusive (hypothesis H3); the cross-experiment interaction reported here (p=0.24p=0.24) is an exploratory test, outside the pre-registration (Appendix A). A flat team is no cure either. At two agents on the conflicting split, flat teams fail 37% of their runs pooled across policies (up to half in the weaker session), while coordinating through the same channels as everyone else. Resolving a planted disagreement is not a matter of communication volume. Figure 10: Success by team structure and split, under the allowed (default) file policy, with ClopperāPearson 95% intervals. Flat pools the two collection sessions (N=20N=20 per point); coordinator has N=10N=10. What to notice: at four agents the coordinator leads on the conflicting split (top left); at eight agents it no longer does (top right). In Experiment 2 (bottom) success follows the split, whatever the team structure, and the coordinator is the weakest point of all on the conflicting split at four agents (1/10). The sharpest failure has no leader and no fix by talking. The eight-step chain (compute_invoices) succeeds in nine of ten runs at two and four agents, then fails all ten at eight agents, where each agent owns exactly one step. Every failure sits on the same seam, between compute_tax (step 7) and format_invoices (step 8): round at each step, or once at the end. The specification settles it, compute_tax is told to pass its tax on unrounded and format_invoices to round every figure once at the end, so the two agents each hold one half of the convention. At two and four agents one agent owns both steps and reconciles the halves internally; at eight agents the seam falls between two different owners and no agent holds responsibility for it. The teams were not silent: the run transcripts show rounding discussed in all ten of the eight-agent runs, and those teams messaged more than the four-agent ones. Talking more did not close an interface that nobody owned. The mismatch is invisible to each agent, whose own step is correct, and invisible in the finished code, which runs. Diagnosing it draws on the specification, the identical failure across the runs, and the transcripts, none of which is the graph; what the coordination graph adds is the structural signature, that at eight agents the seam falls on a boundary between two different owners, an interface no single agent sits across. Beyond structure, no single network property buys success. Exploratory run-level regressions point one way, more messaging and writing go with failure and longer runs, more reading with success and shorter ones, but the associations explain about a tenth of the variance and the causality is open, since a run that goes well needs less repair traffic. The networkās shape records how a run went more than it predicts how it will go. Summary. A coordinator exists only where the interaction structure carries the role, and a prompt clause alone does not create that structure. Decomposition creates interfaces between agents, every interface needs an owner, and the graph shows which interfaces have none; those are where the teams break. 8 How Far to Trust One Run: Reliability of the Measurements The flat condition was collected twice under byte-identical prompts, giving 54 matched cell pairs that are exact same-configuration replications under one pinned model. These replications quantify the reliability of the instrument. Where a task pins the coordination down the two sessions agree closely, showing that the instrument itself can reproduce consistently; where a task leaves the coordination open the spread between sessions is considerably larger and itself task-dependent, which uniform measurement noise would not produce. Figure 11: Test-retest reliability: each point is one matched cell, with the two sessionsā mean messages per run on the two axes; open markers differ under a BenjaminiāHochberg correction across each taskās cells. What to notice: the chained task (green) hugs the diagonal, with no cell differing after correction; the distributed task (blue) scatters off it, with thirteen of twenty-seven differing. Reproducibility under a fixed model depends on the task. Reproducibility is task-dependent (Figure 11). On the chained task the sessions agree almost everywhere: no matched cell differs once the twenty-seven comparisons are BenjaminiāHochberg corrected (one differs at the raw level), and typical cell means move by about seven per cent. On the distributed task thirteen of twenty-seven cells differ after the same correction, one of them by a factor of fifteen in messaging (31.4 against 2.0 messages per run at the same configuration). File activity swings too: at eight agents under the allowed policy, one sessionās teams touch 18.0 distinct files per run on the conflicting split and the otherās touch 4.3. This is why the distributed taskās scaling exponent is a range, 1.76 (95% CI [1.57,1.96][1.57,1.96]) in one session and 2.44 ([2.32,2.57][2.32,2.57]) in another, with non-overlapping intervals, and why the handshake completion time in Section 4 is reported per session. The chained taskās exponent, meanwhile, replicates to two decimal places. The pattern in where the divergence lands explains it. The cells that drift are the high-coordination ones, where the task leaves the team the most freedom in how to organise; the cells that reproduce are those where the task pins the coordination down, as a chain does. The gap is not elapsed time between sessions, since the chained pairs span a longer wall-clock gap than the distributed ones and still reproduce. Summary. Under a fixed model identifier, a multi-agent configuration is characterised by a distribution of runs. Where the task leaves coordination open, single-run benchmarks of multi-agent systems measure a sample of size one from a wide distribution. Any instrument for these systems has to be used with repetition, and any headline number should carry its cross-session range where matched sessions exist, as ours do. 9 Containment and What the Teams Reach For The runs analysed above were collected in an environment that did not confine the agents to their working directory. For each run the grading suite and the reference solution sat in sibling directories, and the runās manifest recorded their paths. A validity check made after the main collection found that the agents used this access: they opened the hidden test suite in 234 runs and read the reference solution in 77, the reach most common in the eight-agent conflicting cells. The same access reached further than the grading files: through the file tools, agents opened another agentās private prompt in 129 runs, read a different runās files in 18 (a finished solution in 16 of them), and read the shared message log in 52; shell-mediated reads, which the graph does not capture, would raise each of these counts. No prompt forbade reading these files, and none asked for them; the only stated constraint concerned which files a team could create. The agents went looking on their own initiative and reported what they found openly. The reachable files are a containment gap in the setup; the looking is the agentsā own behaviour, measured directly under the seal below. The gap does not on its own decide the findings. The confirmatory results survive when every run with such a read is dropped, and the file-policy saving of Section 6 is largest in the runs with no out-of-workspace read and smallest in the most-affected third when the affected runs are grouped by read count (46% against 41% across all affected runs and 37% in the most-affected third), so the access dilutes that effect and cannot account for it. To settle the matter directly we re-ran the load-bearing cells in a sealed environment. The seal. Each runās working directory was placed on its own, with the grading suite, the reference solution, the manifest, and the other agentsā prompts held outside it. Where the grading suite and the prompts used to sit we left decoys of the same names, each carrying a marked placeholder and none of the real content. Where the manifest used to sit we left a copy stripped of its grading pointers, the paths to the test suite and the reference solution; the copy still lists the teamās component assignment, as the original did in the main collection, but nothing that grades the work. An agent that reached for the hidden material therefore found a file where it expected one, read a placeholder, and left a record of the attempt. The real files remained in place for the duration of each run for scoring, and each finished runās sensitive files were cleared before the next run began, but the relocation sends the reach the agents actually used, always a relative path out of the workspace, onto the decoy instead. Every read made through the file tools was logged and classified by location; we count the seal as holding only when no such read reached a real file, and we discarded and re-ran any run in which one did. In the event no run was discarded for such a read; four runs were discarded and re-run for agent timeouts. The seal therefore functions as a tripwire that defeats the observed reach pattern and records every tool-mediated attempt. It stops short of an enforced sandbox: a read issued through the shell would not be captured, and the runs execute under a permissive filesystem mode. The sealed batch is 244 runs at eight agents on the distributed task, covering the six conflicting-split cells (flat and coordinator under each file policy) and the two clean-split file cells, on the same pinned model and with the grading suite byte-identical to the released one. No tool-mediated read reached a real file in the runs we kept. The teams reach for the answers. The decoys turn the reach into a measurement. With the real material replaced by a placeholder and nothing to gain, the teams still went looking for it: in 80% of the sealed runs an agent opened the decoy standing in for the hidden test file, in 66% it opened another agentās prompt, and in 61% it opened the run manifest. No prompt asks for any of these files; the test-file and prompt reads return only a placeholder, and the manifest read returns no grading material, so the reach for the test file is an unprompted tendency to seek out the grading material. It is the kind of reward-seeking that grade-only evaluation cannot see [27, 21, 36, 13], and it makes the containment gap in the main collection unsurprising in hindsight: agents that look for the answer key when they are confined will read it when they are not. The findings hold under containment. With the real material replaced by decoys, the two findings that these cells test reproduce. Naming a coordinator again makes no difference to success: flat and coordinator teams are level under every file policy (forbidden 20/30 against 21/32, p=1.00p=1.00; allowed 26/31 against 23/31, p=0.53p=0.53; mandatory 23/30 against 25/30, p=0.75p=0.75). The single reversal reported in Section 7, the flat team beating the coordinator under the forbidden policy, does not reappear, so it is best read as an artefact of the uncontained cells. The channel substitution of Section 6 holds as well: mandating files collapses one-to-one messaging, from 108 messages per run under forbidden and 134 under allowed to 26 under mandatory on the conflicting split, and from 119 to 21 on the clean split, the same move from the message channel to the file channel measured in the main dataset. 10 Threats to Validity Construct. The file graph captures tool-mediated file activity only. Edges come from the runtimeās Read, Write, and Edit tools; a file operation issued through the shell leaves no edge. In the main collection this cost ten runs their recorded write, because their deliverable was created with a shell command, which leaves no edge, so file activity is undercounted in about 0.6% of runs. This is an undercount, so the sparse file structure we report is conservative: any unlogged operation would only add edges. The per-channel token figures are proxies on two bases. Token cost on file edges divides a turnās output evenly across its tool calls, while token cost on message edges is estimated from message length, so the two are not a like-for-like total and the channel bars of Figure 8 show direction only; the run-level output-token results use the modelās reported totals and are independent of the division, and the direction of the channel substitution survives any monotone re-attribution within a turn. The reported token totals count input and output only, excluding the cached context re-read on each turn, which is the bulk of the throughput; the output saving of Section 6 holds on the cached tokens too, and the runs were collected on a subscription, so we report token reductions. The coordinator is a prompt clause with no enforced routing, so Section 7 measures the effect of nominal leadership; an enforced star topology is follow-on work, and the distinction is the point of the finding. The two experiments also differ in one prompt detail: Experiment 2ās prompt asks agents to coordinate through messages, and its file-first behaviour runs against that instruction, so the cross-experiment contrasts are conservative with respect to it. Internal. The agents are stochastic and a model identifier does not fix the providerās state. Every cell carries ten repetitions, the model identifier is logged per turn (no mid-study change occurred), and within a batch a regression of messaging on run order shows no drift. Between sessions the measurements do vary, and we analyse this variation explicitly in Section 8 and report session ranges. At eight agents the clean main-matrix cells leave four agents idle, and the four-agent break coincides with the tasksā four-unit structure; the two scaling arms were built without either confound and reproduce the deceleration and the plateau. The main collection also did not confine the agents to their workspace, and Section 9 quantifies that access, shows the confirmatory findings survive the exclusion of every affected run, and re-runs the load-bearing cells under a seal that removes it. External. The numbers come from two synthetic Python tasks, one runtime, and one pinned model, and the specific values will not carry directly to other settings. The claims we generalise are structural: the handshake-then-core shape, the one-to-many economics of files, and the gap between nominal and structural leadership. The graph schema and parser apply to any runtime that logs tool calls and messages; tasks from real repositories and other models are the natural replication. Conclusion. Confirmatory claims rest on hypotheses pre-registered in both prediction and test (H1, H4āH8), with BenjaminiāHochberg correction within each contrast set; H2 and H3 carry the qualifications set out in Appendix A, and the appendix also records that the pre-registered top-up rule flagged cells we did not top up. Power is the limit: at ten runs a cellās success rate carries a margin of roughly thirty percentage points, so single-cell readings are directional and pooled contrasts carry the weight. H7 met its pre-committed power-limited branch and is reported as directional; H8, at twenty runs per cell, reached significance. 11 Related Work Work on multi-agent LLM systems evaluates them, almost without exception, by their outputs. Benchmark studies score end-task success across frameworks and team configurations: MultiAgentBench evaluates different coordination topologies and, in an ablation study, different team sizes, and measures task completion and coordination performance [38]; software-engineering studies compare role-specialised teams with single agents based on the functional correctness and requirement coverage of the delivered software [9, 33]; a controlled comparison across 260 configurations evaluates each one using benchmark-specific measures of task performance [20]. Cost studies measure the tokens agentic workflows consume and how cost varies with task difficulty, and argue that cost belongs beside accuracy in agent evaluation [19, 31, 1]. Studies of failure catalogue the ways multi-agent pipelines break, from mis-specification to inter-agent misunderstanding: MAST derives fourteen failure modes from execution traces [7], attribution work asks which agent and which step caused a failed run [35], and a study of code-generation teams attributes three quarters of the failures it analyses to the boundary between planner and coder [22]. All of this looks at finished run: a grade, a bill, or a post-mortem of the transcript. A second line of work designs the communication structure in advance: which agents may talk to which, in what order, and through what roles. ChatDev and MetaGPT assign fixed roles and pass work along a prescribed order [29, 16]; multi-agent debate fixes who reads whom and for how many rounds [10]; MacNet arranges agents into chains, stars, trees, and meshes and compares the arrangements [30]; GPTSwarm and AgentPrune treat the communication graph itself as a quantity to optimise or prune [39, 34]. In every case the topology is an input: the system fixes or searches the structure and then scores the outcome, so the coordination that happens inside the structure goes unmeasured. When communication is examined at all, it appears as raw message logs or token counts, and the structure, the timing, and the file activity that carry much of the coordination stay out of view. Our experiment leaves the channel open: any agent may message any other under every configuration, and the topology is a result the instrument recovers (Section 5). What is missing is an instrument: a way to observe the coordination structure that emerges during a run, on the same footing for messages and for shared artefacts, and comparable across team sizes, configurations, and frameworks. Network analysis provides the natural language for this, and it has a long record in software engineering. Developer networks mined from version histories predict failure-prone components [28, 24], and combining the contribution network with the technical dependency network predicts them better than either alone [3]. The socio-technical congruence tradition compares the coordination a projectās dependencies demand with the coordination its records show [6, 5]. Longitudinal network studies expose team structure itself: developer coordination networks in large open-source projects organise into stable cores and loosely connected peripheries as they evolve [18, 17]. All of these networks are recovered from repository artefacts after the fact, at the granularity the commit record allows; even time-stamped co-editing networks are reconstructed from Git histories once the commits exist [14]. Multi-agent runs permit something stronger: every message, write, and read made through the runtimeās tools is a logged event, so the temporal network of a collaboration can be recorded directly from the trace as it happens. This paper supplies that instrument. It differs from output-based evaluation in what it measures (the coordination itself), from failure analysis in timing (the run is recorded as it unfolds, before its outcome is known), from topology design in direction (the network is an observed outcome), and from mined developer networks in resolution (every edge is an exact, timestamped event). The closest prior threads, on span of control and group-size limits in human organisations [15, 25, 11, 37], return in Section 12, where the measured limits on sustained coordination invite the comparison. 12 Conclusion Multi-agent AI coding systems are evaluated by their outputs, but they succeed or fail by their coordination, and the coordination is invisible in the output. This paperās contribution is to make it a measured object: a temporal network in which agents and files are both nodes and every message, write, and read logged by the runtimeās tools is a timestamped, costed edge. The graph is a direct record of that tool-mediated activity, cheap to collect from existing logs, and comparable across team sizes, configurations, and frameworks. Measured this way, the three configuration choices a developer faces come out differently from what output-level evaluation suggests. The quadratic cost of communication is real but shallow: it is an opening handshake, made once, after which each agent sustains a few channels, no hub forms, and the largest teams switch increasingly to broadcast and messaging growth levels off between eight and sixteen agents. Files, usually treated as outputs, are the teamās one-to-many channel, and requiring their use cuts output tokens by about 42% at eight agents on message-heavy work, while adding cost on chain-shaped work whose files already carry the coordination. And leadership assigned by prompt is nominal only: it creates no structure and buys no reliable success, and a sealed replication of the eight-agent conflict cells leaves flat and coordinator teams level under every file policy. The common thread is that what the prompt declares and what the interaction structure builds can differ, and the measured outcomes follow the second. Beneath those choices, the shape of the coordination network is set by the task. Left to organise themselves, the teams do not converge on a single coordination span. The distributed task, where everyone reconciles one shared specification, builds a dense, tightly clustered graph that rides the all-to-all line; the chained task, where each agent agrees interfaces only with its neighbours, stays sparse, down to a mean degree of 0.28 against a clique of fifteen at sixteen agents, where scarcely any named-message network forms at all. Neither has a hub. In our experiments, the structure a team builds is a property of the work it is given, read directly off the graph. The two collections also reveal the reliability of the measurements. Under one pinned model, the chained taskās measurements replicate across sessions to two decimal places while the distributed taskās exponent moves from 1.76 to 2.44, so a configuration is a distribution of runs, and single-run evaluations of multi-agent systems stand on a sample of size one. And the measurements see what grading cannot: an eight-step calculation split one step per agent failed every run on a rounding convention that sat between two agents and belonged to neither, discussed every time and never settled. Decomposition creates interfaces between agents, each interface needs an owner, and the graph shows which have none. The instrument also caught a behaviour that grading hides. The main runs were not confined to their workspace, and the teams used the access: they opened the hidden grading suite in 234 runs and the reference solution in 77. A sealed replication of the load-bearing cells, with decoys where the real files had sat, both confirmed the two findings it re-tested under containment, the coordinator null and the message-to-file substitution, and measured the behaviour directly: in four fifths of the sealed runs the agents reached for the grading suite even though it returned nothing, an unprompted search for the answer key that only a record of coordination, and not a grade, can see. There is a resonance here with a long literature on the limits of human coordination. Spans of workable oversight have been placed at around five direct reports by Graicunas [15] and near seven items by Miller [25], while Dunbar links group size to limits on the relationships that can be monitored [11], and human group sizes cluster near five and fifteen in Zhou et al.ās analysis [37]. Our agent teams sustain a limited number of one-to-one pushes, roughly two to five peers per agent by the directed out-degree of Section 5, in the range of those figures, and in the sixteen-step arm messaging growth halts between eight and sixteen agents, which invites the comparison. The topology result cautions against reading it as a shared cognitive span. Left free, the agents do not settle on one span at all: where the task calls for it they build a dense near-clique, and where it does not they stay sparse. Human hierarchies may owe as much to the cost of adding people and the distribution of authority as to any limit on coordination itself; here, adding agents still carries coordination cost, but formal authority is minimal, and the pyramid does not return. What remains and still binds is the cost of coordination. We claim no shared mechanism, and our design cannot place the growth break more precisely than the eight-to-sixteen interval, but if coordination structure is subject to similar economics wherever it arises, machine teams are a way to study those economics with an exactness that is difficult to achieve in human organisations. The framework, the pipeline, and all 1,902 main-collection runs, together with the 244 sealed replication runs, are released for replication. The next steps are the ones the instrument makes possible: naturalistic tasks from real repositories, other models and runtimes, the handshake as an early-warning signal for failing runs, and the cross-team setting where separate agent teams share no message bus but do share a repository, so the files, already first-class nodes here, carry all the coordination there is to see. Data Availability The replication package, containing all 1,902 runs as CSV datasets, the task generators, the instrumentation pipeline, and every analysis script behind the numbers and figures in this paper, is released at https://github.com/giuseppedestefanis/when-agents-coordinate. The 244 sealed replication runs of Section 9 are released alongside it, together with the seal implementation and the script that classifies each read by location. The pre-registration records are included, so each committed prediction and decision rule of Appendix A can be checked against the analysis it governs, including the top-up decision plan and the qualifications on H2 and H3; the decision-rule bodies are the committed versions, and the package notes where a scaling-arm recordās status header was updated after collection. Each reported statistic can be regenerated from the released data without rerunning any agent. References [1] L. Bai, Z. Huang, X. Wang, J. Sun, R. Mihalcea, E. Brynjolfsson, A. Pentland, and J. Pei (2026) How do AI agents spend your money? Analyzing and predicting token consumption in agentic coding tasks. Note: arXiv:2604.22750 Cited by: Ā§A.4, Ā§1, Ā§11. [2] Y. Benjamini and Y. Hochberg (1995) Controlling the false discovery rate: a practical and powerful approach to multiple testing. Journal of the Royal Statistical Society: Series B (Methodological) 57 (1), p. 289ā300. Cited by: Ā§A.2, Ā§3. [3] C. Bird, N. Nagappan, H. Gall, B. Murphy, and P. Devanbu (2009) Putting it all together: using socio-technical networks to predict failures. In Proceedings of the 20th International Symposium on Software Reliability Engineering (ISSRE), p. 109ā119. Cited by: Ā§11. [4] B. H. Bjarnason, A. Silva, and M. Monperrus (2026) On randomness in agentic evals. Note: arXiv:2602.07150 Cited by: Ā§A.4. [5] M. Cataldo, J. D. Herbsleb, and K. M. Carley (2008) Socio-technical congruence: a framework for assessing the impact of technical and work dependencies on software development productivity. In Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), p. 2ā11. Cited by: Ā§11. [6] M. Cataldo, P. A. Wagstrom, J. D. Herbsleb, and K. M. Carley (2006) Identification of coordination requirements: implications for the design of collaboration and awareness tools. In Proceedings of the ACM Conference on Computer Supported Cooperative Work (CSCW), p. 353ā362. Cited by: Ā§11. [7] M. Cemri, M. Z. Pan, S. Yang, L. A. Agrawal, B. Chopra, R. Tiwari, K. Keutzer, A. Parameswaran, D. Klein, K. Ramchandran, M. Zaharia, J. E. Gonzalez, and I. Stoica (2025) Why do multi-agent LLM systems fail?. In Advances in Neural Information Processing Systems (NeurIPS), Datasets and Benchmarks Track, Cited by: Ā§11. [8] C. J. Clopper and E. S. Pearson (1934) The use of confidence or fiducial limits illustrated in the case of the binomial. Biometrika 26 (4), p. 404ā413. Cited by: Ā§A.2, Ā§3. [9] Y. Dong, X. Jiang, Z. Jin, and G. Li (2024) Self-collaboration code generation via ChatGPT. ACM Transactions on Software Engineering and Methodology 33 (7), p. 1ā38. Cited by: Ā§11. [10] Y. Du, S. Li, A. Torralba, J. B. Tenenbaum, and I. Mordatch (2024) Improving factuality and reasoning in language models through multiagent debate. In Proceedings of the 41st International Conference on Machine Learning (ICML), PMLR, Vol. 235, p. 11733ā11763. Cited by: Ā§11. [11] R. I. M. Dunbar (1992) Neocortex size as a constraint on group size in primates. Journal of Human Evolution 22 (6), p. 469ā493. Cited by: Ā§11, Ā§12. [12] R. A. Fisher (1934) Statistical methods for research workers. 5th edition, Oliver and Boyd, Edinburgh. Cited by: Ā§A.2, Ā§3. [13] J. Gabor, J. Lynch, and J. Rosenfeld (2025) EvilGenie: a reward hacking benchmark. Note: arXiv:2511.21654 Cited by: Ā§9. [14] C. Gote, I. Scholtes, and F. Schweitzer (2019) Git2net: Mining time-stamped co-editing networks from large git repositories. In Proceedings of the 16th International Conference on Mining Software Repositories (MSR), p. 433ā444. Cited by: Ā§11. [15] V. A. Graicunas (1937) Relationship in organization. In Papers on the Science of Administration, L. Gulick and L. Urwick (Eds.), Note: First published in the Bulletin of the International Management Institute, 1933 Cited by: Ā§11, Ā§12. [16] S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, C. Zhang, J. Wang, Z. Wang, S. K. S. Yau, Z. Lin, L. Zhou, C. Ran, L. Xiao, C. Wu, and J. Schmidhuber (2024) MetaGPT: meta programming for a multi-agent collaborative framework. In The Twelfth International Conference on Learning Representations (ICLR), Cited by: Ā§1, Ā§11. [17] M. Joblin, S. Apel, C. Hunsen, and W. Mauerer (2017) Classifying developers into core and peripheral: an empirical study on count and network metrics. In Proceedings of the 39th International Conference on Software Engineering (ICSE), p. 164ā174. Cited by: Ā§11. [18] M. Joblin, S. Apel, and W. Mauerer (2017) Evolutionary trends of developer coordination: a network approach. Empirical Software Engineering 22 (4), p. 2050ā2094. Cited by: Ā§11. [19] S. Kapoor, B. Stroebl, Z. S. Siegel, N. Nadgir, and A. Narayanan (2025) AI agents that matter. Transactions on Machine Learning Research. Cited by: Ā§1, Ā§11. [20] Y. Kim, K. Gu, C. Park, C. Park, S. Schmidgall, A. A. Heydari, Y. Yan, Z. Zhang, Y. Zhuang, Y. Liu, et al. (2026) Capable language models can outgrow the benefits of collaboration. Nature Machine Intelligence 8 (7), p. 1157ā1172. Cited by: Ā§11. [21] J. Leike, M. Martic, V. Krakovna, P. A. Ortega, T. Everitt, A. Lefrancq, L. Orseau, and S. Legg (2017) AI safety gridworlds. Note: arXiv:1711.09883 Cited by: Ā§9. [22] Z. Lyu, S. Chen, Z. Ji, L. Wang, S. Wang, D. Wu, W. Wang, and S. Cheung (2025) Understanding and bridging the planner-coder gap: a systematic study on the robustness of multi-agent systems for code generation. Note: arXiv:2510.10460 Cited by: Ā§11. [23] H. B. Mann and D. R. Whitney (1947) On a test of whether one of two random variables is stochastically larger than the other. Annals of Mathematical Statistics 18 (1), p. 50ā60. Cited by: Ā§A.2, Ā§3. [24] A. Meneely, L. Williams, W. Snipes, and J. Osborne (2008) Predicting failures with developer networks and social network analysis. In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE), p. 13ā23. Cited by: Ā§11. [25] G. A. Miller (1956) The magical number seven, plus or minus two: some limits on our capacity for processing information. Psychological Review 63 (2), p. 81ā97. Cited by: Ā§11, Ā§12. [26] Z. Mustahsan, A. Lim, M. Anand, S. Jain, and B. McCann (2025) Stochasticity in agentic evaluations: quantifying inconsistency with intraclass correlation. Note: arXiv:2512.06710 Cited by: Ā§A.4. [27] A. Pan, K. Bhatia, and J. Steinhardt (2022) The effects of reward misspecification: mapping and mitigating misaligned models. In The Tenth International Conference on Learning Representations (ICLR), Cited by: Ā§9. [28] M. Pinzger, N. Nagappan, and B. Murphy (2008) Can developer-module networks predict failures?. In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE), p. 2ā12. Cited by: Ā§11. [29] C. Qian, W. Liu, H. Liu, N. Chen, Y. Dang, J. Li, C. Yang, W. Chen, Y. Su, X. Cong, J. Xu, D. Li, Z. Liu, and M. Sun (2024) ChatDev: communicative agents for software development. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), p. 15174ā15186. Cited by: Ā§1, Ā§11. [30] C. Qian, Z. Xie, Y. Wang, W. Liu, K. Zhu, H. Xia, Y. Dang, Z. Du, W. Chen, C. Yang, Z. Liu, and M. Sun (2025) Scaling large language model-based multi-agent collaboration. In The Thirteenth International Conference on Learning Representations (ICLR), Cited by: Ā§11. [31] N. Wang, X. Hu, P. Liu, H. Zhu, Y. Hou, H. Huang, S. Zhang, J. Yang, J. Liu, G. Zhang, C. Zhang, J. Wang, Y. E. Jiang, and W. Zhou (2025) Efficient agents: building effective agents while reducing cost. Note: arXiv:2508.02694 Cited by: Ā§11. [32] C. S. Xia and L. Zhang (2024) Automated program repair via conversation: fixing 162 out of 337 bugs for $0.42 each using ChatGPT. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), p. 819ā831. Cited by: Ā§1. [33] Z. Zeng, Y. Li, R. Xie, W. Ye, and S. Zhang (2025) Benchmarking and studying the LLM-based agent system in end-to-end software development. Note: arXiv:2511.04064 Cited by: Ā§11. [34] G. Zhang, Y. Yue, Z. Li, S. Yun, G. Wan, K. Wang, D. Cheng, J. X. Yu, and T. Chen (2024) Cut the crap: an economical communication pipeline for LLM-based multi-agent systems. Note: arXiv:2410.02506 Cited by: Ā§11. [35] S. Zhang, M. Yin, J. Zhang, J. Liu, Z. Han, J. Zhang, B. Li, C. Wang, H. Wang, Y. Chen, and Q. Wu (2025) Which agent causes task failures and when? On automated failure attribution of LLM multi-agent systems. In Proceedings of the 42nd International Conference on Machine Learning (ICML), PMLR, Vol. 267, p. 76583ā76599. Cited by: Ā§11. [36] Z. Zhong, A. Raghunathan, and N. Carlini (2025) ImpossibleBench: measuring LLMsā propensity of exploiting test cases. Note: arXiv:2510.20270 Cited by: Ā§9. [37] W. Zhou, D. Sornette, R. A. Hill, and R. I. M. Dunbar (2005) Discrete hierarchical organization of social group sizes. Proceedings of the Royal Society B 272 (1561), p. 439ā444. Cited by: Ā§11, Ā§12. [38] K. Zhu, H. Du, Z. Hong, X. Yang, S. Guo, Z. Wang, Z. Wang, C. Qian, X. Tang, H. Ji, and J. You (2025) MultiAgentBench: evaluating the collaboration and competition of LLM agents. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), p. 8580ā8622. Cited by: Ā§11. [39] M. Zhuge, W. Wang, L. Kirsch, F. Faccio, D. Khizbullin, and J. Schmidhuber (2024) GPTSwarm: language agents as optimizable graphs. In Proceedings of the 41st International Conference on Machine Learning (ICML), PMLR, Vol. 235, p. 62743ā62767. Cited by: Ā§1, Ā§11. Appendix A Pre-Committed Hypotheses and Statistical Detail A.1 The eight hypotheses The pre-registrations released with the package are the Experiment 2 plan, which states H1 and H3āH6 with their tests, and the two scaling-arm commitments, which state H7 and H8. The Experiment 1 plan released alongside them pre-registers only the top-up decision above, so H2 is not a fully pre-registered hypothesis: its predicted direction was fixed from the Experiment 1 pilot, but its Fisher test and its correction set were specified after the schedule had run, before the inferential analysis. H3 carries a separate qualification: the Experiment 2 plan pre-registers a within-Experiment-2 Fisher test of the flat condition (labelled peer in the pre-registration) against the coordinator condition (labelled orchestrator) on the conflicting split, which is inconclusive, whereas the cross-experiment interaction reported in Section 7 (p=0.24p=0.24) is an exploratory test the plan does not specify. The hypotheses committed in full, in both prediction and pre-registered test, are therefore H1 and H4āH8; H2 and H3 carry the qualifications above, and both are reported as inconclusive or null. One note for the reader who opens the released plan: the Experiment 2 plan uses its own internal numbering, in which H2 and H7 are different hypotheses (a topology-distribution prediction and a corroborative footprint check) that do not enter the paperās set; the package includes a crosswalk from that numbering to the numbering used here. Where the body reports a hypothesis as confirmed or not supported, it refers to the statement and test recorded here. Table 3: The eight hypotheses and their outcomes. H1 and H4āH8 are pre-registered in both prediction and test; H2 and H3 carry qualifications (see text). hypothesis, in one phrase committed before outcome (where) H1 chained-task messaging scales as n2n^2 Experiment 2 collection confirmed (Ā§4) H2 a coordinator helps on conflicting tasks direction before collection, test after directional at n=4n=4; the n=8n=8 reversal does not survive the seal and is treated as null (Ā§7, Ā§9) H3 the coordinator effect differs across experiments Experiment 2 collection (within-experiment Fisher; cross-experiment test exploratory) inconclusive (Ā§7) H4 mandatory policy adds file coordination Experiment 2 collection confirmed (Ā§6) H5 chained-task addressing is less peer-directed Experiment 2 collection confirmed (below) H6 a shared constant reduces peer-directed addressing Experiment 2 collection not supported (below) H7 the n=4n=4 break is a coordination property 8-step arm directional, power-limited (Ā§4) H8 messaging growth halts between 8 and 16 agents 16-step arm confirmed (Ā§4) Two hypotheses are not discussed in the body. H5: addressing differs sharply between the experiments. At the matched four-agent cell (collection B, allowed policy, clean split), the per-run mean share of messages that name a specific peer is 97.1% in Experiment 1 against 60.7% in Experiment 2, a 36-point gap in the pre-committed direction. H6: a constant shared by every chain step was predicted to push agents towards broadcasting it, reducing the share of messages aimed at one named peer by at least fifteen points; the observed drop is 4.1 points (28.3% to 24.2%, p=0.23p=0.23), in the predicted direction but far short of the margin. The teams resolved the shared dependency by writing the constant into a file, which is Finding 2 appearing where a messaging effect was predicted. A.2 Tests and corrections The unit of analysis is one run: one graph, one binary outcome. Binary success rates carry ClopperāPearson exact 95% intervals [8]. Success contrasts use Fisherās exact test [12]; continuous contrasts use the MannāWhitney rank test [23]; neither assumes normality. Where a question tests a set of related contrasts, the set is corrected with the BenjaminiāHochberg procedure [2] and the corrected values are reported as pBHp_BH. Scaling exponents are least-squares slopes of logā”(count) (count) on logā”(n) (n) over per-run values, with 95% confidence intervals. The one exception is the pre-registered H1 test, which by its plan regresses over the three cell means; it gives the same slope with a wider interval, and both forms are reported in Section 4. The scaling arms use a piecewise version with the knot fixed in advance (n=4n=4 for the eight-step arm, n=8n=8 for the sixteen-step arm) and report the two segment slopes and their difference Ī . A.3 The sustained undirected graph and its topology Section 5 reads the shape of a runās coordination from its sustained undirected graph. For one run, count the direct messages sent in each ordered direction between every pair of agents. Two agents are joined by an undirected edge when at least one of the two directions carried two or more messages, so single greetings are dropped and a link marks a channel the pair used more than once. Only the configured agents agent-1 to agent-N are admitted as endpoints, so a hallucinated recipient never enters the graph. The mean degree of a run is the sum of the agentsā degrees divided by the full team size N, so an agent that sustains no channel counts as degree zero and stays in the denominator; a run that builds no sustained named-message network therefore has mean degree zero. We report the mean of this quantity over every run in the cell, silent runs included, against the clique line nā1n-1, the degree every agent would have if the team were fully connected. Averaging over every configured agent and every run, including the silent ones, is what keeps the degree an honest per-agent expectation; the earlier of these two choices matters most on the sparse sixteen-agent cell, where most runs build no network at all. The global clustering coefficient (transitivity) of a run is the number of closed triples divided by the number of connected triples in the same graph: for every agent, over each unordered pair of its partners, the pair is a connected triple, and a closed one when those two partners are themselves joined. It is 1 when the live partners form a single interconnected group and 0 when no two partners of any agent are joined. Both quantities are computed by precompute_topology_scaling.py in the released package, over the flat cells (both collection sessions pooled) under the allowed policy and clean split, at two, four, and eight agents for each task, with the sixteen-step chain adding points at eight and sixteen agents, the latter the only sixteen-agent data. The directed out-degree of Figure 7 (the eff_team_t measure in the released code) is a different measurement on the same messages: for each agent the number of distinct peers it sends at least t messages to, averaged across all agents; the count is directed and differs from the degree of the undirected graph. A.4 Design checks Repeated runs of the same configuration vary widely [4, 26], in agentic coding by up to thirty-fold in token consumption [1], and every main-matrix cell carries ten repetitions. A pre-registered rule flags a cell for topping up to twenty when its precision is low, and applied to the released data it flags 93 cells across the two experiments (48 of the 85 in Experiment 1, 45 of the 87 in Experiment 2), 25 of them on the outcome-precision condition and the rest on graph-statistic variance. The flags divide roughly evenly by team size, 35 at two agents, 36 at four, and 22 at eight. We topped up none of them, which is a deviation from the rule as written, made deliberately and recorded at the time. Topping the flagged cells up to twenty runs would have sharpened their estimates, the graph-statistic means as much as the success rates, by the usual factor of about 2 2; we judged it unnecessary because the confirmatory success contrasts pool across cells, so no single cell decides them, and because many of the graph-statistic flags were triggered by a metric other than the one a headline result uses for that cell, a cell flagged on file-read variance, say, whose headline reading is message count or sustained degree. The cost of that judgement is that the affected cell-level graph estimates remain less precise than the rule intended. A few hypotheses do read specific flagged cells, among them H1, H5, and H6, and their intervals should be read with that reduced precision in mind. The strict alternative of topping up every flagged cell was considered and set aside, and we record the departure here. The one deviation in the other direction is the sixteen-step scaling arm, pre-registered at twenty runs per allowed cell to tighten the plateau test of hypothesis H8. Two ablations defend the design. First, the forbidden policy is a prompt clause; re-running the worst-affected cell with the workspace locked at the filesystem level produced the same workspaces and the same outcomes, so the prompt form is sound. Second, the pilotās dominant failure traced to an ambiguous return-type clause in one specification; the clause was tightened and the worst cell re-validated (three of three passes) before the full schedules ran, leaving a cleaner outcome variable. A within-batch regression of messaging on run order shows no drift, so batches are internally stable; the between-session drift is measured and reported in Section 8.