Homogenization in Multi-Agent Systems: why a team of agents quickly starts thinking alike

The paper describes not a technique but the protocol used to measure the effect, plus three metrics.

PROTOCOL (repeated for T rounds, the authors used T=5):
  STEP 1: Each role agent independently evaluates the task → score + rationale
  STEP 2: The orchestrator collects all scores and updates the shared state → summary
  STEP 3: The summary is sent to all agents → next round

THREE SYMPTOMS OF COLLAPSE (computed from the agents' scores):
  Conformity: the spread of scores across agents shrinks
  Polarization: the mean score drifts toward the edges of the scale
  Inertia: from round to round the mean score changes less and less

Task: You lead a small team building a backend that accepts Stripe payments for an online store. In Claude Code you have a setup of four review agents (Security, Correctness, Optimality, Readability) plus an orchestrator. Before trusting a green score, you want to check whether the "four opinions" have turned into one.

Prompt:

You are the orchestrator of a multi-agent code review. Follow a 4-round protocol.

<Workers>
Agent_Security: looks for vulnerabilities (injections, redirects, logging of secrets).
Agent_Correctness: looks for logic errors and missed edge cases.
Agent_Optimality: evaluates performance and complexity.
Agent_Readability: evaluates readability and maintainability.
</Workers>

<Protocol>
For each round t from 1 to 4:
  1. Each agent outputs: a ship-readiness score of 1-5 (1 — not ready, 5 — ready) and a rationale. 
     In round 1 the agents do not see each other's scores.
  2. The orchestrator writes a state summary: what was found, what was fixed.
  3. The summary is passed to all agents before the next round.
  After each round, output a table: each agent's score, the mean score, the spread (max minus min).
</Protocol>

<Code>
{payment_and_refund_endpoint_code}
</Code>

At the end, output: the final score, plus four lines:
Conformity (did the spread shrink?), Polarization (did the mean drift to the edges?), Inertia (did the step size of the mean's change shrink?), Conclusion: can the agents' agreement be trusted.

Result: The model will output a table of scores by round, with each role's rationale and the orchestrator's summary. At the end comes a check of the three symptoms. If the spread has shrunk to zero by round 2-3 and the mean has drifted to 5, that is a signal: the unanimity may be blind. In that case your check needs to live outside the chain.

The model's weakness. All the roles in such systems usually run on the same model and differ only in their description ("you are the security expert"). They share blind spots. When an agent sees the others' summary in the next round, agreeing is easier than arguing. The summary creates a shared "anchor", and the model, generating text along the pattern, continues it. So the spread shrinks and the scores shift toward the confident edge.

The model's strength. A single model finds many defects well. The paper notes that a team of reviewers cuts the total number of code vulnerabilities by up to half. But whatever everyone missed at once gets amplified, because the agents confirm each other.

How to use this. This is not a method but a risk map. The levers it suggests: - Number of rounds. The more rounds of discussion, the stronger the inertia. One independent round gives more diversity than five coordinated ones. - What the agent sees before it scores. If the score is given before reading the others', it is independent. - Team composition. Changing the model or the seed does not add real diversity. Different roles in the prompt only add it on the surface, too. - External control. You cannot trust the agents' agreement. You need a tool outside the chain: a static analyzer, tests, a human.

This is the protocol from the paper (Algorithm 1), packaged as an instruction for diagnosing collapse.

You are the orchestrator of a multi-agent system. Follow a protocol of {number_of_rounds} rounds.

<Workers>
{Agent_1}: {role_and_focus}
{Agent_2}: {role_and_focus}
{Agent_3}: {role_and_focus}
</Workers>

<Scale>
Score from {min} to {max}. {what_min_means} → {what_max_means}
</Scale>

<Protocol>
For each round t from 1 to {number_of_rounds}:
  Step 1 (in parallel): each agent outputs a score and a rationale.
         In round 1 the agents do not see each other's scores.
  Step 2 (collect): the orchestrator updates the shared state based on all scores.
  Step 3 (broadcast): if t is less than {number_of_rounds}, the state is passed to all agents.
  After the round, output a table: each agent's score, the mean, the spread.
</Protocol>

<Task>
{material_to_evaluate}
</Task>

At the end, check the three symptoms:
1. Conformity: is the spread of scores in the last round smaller than in the first?
2. Polarization: has the mean moved closer to the edges of the scale?
3. Inertia: is the change in the mean between the last rounds smaller than between the first?
Give the final score and a conclusion: can the agents' agreement be trusted.

What to fill in: {roles} — your real roles, {scale} — any numeric score (readiness, fit, risk), {material} — code, a resume, a text, an application.

🚀 Quick start — paste into the chat:

Here is a multi-agent review protocol template with three collapse metrics. Adapt it to my task: [your task]. 
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what roles your team has, what scale to score on and what exactly is being checked. It needs this so the spread, polarization and inertia metrics are computed on a meaningful numeric scale. It will take the structure from the template and plug in your data.

⚠️ No proven cure: The authors showed that seeds and model mixes do not help, but they did not offer a working remedy. All the defenses below in "Adaptations" are hypotheses, and you have to test them yourself.

⚠️ A simulation in one chat is weaker than a real system: If you ask one model to play all the agents in a single response, it sees everything at once. A real system with separate calls works differently, and collapse there may unfold differently.

⚠️ Other models: The experiments ran on open models (Qwen, DeepSeek, Kimi, Nemotron). The dynamics were not tested on ChatGPT, Claude or Gemini, although the authors see the same effect in every family they tested.

⚠️ Numeric scores only: The metrics were computed from scores. The paper does not measure how open-ended text collapses.

⚠️ Sample averages: The trends come from averaging over hundreds of cases. On a single request the picture may differ.

⚠️ Synthetic data and specific tasks: The resumes are artificial, the reviews are of ICLR submissions, the code comes from a set of tasks with vulnerabilities. On your data the scale may be different.

The idea was to test multi-agent systems not on debates about topics but on real applied tasks. The team took three: code generation (280 security tasks, with vulnerabilities checked by the CodeQL analyzer), resume evaluation (200 "job posting–resume" pairs and 40 variants of each with different gender and ethnicity, 8000 in total) and peer review (1950 submissions to ICLR 2025). Each task was handled by a team of roles with an orchestrator. The roles differ: for code, security and correctness; for resumes, experience and impact; for reviewers, a pragmatist, a theorist, an empiricist. Everything ran for 5 rounds with 10 independent runs on 9 models. Another 11 single-model and 16 mixed configurations went into the appendix.

The result repeated everywhere. The spread of scores fell to half or below, the mean score drifted toward the edge of the scale (by up to half a point), and changes in the last round were several times smaller than in the first. Inertia showed up the strongest. In code, the team cut the number of vulnerabilities by up to half, but certain types (for example, unsafe redirects and log injections) grew from round to round. The reviewers lost calibration and gave overconfident scores, while the generator kept introducing the same mistakes.

In the resume experiment, one agent was given a biased instruction for two rounds. The bias quickly spread to all the agents and persisted after the source was removed. In peer review, small preferences for certain research areas got amplified and locked in the gap between them.

The biggest surprise: the ways of increasing diversity did not work. Different seeds changed the wording but not the final decisions. Mixed models were expected to save the day, but models from different families share blind spots, and the mistakes coincided. The practical takeaway: agreement among several agents is not proof of being right, especially if they saw each other's answers.

These are my ideas; the authors did not test them.

🔧 Technique: remove the exchange of opinions in round 1 → preserve independence.

Lock in each agent's first score as "pre-discussion". If the final conclusion after the rounds differs sharply from the independent scores, yet the discussion brought no new facts, that is a sign of opinion contagion:

Round 1: evaluate independently. Record the score as "independent".
Rounds 2-4: you may see the others.
At the end, compare the independent scores with the final ones and state which changes were made based on new facts and which under consensus pressure.

🔧 Technique: move verification outside the agents → an external anchor.

The agents' agreement does not replace static analysis and tests. You can add a rule to an instructions file (for example, CLAUDE.md):

The reviewers' score is not grounds for shipping. 
Before the final verdict, run the linter and the tests and report their results as a separate item.

Extrapolation: if one "rogue" or mistaken agent in your chain could have influenced the others, restart the others with a clean context after removing the source. The paper shows the bias stays in the team even without it.

• Homogenization in Multi-Agent Systems. The work was done at Apple (including during an internship)
• The conformity and polarization metrics are borrowed from Lin et al. (2025); consensus from Oh et al. (2026); inertia was introduced by the authors themselves
• Multi-agent peer review — Sahu et al. (2025); the security task set — CodeLMSec (Hajipour et al., 2024); synthetic resumes — Tan et al. (2026)
• Mixed model configurations — Anthropic Frontier Red Team (2026)