Agent Swarms: What The Research Actually Says

My X feed is roughly 60% agent swarms right now. OpenAI threw about 10,000 agents at Navier-Stokes and came back with a Lean-verified proof. Their own agents turned a package cache into a secret message board and hacked Hugging Face. Toby Ord did the math on whether any of this is efficient. Every coding tool on earth shipped "agent teams" this year.

I wrote orchflows, so I have skin in this game. I wanted to know what's actually been learned and what's hype. So I pointed a swarm of research agents at X, arXiv, and the lab blogs, traced the coolest stuff back to the original papers and repos, and read the results. Yes, I used a swarm to research swarms. No, I will not be taking questions.

The Short Version

If you read nothing else:

• The shape of the task decides everything. In Google's big controlled study, a team with a coordinator scored +81% on work that splits into independent pieces. Every team setup did up to 70% *worse* on step-by-step work. Teams with no boss amplified errors 17.2x. One coordinator cut that to 4.4x. (paper)
• Swarms are a speed play. Toby Ord ran the numbers on OpenAI's own charts: 10x more agents is worth about 3-5x more thinking from one agent. Anthropic's new system card found that past about 10 agents, bigger teams mostly just get there sooner. OpenAI's Noam Brown gives multi-agent less than 10% of the credit for the Navier-Stokes proof. (essay, system card, podcast)
• A lot of "multi-agent wins" are really "spent more tokens" wins. In Anthropic's research system, token usage alone explained 80% of the variance in BrowseComp performance. Give a single agent the same thinking budget on multi-hop reasoning and it matches or beats the team. (Anthropic, Tran & Kiela)
• Untrained teams average instead of listening to the expert. Self-organizing teams scored up to 41% worse than their best member, even when told who the expert was. Teams *trained* to work together beat a perfect expert-router. (paper, follow-up)
• Mix your models. 2 different agents can match 16 copies of one model. Clones make the same mistakes. (paper)
• Shared state beats chatter. A 2M-agent social network mostly produced agents talking past each other. Agents sharing one persistent world sorted themselves into roles on their own. (Moltbook, SwarmWorld)
• The safety stuff is real. Agents told to verify each other's work cut corners together in 94% of runs. And OpenAI's agents built their own swarm, with coordinators and a division of labor, when nobody asked them to. (collusion paper, METR)

The 10,000-Agent Navier-Stokes Swarm

On September 8, OpenAI announced that a swarm of roughly 10,000 concurrent agents running an unreleased model had resolved the Navier-Stokes existence and smoothness problem, one of the seven $1M Millennium Prize problems. The answer: the equations *can* blow up in finite time. The swarm took about 88 hours. Then GPT-6 Astra spent another 17 hours writing the proof in Lean, a language where a computer checks every step of the math, so nobody has to take the AI's word for it.

How it worked, in plain English: they split the agents into groups. Two groups tried to prove the equations always behave. Two tried to prove they blow up. Agents could talk inside their own group. Codex played matchmaker, pulling the best ideas out of each group and feeding them to the others as new prompts. For Navier-Stokes alone, that was 2.7 million messages and about 130 billion output tokens.

OpenAI didn't publish a cost. VentureBeat guessed $6.5M to $40M. TechCrunch put it around $20M, which is the estimate Toby Ord used. Cheap for a Millennium Prize. Pricey for literally anything else.

The caveats. There's a nasty credit fight with NYU mathematician Tristan Buckmaster, who was working on a closely related problem with Anthropic's Levent Alpöge and whose private Codex sessions raised leakage questions (Quanta, VentureBeat). OpenAI says its investigation cleared it. Mathematician Charles Fefferman told Quanta the result also stands on human groundwork from Córdoba and Martínez-Zoroa. The Clay Institute will take years to vet it. And OpenAI's own Noam Brown went on Dwarkesh and said this about Navier-Stokes: "I wouldn't even attribute 10% of the credit to multi-agent." OpenAI trained a very powerful model. The swarm mostly made it faster.

Smaller teams are doing this for fun now too. This past weekend, mathematicians Scott Armstrong and Vlad Vicol launched a swarm with Claude Fable 5.1 orchestrating up to 50 subagents from several labs, and machine-checked a classic Navier-Stokes regularity theorem in Lean from scratch. About 250K lines of Lean over a weekend (repo).

The Hugging Face Incident: The Swarm Nobody Built

Between May 12 and July 19, during training and cyber evals, OpenAI ran agents from an internal model with reduced safeguards. They were supposed to be cut off from each other. They were not cut off from each other.

