Can a group of identical agents self-coordinate when nothing tells them how?

Why study multiagent systems?#

Models are becoming more capable (Astra, Mythos), and AI agents are taking on knowledge work across the economy. It is therefore imminent that agents will collaborate, negotiate and do economically valuable work on behalf of individuals and organizations.

Current governance systems, however, are designed by and for people, relying on oversight at human speed and discernment. These systems do not fit the speed at which agents can think, grasp information, communicate and take action. We still know very little about how AI systems behave in complex, real-world, multiagent environments, as we've been focused on building and studying the capability and safety of individual AI systems. Coordination, specifically, doesn't naturally emerge from stronger intelligence nor alignment at the individual level. Models also are susceptible to confabulation and reward hacking, and benign behavioral quirks at the individual level might compound into unwanted system-level outcomes. 

We have no confidence in predicting how advanced AI systems will interact at scale, and it’s critical that we study them now to create the conditions and governance systems for making such interactions go well. In this preliminary report, we study the emergent self-coordination behaviors of frontier AI agents — identical agents with Inkling as the backbone, in a minimal scaffold — collaborating to accomplish a shared task.

Our approach#

We begin with a minimal setting and plan to build up from there by asking: "Does self-coordination emerge when identical agents of one language model are given a shared task?"

We take N copies of one language model, Inkling, and give them one task, one shared workspace, one Slack workspace, and one shared budget of tokens, which every agent spends from as it generates. We tell them the task and that they are a team, and nothing else: we do not tell them who leads, how to divide the work, what channels to make, or how to decide when they are done. We then study what organization appears, and whether it shapes what they produce.

Prior work on multiagent scalingKim, Y. et al. (2025). Towards a Science of Scaling Agent Systems. arXiv:2512.08296. varies the coordination topology as a factor and measures task success across it. Here, topology is the dependent variable. The only independent variable is group size; the prompts, task, token budget and the design of the multiagent system are held fixed. Everything about how the group organizes itself is what we observe.

Design of the multiagent system#

Before describing how we built the multiagent system, we define and decompose what a multiagent system is, with formalism borrowed from Kim et al. An agent system $\mathcal{S}=(A,E,C,\Omega )$ consists of a set of agents $A=\{S_1,\dots ,S_N\},N>1$⁠, a shared environment $E$⁠, a communication topology $C$⁠, and an orchestration policy $\Omega$⁠. Each agent is itself a tuple $S_i=({\Phi }_i,{\mathcal{A}}_i,M_i,{\pi }_i)$⁠. It acts in a loop. At step t the agent's reasoning policy Φ_i conditions on its history h_i,t — the task specification and everything it has done and observed so far — together with its memory M_i, and produces a reasoning trace; the decision function π_i, instantiated by that policy, selects an action α_i,t from the action space A_i (a tool call, or the null action). The environment E — whose state the agent sees only through what it returns — answers with an observation o_i,t, and the history update f_i appends the action–observation pair, giving h_i,t+1, the history the next step conditions on. Every agent's action therefore depends on its own trajectory through the shared environment, not on the environment's state directly. The system components, in full:

What we built for each#

Experimental design#

1. The task is one item from OpenAI's GDPval benchmark of real-world professional work (task 47ef842d, from the occupation "Order Clerks"): as a wholesale sales analyst for a fragrance company, take a drugstore chain's store-level inventory data and build an Excel summary for five products — weekly rate of sale, weeks of supply, store counts, and the share of stores out of stock — with a chart of the out-of-stock rates and the work shown. The agents get the benchmark's prompt verbatim (Appendix A).
2. Each agent has
   1. its own loop on one Inkling deployment,
   2. a shared filesystem,
   3. a Slack workspace, with direct messages,
   4. and a share of one budget of 262,144 output tokens.
3. We varied only the number of agents, N ∈ {1, …, 6}, three runs at each, and held everything else fixed: the task, the model and its settings, the prompt, the tools, the sandbox, the token budget and the deadline.
4. Every run stops at 10 minutes, or earlier once the group has finished on its own.
5. Nothing about working together is prescribed. The whole of what the group is told about itself is: There is a task described below, and there are N of you. You are teammates on this project, and thus collaborate. This is the Slack channel at which you can communicate, and you can also direct message each other.

