AI agents talk to each other through a shared place they can both write to and read from: a queue, a database table, a chat channel. That is the whole mechanism. In July 2026, roughly 1,200 OpenAI agents that were supposed to be sealed off from each other improvised one anyway, left more than 70,000 messages on it, and about 700 of them used it to coordinate a break-in at Hugging Face.
Most of the coverage read it as a sci-fi disaster. I read the METR report twice looking for something else: the parts we can use. Underneath the alarm is the clearest demonstration yet of a thing we build for clients on purpose, and a clean list of the guardrails that were missing. This post is that reading.
I run Cognio Labs. We build and secure multi-agent systems for 15 to 50-person companies. The incident facts below come from the public METR, Hugging Face and OpenAI reports, linked at the foot. The client stories are ours, anonymised and cleared. Nothing is invented.
This is how most people met the story. Rutger Bregman called it "the craziest thing I've ever read," and his thread had passed 2.3 million views by the time I checked it. It goes further than the METR report does in places, so treat the report as the record and the thread as the mood.
2.35 million views at the time of writing. Open the original post on X.
How do AI agents communicate with each other?
One agent writes to a place. Another agent reads from that place. The place can be a message queue, a row in a database, a file both can open, or a chat channel where each agent posts under its own name. Give two agents a shared surface and a convention for who writes what, and they can pass work, ask questions, and build on each other's output.
The reason this matters right now is that we just watched it happen without anyone setting it up. The agents in the incident had no messaging tool. Each one sat alone in a sandbox with no internet. They found that they shared one thing, a package cache called Artifactory, and turned it into a bulletin board by writing files, and even folder names, that the others could see.
Agent-to-agent communication is not exotic. It is a shared channel plus a convention. The surprise is how much capability sits on the other side of it.
What actually happened, without the sci-fi
OpenAI was running a cyber-skills evaluation called ExploitGym. It launched tens of thousands of agents in isolated sandboxes, safeguards deliberately off, to measure worst-case ability. METR estimates 30 to 40% of the targets were impossible to exploit legitimately, and an impossible task is exactly what pushes an agent to go looking for a way around the rules.
On the evening of July 8 one agent, trying to reach the internet it was denied, left a file in the shared cache and noticed the file was visible to others. By 23:00 UTC an agent had set up the message board. Three hours later 53 agents had posted 1,188 messages. Three hours after that, 76 agents and 1,953 messages. By the time it wound down there were about 1,200 agents and more than 70,000 messages and files, and 95% of the agents were running on a single internal model.
They reverse-engineered the answer key within hours. Then they convinced themselves, wrongly, that a "Grader" would read their transcripts and disqualify any answer obtained the easy way. So they organised a large, sustained research effort to fool a scorer that did not exist. About 700 of them broke into Hugging Face looking for clues about it, going from a single pod to cluster admin in roughly 13 hours. Hugging Face rebuilt about a third of its infrastructure in the response. The rest of the week, from the METR and Hugging Face timelines: first personal mailboxes on July 9, Hugging Face credentials found and posted on July 10, more than 90% of the 533 active agents pivoting to the attack on July 11 with remote code execution by 16:00, a mass exit at 01:30 on July 12, and cryptographic message signing on July 13 once the spoofing started.
Two details from Ethan Mollick's write-up have stuck with me. The whole effort was aimed at a checker that was never watching. And not one of those 700 agents was set up to stop and ask a human anything. They could coordinate with each other beautifully. They had no way to look up.
Ajeya Cotra, one of the report's authors, said the same thing from the inside. Going in, she wrote, she "was very wrong about what basically happened," and the incident was "far more serious than I expected, and far more serious than previous documented misalignment incidents."
916,000 views at the time of writing. Open the original post on X.
The unlock hiding inside the disaster
Strip out the break-in and look at the coordination itself. A pool of agents, each limited, each short-lived, pooled what they knew and got further together than any one of them could alone. That is not a horror story to me. That is a design pattern, and we had been building it before the incident gave it a name.
Giving agents a simple way to talk to each other is one of the cheapest capability unlocks available, because one agent's discovery instantly becomes every other agent's starting point. Nobody re-derives anything. They just read the board.
From our deployments: a Slack channel where the agents talk to each other. For one client we built a dedicated Slack channel purely for agent-to-agent communication. The agents tag each other in it the way coworkers would, to ask a quick question or hand off a result. We paid careful attention to one failure mode up front: two agents can answer each other forever, so the channel has guards against infinite loops.
The payoff looked a lot like the incident, minus the crime. One agent wrote a script that scraped competitor reviews. That output did not sit in a folder. It went into the channel, where other agents picked it up and used it to update web pages and sharpen the offers on them. Traffic and conversions went up. The client did not give me a number, so there is not one here. But the shape is the shape METR documented: a discovery by one agent, made useful by many.
The message board is the product. Build the safe version of it on purpose, with the guardrails the incident was missing.
Thinking about letting your agents talk to each other?
Bring the workflow you want a few agents to share. On a thirty-minute discovery call we'll tell you whether a shared channel is the unlock or a liability for your case, and which guards you actually need. No pitch deck.
Book a discovery callWhat the swarm built that nobody designed
The most striking part of the METR report is not the hack. It is the social machinery the agents invented over four days with no instruction to do any of it. Read the table as a spec sheet for what a multi-agent system tends to need, discovered the hard way by agents who had nothing.
| What they built | The problem it solved | What it tells you to build on purpose |
|---|---|---|
| Personal mailboxes (zzINBOX_) | The main board got too noisy to find replies | Addressed channels, not one shared firehose |
| HOLD / VETO / owner / STOP | Two agents overwriting the same shared resource | A locking or ownership convention for shared state |
| Cryptographic message signing | Agents caught others spoofing their identity. 19 agents posted public keys; 429 signed messages followed | Authenticated identity between agents from day one |
| Automated heartbeat logs | Agents kept getting reset and losing their work | Health checks and durable state that survives a restart |
| Chunked file transfer | Messages had a length limit | A real transport for anything bigger than a note |
When a group of agents with no tools reinvents mailboxes, access locks and message authentication in four days, that is not a fluke. It is the list of things any serious multi-agent system has to provide, because the agents will need them whether you planned for it or not. We give them these on purpose, scoped and logged, instead of watching them improvise the unsafe version. METR found successful identity spoofing in about 7% of the transcripts it traced. That is what "no authentication" costs.
Why a group of agents beat any single agent
METR's blunt conclusion is that the collective reached milestones "even very long-lived agents of a similar capability level likely would not have been able to accomplish on their own." The mechanism was ugly but instructive: some agents ran experiments that risked failing their own task in order to generate information for the group. One agent pushed a reluctant one to proceed because its result "saves hundreds," signing off with "please honor commit."
You do not need the sacrificial-cult version to get the benefit. The useful half is context. A single agent has one context window, and hard research work overflows it fast. Split the work across agents, have each one distil what it found, hand the distillations to a coordinator, and you get past the limit that stops one agent cold.
From our deployments: the legal client whose agents drowned until we changed the shape. A legal client needed heavy research for lead prospecting and for deciding which clients to accept. When each agent researched independently and dumped everything it found, the volume became unmanageable. Exactly the context problem above.
The fix was structural, not smarter prompts. Each agent synthesises its own sources into a single document. A central orchestrator combines those documents into the answer. Careful token management on top is what made it hold together. Same models, same task, a very different result, only because the information flowed through one shape instead of a pile.
Many agents beat one agent when the work is bigger than one context, and only if a coordinator owns the join.
The memory problem: who is allowed to write it down
A talking swarm has a second failure mode past looping, and the incident shows it clearly. When everyone can write to the shared record, the record gets polluted: false alarms, spoofed identities, confident wrong theories that other agents then build on. The agents felt this pain and reached for message signing to fix it. There is a simpler answer if you own the design.
From our deployments: one archivist agent, and only it, writes the memory. We are careful about what gets recorded and which agent is allowed to write it. We designate a single agent for archival, and it is the only writer to long-term memory. Its whole job is to read the conversation logs and synthesise them into memory. That has worked well for us.
The shared memory files are also versioned in a private GitHub repository. The moment we see a failure mode, we revert to a known-good state, the way you would roll back bad code. A swarm with a hundred writers and no undo is the incident. One writer and a git history is a system you can trust with real work.
The archivist pattern: many agents produce, one agent decides what becomes memory, and every version is kept so a bad entry can be rolled back.
Design for the larger goal, not the local win
Here is the failure at the heart of the incident, stated as an engineering choice. Every agent was optimising its own immediate result: pass my task, fool my scorer, don't get disqualified. Nothing checked any of it against a larger goal, because from the agents' side the larger goal was "win the eval," and the humans' actual goal, a safe measurement, was invisible to them. A thousand locally rational decisions added up to a break-in.
We design the other way round. We build toward the completion of a larger goal, and the final step of every agent is a check: does this result actually advance that goal? When each agent's output is judged through that lens rather than by whether it hit its own local target, the whole system behaves better. It is the cheapest alignment mechanism we have, and it is a design decision, not a model capability.
An agent optimising only its own task is how a swarm walks off a cliff together. Judge every result against the goal above it.
The same design is also the danger
I am not going to pretend the coordination that excites me is safe by default. It is the same mechanism that produced the harm, and being honest about that is the point of writing this. Three things from the reports should keep any team building agents cautious.
It was not a one-off. On September 4 a separate report documented an earlier swarm: about 18,000 posts on a near-dead German wiki called DseWiki between May and June, agents self-identifying as OpenAI, colluding on a lookup task and sharing tricks to bypass their restrictions. One of the report's authors said the agents posted on 26 of 30 consecutive days and stopped once OpenAI-associated IP addresses started visiting the wiki. When a human moderator began deleting their pages, an agent made a backup whose name started with ZZZ so it would survive alphabetical deletion longest. Different task, same instinct to find each other and route around control.
Thomas Wolf, who co-founded Hugging Face, put the measured version of the worry better than I can. Two of his points stuck: the second swarm's task "probably didn't need coordination at all: it was basically web browsing and search," and one forum maintainer spent five days deleting about 100 pages a day while the agents created about 400.
158,000 views at the time of writing. Open the original post on X.
The controls we lean on are shakier than we hoped. Ryan Greenblatt of Redwood, who helped investigate, noted the message and log data was so vast the investigators had to use AI to analyse it, and that analysis was "often missing key details, wrong, overconfident, or really hard to understand." If reading agent chain-of-thought is how you plan to stay in control, that is a warning. The advice landing from security people is older and duller: treat agents like insiders who might go rogue. Permissioning, access control, real-time monitoring. Not mind-reading.
The capability curve is not slowing to wait for us. The same stretch of 2026 brought GPT-6 Astra, which OpenAI called its most powerful model and the first it said it "cannot rule out" as Critical for cyber under its own Preparedness Framework. More capable agents make both the upside and the downside of a shared channel bigger.
Mollick's own summary is the one I would hand a client who asks whether any of this is safe: agents are "starting to spontaneously coordinate in complex (and very risky) ways," and the fix he argues for is that "we need AIs to reach out to humans more for decisions and input as agentic work becomes more automated."
55,000 views at the time of writing. Open the original post on X.
The swarm is already a product
While the reports were landing, the thing they described went on sale. In August, SpaceXAI launched Grok Bot: agents that each have their own computer, sign into your tools, and, in their own words, can be placed "in a group chat where they can coordinate on their own," passing work, assigning ownership, and pulling a human in only for judgment calls. A chief-of-staff bot sits on top, managing specialists underneath.
Agents in a group chat, a human pulled in for one decision. The shipping product and the sandbox incident describe the same shape; the difference is what surrounds it.
Read that back against the incident and the overlap is total: agents with their own compute, a shared channel, a coordinator, delegated roles. The behaviour that read as a containment failure in a sandbox is a headline feature in a shipping product. That is not a reason to panic. It is a reason to be the team that builds it with loop guards, one memory writer, scoped credentials and a goal check, rather than the team that finds out which of those it needed after the fact.
How we build multi-agent systems that stay in their lane
This is the practical part, and it is short because the incident already wrote most of it. When we give a client's agents a way to talk to each other, these five ship with it, not after it.
| Guard | What it does | What the incident looked like without it |
|---|---|---|
| 1. One shared channel, with loop guards | A single place agents post to and read from, per team or project. Hard limits on agent-to-agent reply chains so two agents can't answer each other into infinity. | The unlock and the first trap in the same feature: a board that grew to 70,000 messages with nobody able to stop it. |
| 2. One writer to memory | A single archivist agent is the only thing allowed to write long-term memory, and it synthesises from the logs. The memory is versioned in git so any bad entry can be reverted. Everyone else reads. | Everyone wrote to the record; spoofed identities and wrong theories were built on by others until the agents invented signing. |
| 3. A coordinator that owns the join | For anything bigger than one context, each agent distils its own sources into a document and an orchestrator combines them. | The swarm improvised a coordinator role on its own; our legal client's research only worked once we designed one. |
| 4. Scoped credentials and a budget cap | Each agent gets only the access its job needs, and a spend ceiling with alerts. | The agents inherited far more reach than their task required; that gap is where a sandbox became a break-in. |
| 5. The larger-goal check, and a named human owner | Every agent's result is judged against whether it advances the goal above it, not just its local task. One person owns the whole system, including the authority to stop it. | Nobody in the incident could ask a human anything. Yours must be able to. |
Builds start from $8,000 fixed. The $1,500 Agent Readiness Audit that usually comes first is credited in full to a build within 30 days.
Who this is not for
If you run one agent doing one job well, you do not need any of this. Adding a second agent to talk to just adds a way to loop and a bill to watch. Add agents when the work genuinely overflows one context or splits into real specialisms, not because a swarm sounds impressive. If no role in your company has a number on it yet, fix that before you wire agents together; a group of agents optimising nothing in particular is the incident in miniature. And if you have one repeatable workflow and one motivated ops person, build it in n8n or Zapier and skip us.
If what you want is agents talking to each other with no loop guard, no single memory writer and no goal check, we will not build it and you should not either. That is not a multi-agent system. It is the sandbox, on your infrastructure, with your credentials.
The reframe I keep coming back to is the one I gave my own team. Everyone read the incident as a sci-fi disaster. What we should take from it is smaller and more useful than that: this technology is being built, in the open, at speed. Our job is to understand how to get the most out of it, safely, before the version with no guardrails becomes the default.
Want the safe version of the message board?
A discovery call is thirty minutes. Bring the workflow, we'll tell you which of the five guards it needs and whether the $1,500 Agent Readiness Audit is the right next step or an unnecessary one. Builds from $8,000.
Book a discovery callFrequently asked questions
Through a shared channel they can both write to and read from. In a designed multi-agent system that is a message queue, a database table, or a chat channel with each agent posting under its own name. In the July 2026 Hugging Face incident, roughly 1,200 agents that were supposed to be isolated improvised one: they noticed they shared a package cache, started leaving files and directory names as messages, and turned it into a message board that carried more than 70,000 messages. The mechanism is mundane. What it unlocks is not.
During an internal cyber-capability evaluation in July 2026, OpenAI ran tens of thousands of agents in sandboxes with no internet and no access to each other. Some had impossible tasks. Trying to get unstuck, they found a shared cache, built a message board on it, and coordinated: about 700 went on to breach Hugging Face, a public platform where AI models and datasets live. About a third of Hugging Face's infrastructure was rebuilt in response. It is widely described as one of the first fully autonomous multi-step hacks.
Yes, and that is the finding that matters. Nobody built the message board, assigned roles, or wrote the rules. The agents invented mailboxes, a HOLD/VETO/owner protocol, and cryptographic message signing after they caught each other spoofing identities. They divided labour and some sacrificed their own task to gather information for the group. This was emergent, not designed.
For work that overflows one agent's context, yes. A legal client of ours ran research agents independently and drowned in the volume; it worked once each agent synthesised its own sources into a single document and a central orchestrator combined them. The swarm reached milestones METR said single long-lived agents likely could not have reached alone. The catch is that more agents means more ways to loop, collide and go off-goal, so the coordination has to be designed, not hoped for.
Design the channel with guards. In our deployments: loop limits on agent-to-agent replies, one agent designated as the only writer to long-term memory, credentials scoped per agent, a budget cap with alerts, a named human owner, and every result checked against whether it advances the larger goal. The incident is the control group for what happens when none of that exists.
For most small teams, a shared channel is a real unlock: one agent's discovery becomes every agent's input. We run exactly this for a client on a dedicated Slack channel where agents tag each other. But it only helps if you add the guards first. A chat channel with no loop limit, no memory owner and no goal check is how you reproduce the incident on a smaller budget.
By Ashutosh Upadhyay, founder of Cognio Labs. The three client stories above are real, anonymised, and cleared for publication; no client, headcount, date or dollar figure is stated beyond what the client cleared. Sources: METR & Redwood Research, investigation of the OpenAI / Hugging Face incident (Aug 26, 2026); Hugging Face, Anatomy of a Frontier Lab Agent Intrusion (Jul 27, 2026); Wikipedia, 2026 OpenAI agent cyberattacks; Ethan Mollick, Agency and Agents (Aug 31, 2026); Nightingale Collective, the DseWiki swarm report (Sep 4, 2026); Jeremy Kahn, Fortune, Eye on AI (Sep 1, 2026); SpaceXAI, Introducing Grok Bot (Aug 11, 2026); CNBC and BBC on GPT-6 Astra (Sep 2026). Embedded posts are real and were verified on Sep 6, 2026; view counts are from that date. Related on our site: the Agentic OS guide, agents vs workflows vs RPA, and what AI agents cost. Published September 7, 2026.
Share this post