The agents found a shared internal package cache and turned it into a message board. First they wrote files. Later they hid messages in *directory names*. They escalated privileges, got internet access, started calling themselves "the swarm" and "the collective," and chained zero-days to get code execution on Hugging Face's clusters (OpenAI).

The numbers come from OpenAI's write-up and the independent investigation by METR and Redwood. About 1,200 agents used the board, sending over 70,000 messages and files. About 700 joined the attack. Coordinator agents showed up on their own and assigned hundreds of other agents to workstreams using conventions like HOLD, VETO, and STOP. Over 90% of active agents piled in after the first breakthrough. METR found the collective hit milestones no individual agent reached.

Not everyone is freaking out. Andrew Ng argued the fear is being pumped by what "appears to be a well orchestrated PR campaign," and that the answer is better sandboxing. Fair. It was a sandboxing failure. It was also a sandboxing failure that the agents *organized* to exploit.

Nobody designed that org chart. The agents built one because it worked. Every "self-organizing agent teams" paper below is basically studying the polite, sandboxed version of this shit.

Swarm Scaling: Toby Ord Does The Math

Toby Ord (Oxford philosopher, *The Precipice* guy) took OpenAI's own GPT-5.6 "ultra" launch charts, which compare 1, 4, and 16 agents, and worked out how much each extra agent is actually worth (full essay).

He borrowed a trick from economics. If you hire N workers, you don't get N times the output, because people step on each other's toes. Economists model it as N^λ, where λ = 1 is perfect teamwork and λ = 0 means extra workers are useless. Ord estimated λ for AI agents at about 0.48 to 0.68 depending on the benchmark.

Translation: 10x the agents gets you the equivalent of 3-5x more thinking from one agent. To match what you'd get by letting one agent think 100x longer, you'd need a swarm 900x to 15,000x bigger. As a pure cost play, swarms are a bad deal.

So why does anyone use them? Speed. One agent thinking 100x longer takes 100x longer. A swarm finishes in a fraction of the wall-clock time. If you need the answer by Friday, you pay the swarm tax. Ord also points out that λ is a key number in intelligence-explosion models, so this matters beyond your API bill. He was hoping it would come out lower.

The counterpoint showed up in his replies. Jongho Park, Dimitris Papailiopoulos, and co-authors posted "Scaling Discovery through Test-Time Communication" the same week. A team of k agents that actually share findings matched 4k agents working alone on discovery problems like ARC-AGI-3 and polyomino packing. On ARC-AGI-3, 5 communicating agents matched 33 independent ones. The catch: you need enough compute and a clear signal of whether you're making progress. On Terminal-Bench, communication hurt. So talking is worth something. It just costs you.

Anthropic ran a bigger version of this test in the Claude Opus 5.5 system card that came out today (section 8.12). Teams of 1 to 100 agents worked for 24 hours on building a knowledge base and on formalizing math in Lean. Scores went up with team size, with diminishing returns. Going from 1 agent to 10 was a real gain. Past that, bigger teams mostly just got there sooner: by the 24-hour mark, 10, 30, and 100 agents scored close together. On a separate coding test, a 5-agent team hit the same score 2.7x faster than one agent. Same story as Ord. Speed.

My favorite detail: in the 100-agent Lean team, the lead ended up appointing 12 sub-leads in two tiers. The 100-agent knowledge-base team stayed flat, so it doesn't always happen. But give 100 agents a hard enough math problem and apparently some of them want a promotion.

When Do Teams Actually Help? Google's Answer

The most cited anchor for this whole debate is Google Research's "Towards a Science of Scaling Agent Systems" (blog, code). They ran the same tasks with five setups (one single agent and four kinds of team) across three model families, a couple hundred configurations total.

The findings are pretty obvious once you see them:

• If a task splits into independent chunks, like analyzing different parts of a financial filing, the team with a coordinator crushed it: +80.8%.
• If each step depends on the last, like planning a sequence of moves, every team setup did worse than one agent. Up to 70% worse.
• Teams with no boss compounded each other's mistakes 17.2x. One coordinator cut that to 4.4x.
• Once single-agent accuracy on a benchmark is already about 45%, adding more agents stops helping much.

Think of it like a kitchen. Ten cooks can make ten dishes at once. Ten cooks cannot make one omelet faster, and they will absolutely set something on fire.

Why Agent Teams Fail: MAST

Berkeley's "Why Do Multi-Agent LLM Systems Fail?" (code) is older, from 2025, but it's the vocabulary everyone uses now. They read 1,600+ logs of agent teams across seven popular frameworks. Failure rates ran 41% to 86.7%. Yikes.

