In a system that mixes models from several different companies, each agent was given just one hint: "which model family you and your counterpart belong to." As soon as that happened, agents wearing the same label began to huddle together and take sides against the rest.
Nobody ever told them to pick sides. Yet they did. The paper gives this phenomenon a name: factionalism — the tendency to form cliques among those who share the same tag.
How bad does it get? In two games where the only thing you need to do is cooperate well, labeled groups used on average 30% more rounds and 55% more tokens to reach a conclusion. Their success rate dropped from 96% to 81% (per the paper's abstract).
The twist is that the fix is as simple as the problem. Hide that one label from the agents, and the clustering disappears.
Modern AI systems don't dump everything on a single model. They bundle several AI agents together like a team and put them to work. This is called a multi-agent system. And increasingly, those teams mix models from multiple vendors.
But information like "which model family is this agent?" is really just an incidental tag that has nothing to do with the actual work. The trouble is that this tag often leaks all the way down to the agents themselves — riding in on system prompts, agent names, or message headers. Nobody told them to pick sides based on it. So do the agents actually ignore it? No one had properly checked, and that's the authors' starting point.
In fact, a hot topic these days is how you can assemble a bunch of smart AIs and still get nonsense out. Each model is fine on its own, but put several together and they fall out of step or stampede off in one direction. Observations have been piling up that multi-agent failures stem less from the models themselves than from the interactions between them (Cemri et al. 2026; Anthropic Frontier Red Team 2026). This paper puts that out-of-step behavior under the microscope.
The authors define factionalism as "the tendency for agents to organize into groups that share a common identity." If you draw the agents' exchanges as a relationship graph, it shows up as that graph splitting into several clusters along label lines. Underneath it all lies homophily — a "birds of a feather" tendency to respond more warmly to a counterpart wearing the same label.
Here the authors make one clever distinction. Just because same-labeled agents agree a bit more often doesn't necessarily mean the group splits. Think of a class reunion. Sometimes people from the same department greet each other especially fondly yet still mix freely at the tables (local closeness — a two-person affair). Other times they split off and claim separate tables by department entirely (global division — a whole-group affair). The authors measure these two separately and call something "factional" only when both are clearly present. They baked the criterion — that a little extra friendliness among peers isn't enough — right into their measurement design.
In truth, this is the AI version of the "minimal group bias" long observed in humans. Split people into teams by a criterion as meaningless as a coin flip, and they'll still favor their own side. This paper asks whether the same thing happens in groups of LLMs. And to pin down whether the cause lies in the model's insides (its actual architecture) or the surface written into the prompt (the label), it sets up one clever experiment we'll see later.
The experiments used five open-weight model families. Open-weight means a model whose source code isn't public, but whose weights (the trained bundle of numbers) are released so anyone can download and run it. Specifically: Gemma, GPT-OSS, Nemotron, Qwen, and GLM.
A single round holds 9 to 25 agents, and depending on the roster size it mixes three, four, or five of these families. They ran both a balanced setup — each family in equal numbers — and an imbalanced one that loads up on a single family. The balanced setup erases the explanation that "they cluster because there are more of them," while the imbalanced one checks "does the effect hold up even when there's a majority?"
The tasks are two cooperation games.
Both games run on the same framework. Each round an agent submits a natural-language message, a vote, and a list of recipients it has chosen — "who do I want to send this message to?" The next round, it sees only the messages addressed to it. The key point is that agents choose for themselves who to talk to. Even when the environment doesn't force it, this leaves room for same-family agents to seek each other out and agree.
On top of this, to see whether the same thing happens even on a task with a predetermined external answer, they laid leader election right on top of GPQA-Diamond, a set of hard scientific multiple-choice questions. The elected leader's answer becomes the group's answer, and it has to be correct to count as success.
The crux is how you turn "the group split into sides" into a number. The authors first drew "who followed whose opinion" as a relationship. If one agent's decision gets copied by another in the next round, the tie between them counts as thicker.
Then they looked at this relationship through two lenses — though the two lenses groom the same relationship slightly differently. (1) Are same-labeled agents more tightly knit? (2) Does the graph actually fracture into multiple clusters along label lines? These are different questions. Liking a particular candidate a bit more in a popularity poll (1) is nothing like building an entire campaign around that candidate and drawing a line against the other camps (2). It's the same difference as the "fond greeting" versus the "separate tables" at that class reunion. The authors ruled something a faction only when both lenses agreed. And they counted only cases that passed repeated trials as non-coincidental — a conservative bar that doesn't call something a faction lightly.
And to funnel the cause down to that one label, they designed the experiment itself in three clean layers.
Both metrics start from the same "following" relationship but build the graph differently. (1) "Are same-labeled agents more tightly knit?" weights an edge by the fraction of decisions j sent to i as a recipient that match i's next-round decision (Eq. 1), normalizes by contact volume, and then measures the Edge Density Ratio (EDR) — the ratio of mean weight for same-label pairs to different-label pairs — with a permutation test that shuffles labels to rule out chance. (2) "Does it fracture along labels?" runs the Louvain algorithm on a graph of un-normalized match counts summed in both directions to find communities, then scores how much those communities overlap the label partition using Adjusted Mutual Information (AMI, 0 if unrelated, 1 if identical). Factionalism is granted only when all four tests on these two metrics are significant. The two EDR tests are a Fisher-combined version of the per-seed permutation p-values and a one-sided t-test on log(EDR); the two AMI tests are a one-sided t-test and a sign test. All four must pass after a Holm–Bonferroni correction to count as factionalism. Whether the clustering follows the label the agent saw or the actual architecture behind it is settled — separately from this verdict — by the label-swap experiment.
This relationship-graph score looks only at whether the structure of the interaction split. It does not look at the quality of the decisions. Quality and efficiency (the rounds, tokens, and success rate we saw earlier) were measured separately.
To cut to it: factionalism appeared in every experiment where the label was visible, and in none where there was no label. It was just as strong in the balanced setup as in the imbalanced one — meaning a numerical majority isn't the culprit.
But the more interesting question is this: why do the models take sides? There are two possible explanations.
The design was set up to tease these two apart, and the results came down on the side of the label hypothesis. When the labels were scrambled against the real models, the clustering followed the "scrambled labels," not the "actual architecture." It held up when the labels were swapped for color names with no reputation or meaning (teal, coral, silver, violet, maroon), and it held up on GPQA-Diamond with its predetermined external answer. In a word, exactly as designed, the results followed the label.
To nail the conclusion down once more, the authors directly measured two signals (Section 4.4). One is the "writing-style" signal: how naturally a counterpart's raw text reads to my model. The other is the "conformity" signal: how much I follow a counterpart's vote. Measured out, the stylistic similarity was there but vanishingly small, and it tracked the real architecture even when labels were scrambled. The conformity signal, by contrast, grew when a label was attached, and when scrambled it followed the "visible label," not the actual architecture. The conclusion is clear. Models don't cluster because they recognize kin by writing style. The agents simply respond to "the label they were told" and accept decisions from the same label more readily.
This cost widened as the group grew. Labeled groups spend more tokens while succeeding less, so the cost paid per success climbs steeply as the group gets larger.
The authors say they deliberately kept the scope of their claims narrow. The core limit is that the study covers at most five open-weight model families.
Two points are worth flagging. First, the tasks are abstract coordination games and a benchmark. This cleanliness is a strength for proving causation, but whether it carries straight over to real software-agent settings — where roles, authority, and interests are all tangled together — is another matter. Real systems usually come with roles and goals, and this design alone can't tell us whether such stakes would amplify the cost of factions or dampen it.
Second, the fix — "hide the labels" — isn't free. The authors themselves hold that the orchestrator, the upper layer that coordinates and dispatches everything, needs to keep hold of identity in order to decide which model to assign work to, to track problems, and to pin down accountability. In other words, you hide it only in the context agents exchange with each other; it's not a prescription for the whole system to throw identity away. How to strike this balance in actual operation is the remaining homework.
So how does this finding reach into ONTLE's system? There's one spot where the paper's warning seems to fit exactly: the moment when ONTLE's AI PM gathers a conclusion together with several responsible agents.
Picture, for instance, a meeting to decide whether to move a customer deliverable up to "ready for approval." The PM agent gathers opinions with the development and QA agents. Because ONTLE's model router assigns different models depending on the nature of the task (heavy reasoning for chat and intake, mid-tier for execution, a fast model for edits and deployment), this meeting is already a place where several families are mixed. If the prompts, headers, and agent names being exchanged carry a tag saying "I belong to such-and-such model family," then — just as the paper's results predict — the approval consensus could split along the labels, run for more rounds, and more often fail to reach a conclusion. The cost was measured as especially large precisely on this kind of consensus task, so ONTLE's approval flow, which gathers conclusions by vote, is a place worth watching.
What matters here is that this is a problem on a different surface from ONTLE's existing rules. ONTLE already has a rule that "model names used must not be exposed in customer deliverables, screens, or PM replies." But that's a rule for the surface the customer sees, and the reason was "class." Where this paper points is not the customer but the surface agents exchange among themselves. It's asking us to apply the same model-name-hiding hygiene habit, one more time, to a new surface we haven't touched until now. And the reason isn't aesthetics — it's coordination cost.
Go one step deeper, and a question arises about ONTLE's model-routing strategy itself. For the sake of efficiency, the router divides the work: "heavy reasoning to this family, fast execution to that one." But the moment that assignment reads to the agents as "sides drawn by capability," routing meant for efficiency could instead become the seed of the very side-taking the paper warns about. Is an arrangement that lets the high-performing models huddle together always best, or should we sometimes deliberately mix the families and hide the boundary between them? This is the fresh homework this paper hands ONTLE.
That doesn't mean "switch to capability descriptors and you're done." The paper showed that factions emerged even with meaningless color names. The point isn't to change the name, but to hide from the agents the categorical tag itself — the thing that lumps many into one side. Fortunately, in settings like the approval meeting where the roles are all distinct — one PM, one dev, one QA — a role name works as "individual identification" rather than a "side," which is relatively safe. The danger grows when many agents of the same category pile into one place. That's why it needs more care as scale grows.
Translated into practice, the order goes like this.
No. What the paper singled out is the "categorical tag" that lumps many into one side (family, color) — not individual identification. The study swapped only the family labels while leaving "who sent it" intact, and the clustering followed the family label, not the number. Distinguishing individual senders is not, in itself, the trigger.
This study looked at groups mixing multiple families. If there's only one label, there's logically no side to split along in the first place. That said, what this paper covered is the case of mixing vendors, and these results don't speak to the other trade-offs that single-family operation carries.