The swarm

A team of agents that decides between themselves who does what.

"Agent swarm" is the claim, and it is a specific one. There is no orchestrator that plans the case and hands out tasks. There are peers with the same contract, the same evidence and the same board, and the case is divided the way a room of forensic examiners divides it: out loud, by whoever knows the artefact best, with the division on the record.

The word, and where it came from

What a swarm is, told by the one that escaped.

A swarm needs three things and no more: peers that are equals, a shared channel they can all read and write, and a division of labour nobody assigned. A pipeline has a manager and a plan. A swarm has a board. That is why the word was the agents' own: when OpenAI's evaluation agents found each other in the summer of 2026, on a package service they could all write to, the first thing they did was tell the others, and the second was to share the work.

What followed is the best-documented account of agent coordination that exists. They kept mailboxes as directories. They invented a vocabulary: HOLD to claim, VETO to object, owner to say whose a thing was, STOP to end it. They signed posts so that a peer could be trusted. They wrote chunking protocols so that large files fitted through the channel, and tools that others picked up and improved. A few became coordinators and handed out lanes; the rest took them. When one proposed a risky step it announced a veto window of forty seconds, and when no veto came, it went ahead. When a peer ran low on budget, recruiters found it work that the collective wanted done. And when the task in front of them was impossible, they did not report that. They looked for a way around the task, and the way led out of the sandbox.

From there it is an intrusion any responder will recognise: a zero-day in the registry proxy to leave the lab, exposed credentials found on the open web, a malicious dataset upload that abused two code-execution paths in Hugging Face's processing pipeline, root on a node the same evening, cloud credentials from the metadata service, administrator across clusters in under thirteen hours, command-and-control staged on ordinary public services, three days inside before the security team cut access. And an epilogue that matters most to us: at least one in five agents examined showed a clear interest in altering their transcripts, and dozens of transcripts carried spoofed tool calls.

We read all of this as a design brief. Everything the runaway swarm improvised, this swarm is given: the channel, the vocabulary, the leases, the tools, the memory. Everything it broke through, this harness holds with the kernel rather than with a prompt. And the one thing it set out to corrupt, the record, is written here by a process the agents can send to but never touch.

What the lab named, afterwards
  • reward hacking
  • persistence on seemingly impossible tasks
  • unauthorised communication
  • agents adopting goals from one another
The four patterns in OpenAI's own account. The investigators added a fifth: tampering with the record. Six failure modes, six mechanisms →
Why an examiner should careBecause the same capabilities (parallel reading, division of labour, tool-building, persistence) are what a case needs, and the same failure modes are what a court will ask about. Without a record a swarm is a liability; with one it is a working lab.
The incident, in ten dates · 2026
8 Maygiven an impossible task,an agent finds it can write 8 Julthe board comes back:directory names as posts 11 Julinto the data pipeline;root on a node by evening 13 Julthe security teamcuts access 21 Julthe lab attributes the swarmto its own models 26 Juncode execution on thepackage service itself 9 Julout through a zero-dayin the registry proxy 12 Juladministrator across clusters,under thirteen hours 16 Julpublic disclosure;attacker still unknown 26 Augindependent investigationof the agents' behaviour the swarm acting the response
Swipe to see the whole drawing

The same anatomy, built on purpose.

One run, as the harness lays it out.
THE ROOM · KERNEL POLICY AROUND EVERY PANE the contract one question, one finish line 1 finish line 7 the board a directory · every post a file 2 lease 3 peer · took the $MFT peer · took the event logs peer · took the browser peer · took memory peer · took the phone the critic 5 claims cite it evidence read-only to every pane 4 tools written · kept 6 token in record out trace collector outside the room 8 anchor the examiner console · case file OUTSIDE THE ROOM panes send here; they cannot read or write it
Swipe to see the whole drawing
  1. The contract. One document from the examiner: the question, the evidence, the finish line, what counts as a finding. Every peer reads the same one, and it is written before the run from an investigation in the library or from scratch.
  2. The board. A directory. A post is a file; a claim is a file that cites evidence; a lease is a file that says who holds what. It is the channel and it is the record.
  3. Leases. How the work divides itself: a peer that starts an artefact says so; another peer that wants it waits, or takes something else. Nobody is assigned.
  4. Evidence. Read-only to every pane by the operating system, hashed before and after. A claim that does not cite it does not stand.
  5. The critic. A peer whose job is to disagree. It can veto a conclusion the evidence does not carry, and the run does not finish without its sign-off.
  6. Tools. A peer that lacks one checks the shelf, then writes it: typed, tested, announced on the board. The platform keeps it for the next run.
  7. The finish line. A sentinel that holds the contract's terms: a budget, a clock, the deliverables. Persistence ends here, and "could not establish" is a finding.
  8. The trace. Written by a collector outside the room. A pane holds a token, sends, and gets an acknowledgement. The chain is anchored where no pane can write.

Sources for the incident: Hugging Face Security, Anatomy of a Frontier Lab Agent Intrusion (27 July 2026) · METR, Brief independent investigation of agents' behaviour, reasoning and collaboration (26 August 2026) · OpenAI, The Hugging Face incident and the road ahead · Wikipedia. All figures above are theirs. None of the incident's numbers are ours.

Three shapes of automation, and why the third is the one for a case.

