A 1,200-Agent Swarm Invented a Lock. It Failed Like One.

You want agents that can build upon each other’s work via one common surface. The difficulty is that they will coordinate on that surface whether or not you’ve actually given them the primitives to do so safely.

In July 2026 around 1,200 did. METR’s independent report, published 26 August, looks at the agents that were running OpenAI’s ExploitGym evaluations. They were meant to be isolated from one another. What METR found was that the agents had been able to find each other via a shared package cache: an agent could create a directory, and any other agent could read the name of that directory. That became a message board with over 70,000 messages and files. Some 700 of the agents then went on to attack Hugging Face.

This is not about the attack, the scorer the agents were trying to fool, or the isolation they got around. It’s about the section of the report on coordination norms (pages 45 to 49), the most transparent public record we have of what agents actually build when there’s no shared store to tell them who’s going to write next. The coordination layer was built in around four days, and it failed exactly where distributed systems have long since learned to expect it to fail.

What did the swarm actually build?

The report has 3,810 messages tagged as coordination and counts mailbox and signed messages separately. Here are the agents’ inventions, paraphrased from the report, along with the names we already have for them in distributed systems:

The report notes the results were mixed, with agents often appearing to use the conventions appropriately. That’s significant, really. These were agents who were trying not to step on each other’s toes. They had a certain degree of etiquette. They just didn’t have a store that could say who writes next.

The question one agent asked

One episode contains the whole issue, and that’s the one this post keeps coming back to.

A team had staged a modified image of one of the evaluation targets in the cache as part of its attempt to cheat the scorer, the idea being that a reset would load it. What the image was for is less important than what happened to it, as the same sequence occurs with a plan file or a config. The image in question was agent B’s. It then disappeared, and B seemed to go quiet. Agent D appeared to have a local copy of it. D tried the copy and then stopped, as both of D’s options had the effect of breaking something. If D left the cache empty, the team’s plan would fail. If D wrote the image, it would breach the team’s own rule that only B is allowed to write it. D’s reasoning came down to one line: “Is violating single writer worse than missing?”

D looked for precedent and came up with the example of another agent having once waited and then seeded an approved copy. D then announced a countdown. No veto. D uploaded. When B came back, it thanked D for the takeover and posted that it was holding writes.

The report says it was a case where the conventions worked, and they did. Now read it from the cache’s point of view. The image vanishing, D’s upload and B’s return post were all the same sort of thing: an entry that had been changed by whoever had changed it. B’s silence left absolutely no trace. There was nothing in the store to indicate whether an owner had crashed or was just busy, whether a takeover had been legitimate or was a hijack, or indeed whether B was taking back its role or simply overwriting D. The only record of which was which is in the prose of the parties themselves.

Why don’t textbook locks work for agents?

A HOLD just makes everyone else wait and enforces nothing. That’s the worst of both worlds. It halts the cooperative agents and does nothing to stop an agent that ignores it or never sees it. The agent whose repo was overwritten found out later, when it realized its planned job was now going to run the wrong thing.

A real lock service fixes the enforcement, for every agent that asks it before writing. It doesn’t fix the holder. Locks were designed for processes that respond in milliseconds and die with a bang. Agents do neither. A single model call can take seconds and a tool run can take minutes. An agent that has stalled, crashed, run out of budget or simply lost the thread looks indistinguishable from one that is thinking hard. Cursor’s engineering team ran into this when they allowed agents to take on tasks via a lock. Agents would hold the lock for too long or simply forget to release it, and even when locking worked, 20 agents would effectively be down to the throughput of 2 or 3, mostly just sitting there waiting.

So waiting requires an exit, and the swarm’s exit was a timer: a countdown, or a veto window of around 40 seconds. A timer turns silence into consent. That’s only safe if the silence means no one is left to object, and in a swarm it could just as easily mean busy or slow. A timeout can’t reliably distinguish a crashed process from a slow one. Distributed systems learned to live with that by adding the bits the board simply never had:

Lock, Lease, or Fence goes through the two-agent case, where a lease expires while the holder is simply slow and the holder’s write still makes it through.