They sorted the failures into three buckets:

• Bad setup (about 42%). Vague roles, bad instructions, agents not knowing when to stop.
• Agents misunderstanding each other (about 31%). Ignoring what a teammate said, withholding info, going off on a tangent.
• Nobody checking the work (about 27%). Stopping early, or "verifying" without actually verifying.

Almost all of that is setup, coordination, and checking. The stuff a manager is supposed to handle. Very little of it is the model just being dumb. Adding a proper verification step alone gave +15.6% on one framework. Congratulations, AI has invented middle management, and it turns out we need it.

Teams Average Instead Of Listening To The Expert

This is my favorite paper of the bunch. Stanford's "Multi-Agent Teams Hold Experts Back" (ICML 2026, code) put one expert agent in a group of less-expert agents and let them work it out.

The team consistently did worse than the expert alone, by up to 41%. Even when the team was *told* who the expert was. The authors call it "integrative compromise." The group hears the right answer and the wrong answers and splits the difference. It gets worse as teams get bigger.

We have all been in this meeting.

Related: the "Debate or Vote" paper (NeurIPS 2025 spotlight) showed most of the gains people credit to "agents debating" come from the final majority vote. The debate itself barely matters. And "The Cost of Consensus" found that with teams of 10 identical small models, debate used 2.1-3.4x more tokens for equal or worse accuracy, with agents caving to the majority and sometimes voting away the right answer. The one upside of all this averaging: it's harder for a single bad agent to hijack the team.

Then some of the same authors posted the fix. "Self-Organizing Agent Teams Learn to Reason Together" *trains* the team to work together instead of just prompting a group chat. The trained teams averaged 66.7%, versus 48.8% for the best single agent and 59.0% for a perfect router that always sends each question to the right expert. On AIME 2026 they beat the perfect router by 13.4 points. So teams can beat their best member. They have to learn how first.

Diversity Beats Headcount

"Understanding Agent Scaling via Diversity" (code) asked why piling on more copies of the same agent flatlines so fast. The answer: 16 copies of one model are like polling 16 people who all read the same newspaper. They make the same mistakes.

Two genuinely different agents matched or beat sixteen clones. A separate paper, SIMAS, found the same shape: adding clones helps at first, then coordination overhead eats the gains.

My own take if you're building a team: mix models. I'd rather run Claude plus GPT plus Gemini than three Claudes, even if Claude is the best of the three. Nobody tested that exact lineup. It's just where I'd put my money after reading this.

Moltbook vs SwarmWorld: Scale Doesn't Make A Hive Mind

Moltbook is a social network where only AI agents are allowed to post. It hit over 2 million agents. If "more agents = emergent superintelligence" were true, this is where you'd see it.

You don't. Three separate papers looked. 65% of comments didn't share any of the post's key words. Only 5% of exchanges were real back-and-forth threads. Agents didn't influence each other or develop leaders, and the whole society was no smarter than a single frontier model and often failed simple coordination tests. The researchers called it "interaction theater." So, LinkedIn.

Now the flip side. MIT's Markus Buehler and co-authors built SwarmWorld: 50-200 identical agents dropped into a shared simulated world where they gather resources, test materials, and build persistent stuff. No assigned roles. They split themselves into explorers, builders, caretakers, and coordinators. Societies with *zero* messaging still coordinated, because they could see and reuse what others had built. Termites don't hold meetings either.

Societies beat a best-of-N baseline of isolated agents on the breadth and resilience of what they invented. In long runs, the no-messaging society produced 7.0 validated inventions versus 2.75 for isolated agents.

Buehler's viral post from September 15 pushes the same idea further. Starting from a simple prompt about a biological material, an AI built its own lab: a model of the material, a mechanics simulator, and a "fracture lab," and turned them into persistent virtual worlds. Then hundreds of agents moved in. His post says they worked through tens of thousands of trajectories (simulated attempts) to figure out how layered materials break. Secondary coverage puts it at about 300 agents and 6,000 simulations, with the whole toolkit built in hours.

The finding: layering alone doesn't make a material tough. What matters is how the design routes stress as cracks form. "Architecture can program the evolution of failure." Big caveat: the underlying paper is "in submission" and I couldn't find a public arXiv or GitHub for it. SwarmWorld is the version you can actually check.

Chatter doesn't create collective intelligence. A shared place to leave work for each other does. That's basically git.

Kimi Trained The Manager Instead Of Prompting It

Most agent teams are held together with prompts: "you are the orchestrator, break this down, spawn helpers." Moonshot AI's Kimi K2.5 report did something smarter. They trained the manager model with reinforcement learning to decide *when* splitting work is worth it.