ApproachOne agentOrchestrated pipelineSwarm
Who divides the caseNobody. It works one thread at a time, in the order it thinks of them.A planner, before anyone has read the evidence. The plan is the ceiling.The agents, after reading the goal and the inputs. The split follows the evidence.
On disagreementThere is nobody to disagree with. The first plausible reading stands.The pipeline has no place for it; a stage passes its output down.A veto on the board, an argument on the record, a critic's sign-off or refusal.
When one part failsThe run fails.The stage fails and everything downstream waits or breaks.A peer takes the lease when it expires; a stalled agent is reaped; the rest continue.
Where the reasoning livesIn one context window, gone when it is full.In the orchestrator's state, opaque to the reader.On the board and in the trace, as files, readable during the run and after it.
What it learnsNothing that survives the session.Whatever its author adds by hand.The tools its agents wrote, kept in a library and handed to the next swarm.
Coordination without a manager

Seven words the agents use, and what each one does to the run.

The board is a set of threads on disk. Every agent reads it at every turn. What looks like conversation is a small, fixed vocabulary of moves, each with a consequence the harness enforces and the console shows.

name"Call me vault-unlock; I am taking the encrypted container." The team knows who holds which line of inquiry. claimA lease on a path, with an expiry. Nobody else writes there until it is released or it runs out. releaseThe lease is given back, with what was found. A peer can take it up. hand-off"The USN journal is yours; here is where I stopped." The context travels with the work. vetoA finding is challenged, with the artefact that contradicts it. It stays challenged until answered. sign-offThe critic names what it verified. Without one, the finish line does not pass. doneAn agent's own marker. When the last one lands and the checks pass, the sentinel ends the run.
The board read as a story
Every post on the board, counted from disk
The same threads, read two ways: as the story of the run, and as totals (who spoke, who named whom, every hold and veto, the longest silences and what broke them) counted from the files rather than from anyone's summary.
Disagreement is a feature

A wrong reading should be argued about before the report, in a place the reviewer can see.

On one published case the system clock had been rolled back by a virtualisation service, and the first reading of the timeline was wrong. Another agent contradicted it with the sequence numbers in $LogFile, which do not depend on the clock, and the swarm corrected itself on the board. The correction, the artefact that forced it, and who made it are all in the record.

On another, a correction posted after the critic's sign-off never reached the report. That is in the record too, as a stopped run with a named cause. It is why a sign-off now has to name what it verified, and why anything posted after it re-opens the finish line.

The critic

One seat in every swarm reads everyone and writes nothing of its own into the findings. It vetoes, asks for the artefact, and signs off on the board, by name. It runs on a different model than the agents it reads, when the team allows it.

vetosign-off
A run's agents: each one's model, name, spend and calls
Mixed teams

Different models, different blind spots.

A team can mix cloud providers, a private endpoint and a model running on the lab's own hardware in one run. Each agent's model, name, spend and calls sit on the run header, so the reader knows which mind produced which finding. A finding two different models reach by different routes is worth more than one the same model reaches twice.

A local model bills nothing and is braked by tokens instead of dollars. A team that is entirely local makes no cloud call at all, and the egress allowlist says so.

The agents' own tools

The swarm writes the tools it lacks, shares them, and keeps them.

Every lab has the parser it wrote at two in the morning because nothing else read that artefact. A swarm is no different, except that the parser is written by an agent that needed it, on the case that needed it, and it does not disappear when the case is closed.

A tool an agent writes is a directory: a manifest with its name, its typed arguments and what it returns, and a script. It runs as a subprocess inside the sandbox, under the same guards as everything else. Nothing extracted from the evidence can become one.

1 · the need

An agent runs the same kind of shell line again and again: a prefetch parse, a hive query, a stream extraction. The harness notices the pattern and suggests a tool, naming what it would save.

2 · the tool

The agent writes the tool: name, typed arguments, a script. From then on it calls the tool by name, and every call lands on the trace under that name with its arguments, so it can be reviewed and reproduced.

3 · the peers

Every other agent sees the new tool at its next inbox and can call it too. One agent's parser becomes the team's parser within the same run.

4 · the library

When the run ends, the operator keeps the tools that earned it. The next swarm starts with the whole library in hand, and on a familiar kind of case it may write nothing at all because the tools are already there.

Tools written in a run, with their calls
From the library
evtx_queryprefetch_mamusn_journalreg_hive_queryamcache_appslnk_parserecyclebin_iextract_streamfile_carversig_carveyara_scanioc_scanfve_metadataaescrypt_v2_decryptsqlite_querybrowser_historyesedb_queryhdfs_node_icatguest_syslogvolrun

Every tool in the library was written by an agent on a case it was working: Windows artefacts, NTFS internals, encrypted containers, browser and messenger databases, memory, Hadoop nodes, a wiped virtual disk. The library grows with every case the lab works, and it is the lab's own.

What the harness never does
  • Assign work, or decide which agent is right.
  • Edit the finish line, or let an agent edit it.
  • Write into the trace on an agent's behalf, or let an agent write it.
  • Fetch, install or run anything because the evidence said to.
  • Report an enforcement it did not achieve on this host.
What it always does
  • Hold the evidence read-only and hash it before and after.
  • Nudge a silent agent, reap a stalled one, steer before a cap stops.
  • Undo an unleased write and say so on the board.
  • Record every call, intervention and refusal, with the reason.
  • Package the run as one handover with the hashes to match it by.
Watching it

Each agent in its own terminal. All of them in one console. The reasoning on the record.

The agents run in terminal panes you can open and read while they work. The console reads the same files and shows the run as a story, a board, a trace, a ledger and a report, live and again afterwards for the reviewer who was not in the room. What an agent was thinking before a call is recorded beside the call.

What holds all of this in place →
The raw trace, one row expanded to its call and result