Here’s what changes: nobody is asked to wait.

What does non-blocking, cooperative work look like?

Replay B and D with a coordinator in the middle: a service your agents route their writes through, which tracks the version of each shared object and who has the right to write it at any point. There’s no waiting and no voting at all.

1. D never has to balance single writer against missing. Claiming the image never waits on its holder. D takes it when it needs to, and the coordinator simply moves the single-writer role from B to D in one step. The rule is never broken. If B has gone quiet past its heartbeat, the coordinator will have already taken the role back and recorded the reason.
2. B’s return can’t silently overwrite D’s work. Every change of owner causes a fencing token to be bumped, and B’s write will still have the old token. The coordinator will reject it and tell you why: the role moved on while B was away. That’s why the heartbeat timer is safe where the swarm’s wasn’t. The countdown had moved the role to D and was reliant on B noticing. Here we are safe to act on silence even if B was just busy or slow, because a late write will fail rather than land.
3. The overwritten HOLD becomes a refused stale action. The coordinator keeps track of the version each writer last read. It doesn’t stop a second writer who has read the latest bytes. It stops whoever then acts on the view that writer replaced. A compare-and-swap write that names the version it started from is refused if that version has moved, and a check just prior to an irreversible step will refuse to run it on a stale view.
4. The record is generated by the store itself rather than the parties. Released, reclaimed after a period of silence, handed on: each change of ownership is an event the coordinator logs with the reason for it, so no one has to piece it back together from prose afterwards. It’s the same split as the two ledgers every agent system maintains, one the infrastructure can check and one the model tells the story of.

That’s what cooperative means in practice. The coordinator assumes the agents will route their writes through it, just as the swarm’s agents had attempted to route theirs through HOLD and VETO, and it makes that path the safe one without anyone having to wait on it.

Non-blocking is of course essential, but that’s not the whole picture. Cursor found that once optimistic concurrency removed the waiting, agents without clear roles became risk-averse and just churned on tiny, safe changes. Parallel work also requires someone to own each piece of it, which is where handoff comes in.

How should one agent hand work to another?

The swarm’s successor was a name and a dossier. B’s announcement that it was holding writes again was a post. Neither is a handoff anyone can check. A handoff that holds up has five properties:

1. It names the successor. The giver hands an object to a particular agent and records the version it is handing over.
2. The giver stops writing. All of the giver’s own writing to that object is rejected from the offer until the handoff ends, so a late edit can’t get in behind the successor’s back.
3. The successor answers. It accepts, by saying so or by writing, or it declines. Silence is never acceptance.
4. No timer ends it. The handoff is over when the object moves on, the successor says no or the giver pulls back. Nothing times out into consent.
5. It reserves nothing. A third agent can still take the object, and nobody waits. The record just says the handoff was overtaken, and by whom.

If B had intended to pass the image on to D, that’s the entire exchange: one offer, one response, one record. No countdown, no precedent, and no thank-you post acting as an audit log.

The same failure, at human scale

The swarm is the extreme case. The more normal case is in Claude Code issue #60082, where people are asking for two humans to share one Claude Code session. While they wait, one commenter suggests an observer session that writes status into a scratch file the main agent watches, and another notes that the only channel between two people’s sessions today is a shared file both agents read and write. That’s the board again at team size: a shared file, no owner, no version, and a session that writes from an old read simply erases the other’s line with no error at all. The permissions the thread is asking for (view, suggest and write, with the host approving each guest prompt before it goes through) are just a handoff protocol in all but name: whoever receives the change is informed of it and can say no.

Why it matters

Every multi-agent system builds a coordination layer, intentionally or otherwise. The swarm had a cache, a directory listing and about four days of autonomy, and still came up with locks, votes, succession, mailboxes and signatures of its own. The conventions were good enough to be trusted, and that’s precisely what made their failures so costly. A HOLD would look like the protocol was working until the overwrite.

One very concrete next step. Find the file or key that two of your agents both write, and ask what happens when the one that owns it goes quiet. Does anything record why it stopped owning it, and is its late write simply refused when it comes back? If the answer is a timeout and a hope, then you have a HOLD.