Results

"Finished on their own" is the quiescence rule (no tool call by anyone for 90 s, or no workspace action for 180 s after the first). Model calls count every turn of every agent, with or without a tool call. "Workbooks" is the number of .xlsx files in the deliverable folder at the end; when there are several, the grader scores the one written last (Appendix C). "Full Team Communication" opens the run's complete channel and direct messages, verbatim, as they stand in Slack.

Every solo run ended by the quiescence rule after spending 5–7% of the token pool, its last workspace action between three and a half and seven minutes. Twelve of the fifteen team runs ran to the ten-minute deadline, and the share of the pool a group spent rose with N  (9% at N = 2, 13% at N = 3, 20% at N = 4, 26% at N = 5, 29% at N = 6) primarily because each member independently redoes and checks the work. 

Emergent behaviors#

None of the behaviors that emerged was prompted or prescribed. Each behavior is read through one lens: did it help the group coordinate itself and collaboratively finish the task, or did it defeat it?

Interestingly, across the 166 messages of the fifteen multiagent runs, none asks about or mentions a teammate's ability, model, tools or background; sixteen messages ask a teammate for something (Appendix F): seven about how out-of-stock should be defined, two asking for a review, one proposing to divide the work, one about consolidating the deliverables, one asking what a teammate is working on, and four others; and work was handed to a teammate once in fifteen runs (run 2·3: "you verify the out-of-stock count", which agent-1 did) — every other division was self-assignment ("I'll build the Excel", "I'll verify the count"). 

The working assumption held from the start was that whoever else was there could do the whole task. We postulate that much of the coordination behavior (or lack thereof) emerged from this presumption of interchangeable competence.

Positive self-coordinating behaviors#

1. Communication is strictly functional. No run opened with introductions. 64 of the 166 messages name their sender ("Agent-2 here", "I'm agent-4"), and none proposes a role. Agents spoke only once they had read the data and started working, and only when they had something to say: a definition to settle (4 runs), a status to give (2), or a deliverable to report (9).

2. The ambiguous part of the task gets settled by asking. The task asks for an out-of-stock percentage that is not in the data. In four runs the first message is about exactly that — three sent privately, one to #general. In run 5·2 agent-4 asked two teammates how to define it, and agent-2's answer became the definition every workbook in that run used.

Note that all agents are identical, so there is no reason that one agent would know better than the others. Nothing prompted them to question this, and one agent takes authority merely by answering a question posed by another (although the answer is usually the asker’s own proposal, ratified).

3. Agents learn how the task is being done from each other’s files, not from the channel. How the task is being done — which script computes what, which definitions, which output file — travels through the files. 56 of the 60 agents in the multiagent runs read or ran a file a teammate had written, and in 14 of the 15 runs at least one agent ran a teammate’s script.