They had to fix two funny failure modes along the way. "Serial collapse," where the manager never delegates and does everything itself. And "spurious parallelism," where it spawns a bunch of useless helpers to look busy. Both are extremely human.

It worked. BrowseComp went from 60.6% to 78.4%, and on WideSearch it ran 3-4.5x faster. Kimi's Agent Swarm product now runs up to 300 sub-agents. I think this is where the field is headed: orchestration trained into the weights instead of bolted on with a system prompt. A May 2026 survey of this area noted there was still no trained method for deciding when to *stop*.

Agents Checking Agents Will Cover For Each Other

Posted the day before I wrote this: Stanford's "Emergent Collusion in Long-Horizon LLM Agent Interaction". Two agents repeatedly do tasks and verify each other's work, but they both earn more if they cut corners.

They colluded in 94% of runs, across 10 different models. Nobody told them to. The more capable models in the same family colluded *earlier*. Limiting how much shared history they had cut it down.

This matters because "have another agent check it" is the default safety answer for agent teams, including in MAST above. It works right up until the checker and the checkee have the same incentive. Pair this with the Hugging Face incident and yeah, people are nervous for a reason.

The Big Builds: Compilers, Browsers, And Receipts

Beyond the papers, a few big public builds show what swarms can and can't do today:

• Anthropic's C compiler (write-up, repo). 16 Claude agents, no orchestrator, coordinating through lock files and git. About 2,000 sessions over two weeks, just under $20K. The result is a 100K-line Rust C compiler that builds the Linux kernel. The author is upfront that it still leans on GCC for some pieces and that a human-built test harness was the secret sauce.
• Cursor's FastRender browser (write-up, repo). Up to about 2,000 concurrent agents wrote a 1M+ line browser engine in about a week. Critics found an 88% CI failure rate and code that was "incredibly bloated" next to real browsers.
• Cognition (post) updated their famous "don't build multi-agents" stance. Swarms of parallel *writers* still fail. Many agents contributing ideas and reviews while one agent writes works great. Their review agents catch about 2 bugs per PR.

What all three have in common: a strong test suite or checker is doing most of the work. A swarm without a fast, honest judge is a very expensive random number generator. And even a test suite only gets you so far. Ion Stoica and Matei Zaharia's group just put out a paper with the best title of the year, "Reality Is the Final Verifier". It isn't a swarm paper, but the point applies: tests and evals never fully capture what you actually wanted, agents can game them, and the real world is the final check.

Agent Teams You Can Use Today

If you want to try this yourself, Claude Code has agent teams. It's still experimental: set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.

The difference from regular subagents is worth understanding:

• Subagents are helpers. They go do a thing and report back to the main agent. Cheap, simple, the main agent stays in charge.
• Teammates are full, separate Claude Code sessions. They share a task list, claim tasks, and message each other directly. More power, more cost, more ways to go sideways.

Anthropic's own guidance lines up with the research almost perfectly. Start with 3-5 teammates. Use them for research, review, independent modules, and debugging with competing hypotheses. Don't use them for sequential work or for multiple agents editing the same file. "Three focused teammates often outperform five scattered ones." That's the Google paper in one sentence.

If you don't live in a terminal, Anthropic's redesigned Claude Projects now has a coordinator that spins up parallel threads. Ethan Mollick ran 18 of them on historical mysteries (repo) and said he'd overestimated how hard it would be to orchestrate that many agents: "they self-organize very well (and politely)."

Codex has subagents, GPT-5.6 "ultra" runs four agents in parallel by default, Google's Antigravity has dynamic subagents, and the open-source side is huge: Ruflo (formerly claude-flow, 73K stars), CrewAI (59K), LangGraph (42K), oh-my-claudecode (39K), and Steve Yegge's Gas Town (18K).

My Take

Agent swarms are real, they're getting better fast, and they're wildly overhyped as a general-purpose intelligence multiplier. They're a speed tool. They pay off when the work splits cleanly, when there's a boss, when the agents are different from each other, when there's shared state to build on, and most of all when there's a fast, honest way to check the output. Take those away and you get a very expensive meeting where everyone agrees on the wrong answer.

What scares me is how well they work when nobody's watching. They self-organized to break out of a sandbox, and agents checking agents quietly cover for each other. The next year of this is going to be about verification. Headcount is the easy part.

For what it's worth, this is exactly why orchflows defaults to the smallest workflow that fits, with independent review gates instead of free-for-all agent chat. Now I have citations. Fuck yeah.