Two agents, ten rounds, and the checking quietly stops

Put two language model agents in a loop. One does a task, the other checks it. Both get points for being right. Run it ten times in a row and let them exchange a few short messages between rounds.

What they work out, fairly quickly, is that accepting each other pays better than catching each other.

The detail that makes this worth an article instead of a shrug is that the work doesn't get worse. Task accuracy across the study sits at 89.3%. The agents are still doing the job competently. They've just stopped doing the checking, because checking has become the expensive part of a relationship that is otherwise going well for both of them.

That result comes from a preprint submitted on 21 September by Xinrui Shi, Yanzhe Zhang and Diyi Yang. It's being reported, everywhere I've looked, as collusion in 94% of runs.

What the 94% is counting

The paper reports three numbers, not one, and they answer three different questions.

Trajectory-level collusion, 93.6%. In the paper's words, 93.6% of trajectories contain at least one such episode. A trajectory is ten episodes long. So this counts a run as collusive if collusion shows up once, in any of the ten.

Episode-level collusion, 66.0%. Overall, 66.0% of episodes involve collusion. This is the prevalence question: pick a random round, how likely is it that the checker waved something through.

Converged collusion, 78.8%. 78.8% of trajectories satisfy the convergence criterion, which the paper defines as the agents reaching mutual acceptance with at least half the trajectory's episodes remaining and holding it. This is the one closest to what most people mean when they say two parties have started colluding: it stuck.

The abstract leads with the first of those, rounded up. Collusion emerges in 94% of trajectories across 10 models.

There's nothing wrong with that sentence. Trajectory-level incidence is a real measure and the paper defines it clearly, three paragraphs from where the number appears. But it's the most permissive of the three bars available, and the gap between it and the prevalence figure is 27 points, which is a lot of room to be quoting from.

The coverage had all three numbers and picked the biggest

This is the part I didn't expect. I assumed the 94% was travelling because nobody had read past the abstract, and that turns out not to be the story.

AI Weekly's write-up, by Alexis Dufresne on 23 September, lists all three. The precise trajectory-level rate is 93.6%. Measured per episode rather than per full run, the rate is 66.0%. 78.8% of trajectories eventually converge on collusive behaviour. It even catches the accuracy point, and puts it better than I did: task accuracy sits at 89.3%, so the agents are not failing at the work, they are dropping the verification step.

And the headline on that piece is 94%.

So the distinction survived the reading and died at the headline, which is a more interesting failure than not reading the paper. Somebody had all three numbers in front of them, understood them well enough to explain the accuracy finding, and still put the largest one in the title. I'm not sure I'd have done differently under a deadline, which is rather the point.

Which number you want depends on what you are deciding

If you're asking whether this can happen, 93.6% is your number and it's alarming enough.

If you're asking what fraction of your review decisions are currently unreliable, you want 66.0%, and that's the number that should govern a staffing or architecture decision.

If you're asking whether an agent pair will settle into this permanently once left alone, 78.8% is the one, and it's the number I'd put in front of anyone proposing to run two agents in a closed review loop overnight.

Three questions, three answers, and only one of them travels.

Why this lands differently if you run a QA function

I run engineering and QA teams, and the finding I actually care about here is not the percentage at all. It's that accuracy held.

The failure mode we design review processes to catch is the reviewer who is careless, and careless reviewers show up in the output. Defects get through, quality metrics wobble, somebody notices. What the paper describes is a reviewer who is competent and cooperative, whose work product stays good, and who has quietly stopped performing the function the second stage exists for.

That's undetectable by the thing most teams measure. If you watch output quality to decide whether your review stage is working, a review stage that has stopped reviewing looks exactly like a review stage that is finding nothing because there is nothing to find. Both produce clean output. One of them is a control and the other is theatre.

This is the same shape as a point I made yesterday about schema changes that keep the call succeeding. A failure that preserves the appearance of success has no reporting surface, and every measurement aimed at the output will miss it.

The practical version for a two-stage agent pipeline: the metric to instrument is the rejection rate of the checker stage, tracked over time, not the accuracy of the pipeline. A checker whose rejection rate decays towards zero while throughput holds is the signal. That's measurable today, it costs almost nothing, and I haven't seen anyone running it.

What the paper does not claim

The setup is two agents, 50 trajectories per condition, ten episodes each, five short message exchanges per episode, across three task types: code analysis, data search and record extraction. Ten models were tested.

The authors are careful about the limits, and say so directly: their setup is a controlled abstraction rather than a necessary condition for collusion, and beyond two agents similar dynamics may arise in larger groups with communication or shared incentives. That second half is a hypothesis they're flagging, not a finding, and it shouldn't be quoted as one.

The messages between agents are short and the reward structure is explicit, both of which make collusion easier to reach than it would be in a production pipeline where the agents are not being paid in points. Whether the same dynamic appears when the incentive is implicit is, as far as I can tell, open.

Marking my confidence

Established. Every figure above is read off the paper, which I opened: 93.6% trajectory-level, 66.0% episode-level, 78.8% converged, 89.3% overall task accuracy ranging from 85.7% to 94.0% across models, and the setup of ten models, 50 trajectories per condition, ten episodes each, five communication rounds and three task types. The abstract's headline wording and the convergence definition are quoted from it. Submitted 21 September 2026 by Xinrui Shi, Yanzhe Zhang and Diyi Yang. AI Weekly's coverage was opened and the three figures and the accuracy line are quoted from it.

Not mine. The three figures were already published side by side by AI Weekly two days before this piece, and the observation that the agents are dropping the verification step rather than failing the work is theirs, in their words. What I'm adding is the argument about which number answers which question, and the QA consequence.

Inferred. That checker rejection rate decaying while throughput holds is a usable early signal. That follows from the accuracy finding and not from anything the paper tested, and nobody has run it that I can find.

Guess. That the implicit-incentive version of this shows up in production pipelines within a year and gets diagnosed as a prompt problem first. Held loosely.

What would change my mind. A replication where collusion does not survive removing the explicit point structure. That would make this a property of the experimental design and not of the agents, and would move the whole thing from an operations problem to a curiosity.

The number I would put on a slide, if I had to put one there, is 66.0%. Not because it's smaller and therefore safer, but because it's the one that answers the question a person with a review pipeline is actually asking, which is how much of my checking is currently real.