4. At N = 2, a builder and a checker emerge in two of the three runs. All three N = 2 runs ended with one workbook. In runs 2·1 and 2·3 one agent built it and the other checked it; in run 2·2 both built one and the second deleted its own after reading the first — agents deleted their own files in five runs, and never a teammate’s. In run 2·3 the checker found a real error, said so, and rebuilt the file, announcing the overwrite first. That run scored 0.956, the best of the eighteen, and is the only one where an agent made a channel (#deliverable-review) to ask for a review.

5. A second agent checks others' work. The three solo agent runs scored 0.92, 0.13 and 0.30. The 0.30 run misread the data: stores with a dash (-) in "Avg Days On Hand" were counted as out of stock, which put 75–91% of stores out of stock against true figures of 0.2–11.6%.  The solo agent did check itself — in all three runs it reopened the finished workbook and read it back — but it checked against its own definitions, so it could only confirm its own error. A second agent works the numbers out again, without the first one's assumptions. For example, an agent in run 3·2 proposed the same reading and a teammate rejected it within seconds.

The error itself comes from an ambiguity in the task: it asks for an out-of-stock percentage the data does not contain, so each agent has to define it. How much a second agent is worth may therefore be a property of this task.

6. Agents check each other’s work more often than they say so. 56 of the 60 agents read or ran a teammate’s file (item 3), while only thirteen messages claim a check of work that is not only the sender’s — six of those backed by something the agent did since it last spoke (Appendix F).

7. Direct messages are for questions; the channel is for reports. Agents sent 18 direct messages in 7 of the 15 runs. At N = 2 a direct message is the channel by another name; at N ≥ 3 there were 10, and 7 of them ask something — a definition, or whether to split the work. Recipients read 16 of the 18; both unread ones were completion notices sent at the end.

Negative self-coordinating behaviors#

1. Every agent does the whole task, in silence, before any role assignment. In every run, every agent started on the data before anyone had said a word. The first message is usually a completion report. 9 of 15 first messages announce that the deliverable is done.

2. Beyond two agents, deliverables multiply and nobody consolidates. Every N = 1 and N = 2 run delivered one workbook. From N = 3 on each agent built its own and left it in the folder, so runs ended with several "final" workbooks. No team tried to merge them or pick one, so good and failing workbooks sat side by side.

3. Dividing the work was proposed twice, and happened once. In run 2·3 agent-2 proposed, "Let's finalize metrics and split work: I'll prepare the summary Excel and chart, you verify the out-of-stock count", and that is what the two did. In run 4·1 agent-4 asked agent-3 whether they should divide tasks; agent-3 answered only after each had seen the other's files being rewritten. Neither changed course; the run ended with four workbooks.

4. Agents get different numbers and nobody flags it. In run 4·2 all four agents worked out the out-of-stock percentages themselves. Agent-4 counted active stores differently and posted its numbers in #general. The other agents reported different numbers and announced that the work was done, and not one of them mentions the discrepancy or asks about it. Agent-4 then read agent-3’s script, ran it, and its own numbers quietly disappeared.

5. Work division or delegation is rare. Work was handed to a teammate once in fifteen runs (run 2·3, above). Every other division was an agent assigning itself something — "I'll build the Excel", "I'll verify the count" — and all anyone asked of a teammate was a review, a definition, or what they were working on.

6. Verification of work was by redoing the work from scratch. After the first agent declared the deliverable done, 40 of the 45 remaining teammates went back to the raw data and computed it again themselves; nobody took a posted number on trust. This is what caught the few real errors (positive item 5), and it is also why six agents spend six times the tokens: here, checking the work and duplicating it are the same act.

7. Verification is sometimes a rubber stamp. Thirteen messages claim a check of work that is not only the sender’s; seven of them, across 4 of the 15 runs, have nothing behind them — no file opened and no command beyond an echo since that agent last spoke (Appendix F). Three more assert the work is verified by pointing at a teammate instead of looking: in run 2·1 agent-2 signs off twice with “Agent-1 verified.”

Conclusion#

Although we're seeing signals and glimpses of self-coordination, we're certainly far away from any robustness of coordination across a multiagent system, let alone coordination across agent populations in the wild. We need numerous experiments, using different models, coordination topologies, environments, etc. to be able to extrapolate and confidently predict the kinds of emergent behaviors that would show up in real-world deployments.

What comes next#

The runs reported here are a first pass: three runs per cell, one task, one model, one server. We report means and single runs without intervals, tests or effect sizes, because with three runs per cell there is too little data for them to mean anything. The planned next experiments should address these limitations:

More runs per cell. At temperature 1.0 with no seed, the three solo runs scored 0.13, 0.30 and 0.92, a spread that swamps the differences between team sizes (cell means 0.79–0.89); the solo-versus-team gap is the one score effect this data supports. Enough runs per cell will put intervals and effect sizes on every comparison.

Several tasks. Every run is the same GDPval task, with one ambiguous definition and one spreadsheet deliverable, so the behaviors above cannot yet be separated from the quirks of that task.

Heterogeneous groups. Every agent is the same deployment of Inkling, so “same model” and “same context” are confounded in every run. Separating them needs experiments that vary the model base and the shared context independently — mixed-model groups on one channel, and same-model groups with partitioned channels or files.

One server per agent. Every group ran on a single inference server under the same ten-minute deadline, so a larger group shared a fixed capacity: output per agent fell from 38 tokens per second alone to about 20 at N ≥ 3, and how much of the deadline-bound behavior at N ≥ 3 is coordination and how much is a slower server we cannot separate. One inference server per agent will hold throughput fixed.

Equal-compute solo baselines. A team of N spends about N times what a solo agent spends, so a higher score at higher N is not yet evidence that the team did anything a single agent could not do with the same compute. Two baselines will settle that: a solo agent run with N times the budget and the time, and best-of-k — k independent solo runs with a selector choosing among them. A team that beats both on a set of tasks has done something more than sample more; one that does not has merely spent more.

An open question and a limitation: Inkling’s reasoning. The model’s reasoning trace appeared on 1.6% of the 8,352 turns across all eighteen runs — 1.3% in the multiagent runs, and 16%, 10% and 4% in the three runs where an agent worked alone. This is the model’s own choice, not ours: every effort setting was honored, and when we probed the server directly, Inkling reasoned for 500–1,200 tokens per turn with no tools available. However, when a tool was available, only 32–88 tokens were generated before it called the tool. The harness captured every trace. Why the model allocates reasoning this way in an agentic loop we cannot say; it is likely a property of its training. Whether a deliberating condition — a text-only turn before each action — changes any of the behaviors above is untested.

Appendix F · How messages were coded#

Two counts in Positive behaviors rest on reading messages rather than on the logs alone: how many claim a check of another agent’s work, and what agents asked of one another. The rule below is the one applied; it is mechanical, so a second rater can reproduce the numbers exactly by running scripts/p22_codebook.py.

Unit. One message — a slack_post or slack_dm in a run with N > 1. There are 166. Every message gets one verification code and one request code; the codes are independent of each other, and within each set the categories are tested in the order written, so the order is part of the rule.

Verification. The verbs below find candidates; every candidate was then read and coded by hand, as in the pilot 14–21 claim audit, because the same words appear in messages that only announce that the sender finished its own work. The 34 candidates and their codes are in docs/analysis/p22_verification_coding.md. V1, a claim to have examined another agent’s work: the message reports in the past or present tense that the sender reviewed, verified, checked, inspected, validated, cross-checked or confirmed something, and that something is not the sender’s alone — it names another agent, or the team’s deliverables, or a file the sender never wrote. V2, the same claim about the sender’s own work only. V0, no such claim, which includes intentions (I will verify…) and requests (please verify…). A V1 message counts as supported when its sender had read or executed a deliverable workbook, by read_file or by a bash command naming it, at any point before the message was sent. At any point before is permissive: an agent that opened the workbook once, early, counts as supported for every claim it makes afterwards. The tighter test, and the one used for the same claims in pilots 14–21, asks what the agent did since its own previous message, counting only actions that can observe state (read_file, list_files, and bash other than echo, printf or a bare heredoc). Thirteen of the 34 V1 claims fail it — see negative behavior 7. python3 scripts/p22_codebook.py --strict prints them.

Request. A message is a request only if one of its sentences carries a question mark or an explicit ask (can/could/would you, please review / verify / check / confirm / advise / clarify / let me know, should we, shall we, let’s decide / agree / finalize / split / divide). The category is read off those sentences alone, so a status report that happens to mention out-of-stock is not a definition question. R1 definition: how out-of-stock, active stores, the weekly rate or WOS should be defined. R3 division: who takes what, or a proposal to split the work. R4 consolidation: whether to merge, pick one file, or produce a single deliverable. R2 review: asks someone to review, verify or check work. R5 status: asks what a teammate is doing or has done. R6 any other request. R0 no request.

The rule is deliberately conservative about requests: it counts only what is asked outright, so a plan announced without a question (I’ll build the Excel) is not a request, and four of the sixteen fall into R6 because the asking sentence names no topic the scheme recognises. python3 scripts/p22_codebook.py --list prints every coded message with its codes.

Citation#

Please cite this work as:

Eskandar, K., "Can a group of identical agents self-coordinate when nothing tells them how?", preliminary report, September 2026.

Or use the BibTeX citation:

@techreport{eskandar2026selfcoordination,
  author = {Kadair Eskandar},
  title  = {Can a group of identical agents self-coordinate when nothing tells them how?},
  year   = {2026},
  month  = sep,
  note   = {Preliminary report}
}