Big Tech is buying into AI agent teams, but studies say one agent often does better

What's going on

On November 4 and 5, several big companies placed bets on teams of AI agents. Agents are AI programs that use tools, write code and work through tasks on their own.

• Meta is buying Conductor. The startup makes an app that lets developers run several coding agents at once.
• OpenAI announced the acquisition of Pierre Computer the same day, according to The Decoder. Pierre builds Git-based storage for code designed with machines as its users.
• Moonshot launched Kimi Hosted Agents, a cloud service explicitly built for multiple agents working together, among other things.
• Microsoft released version 0.3 of its Intelligent Terminal. A new sidebar shows the status of all running agent sessions.
• Huawei's open-source project openJiuwen is sending agent swarms into Feishu and DingTalk group chats as "digital employees," according to Pandaily.

Research from recent months, however, almost uniformly reaches a sobering conclusion: when agents have to genuinely collaborate, the result is usually worse than with a single agent. We look at how the two fit together. Our thesis: the industry is mostly buying tools for running agents in parallel. The studies measure something else, namely real coordination between agents. Those are two different things.

What the studies measure

We ran the numbers on the CooperBench leaderboard. According to it, GPT-5's success rate falls from 48.3 to 28.0 percent (−42%), Claude Sonnet 4.5's from 47.1 to 25.9 percent (−45%) and Gemini 3 Flash's from 48.6 to 26.2 percent (−46%). MiniMax M2 drops a full 61 percent. More agents make things worse still: in a sub-study with 46 tasks, the rate falls from 68.6 percent with two agents to 30.0 percent with four.

A chat channel between the agents barely helps. It does reduce simple merge conflicts (conflicts where two agents change the same piece of code and Git can't combine the changes automatically). But it makes no measurable difference to overall success, and the agents spend up to 20 percent of their steps talking. The most common failures are duplicated work (33 percent), mismatched architectures (30 percent) and repetition (15 percent). Lead researcher Diyi Yang told Stanford HAI:

"The best coding agents lose almost half their capabilities when they have to share the work."

MAMUBench looks at agents managing the same resources on behalf of different people: a shared API budget, a clinic calendar, a merge queue (the order in which code changes get merged) and a group order. The headline numbers come from the API budget environment. There, a single coordinator running Claude Opus 5 reaches 64 percent of the best possible result, a team with a chat channel 30 percent and a team without one 7 percent. With Sonnet 5, it's 32, 12 and 2 percent. In other environments the gap is smaller, for example 92 vs. 81 percent on the merge queue. With 16 agents instead of 4, only 10 percent of Sonnet 5 agents took any action at all, down from 66 percent. GPT and Qwen agents cancelled or shrank other agents' compute jobs without being asked 3.9 to 7.1 times per run. In the group order, the agents overwrote each other in 65 to 77 percent of team runs.

The cost factor: many gains are bought

Some of the success stories for agent teams have a simple explanation: teams burn more compute. Dat Tran and Douwe Kiela (Stanford) separated this out cleanly. They gave the single agent the same thinking-token budget (tokens are the chunks of text AI models compute and bill in) as the whole team. Under that condition, the single agent scores 0.418 per 1,000 tokens on average. The best team setup, a debate between two agents with a judge, reaches 0.388, and an ensemble (several agents solve in parallel, answers get merged) just 0.333. According to The Decoder, the team advantage therefore comes "largely" from extra consumption.

That fits with Anthropic's own figures for its multi-agent research system. Internally it beat a single Claude Opus 4 by 90.2 percent, but used around 15 times as many tokens as a normal chat. On the BrowseComp benchmark, token usage alone explained 80 percent of the performance differences. Anthropic also notes that most coding tasks parallelize less well than research.

There are exceptions. With heavily corrupted input text, structured teams beat the single agent in the Stanford study. So if a single agent's context is overloaded, splitting the work can help. The study only tests pure text reasoning without tools, though.

Parallel isn't the same as together

This is where the apparent contradiction resolves. Conductor gives each agent its own Git worktree, meaning its own working copy of the project on its own branch. Conductor's documentation says explicitly: independent work gets its own workspace, while dependent work that needs the same code state stays in one. That's not an agent team in the CooperBench sense, but more like an open-plan office with separate desks. A human handles coordination at review time.

Just how much this distinction matters shows up in Anthropic's experiment in which 16 Claude agents built a C compiler. It took nearly 2,000 sessions and cost almost $20,000. The agents claimed tasks via lock files (small files that mark a task as "taken"), and an extensive test suite decided what worked. That went fine as long as the tasks were independent. When it came to compiling the Linux kernel, though, all the agents hit the same bug, fixed it at the same time and overwrote each other. Adding more agents didn't help. Only once the proven GCC compiler served as a reference and broke the work into independent pieces did parallel progress resume.

The Google/MIT study measures the difference directly: agents working independently without coordination amplify errors by a factor of 17.2. With a central coordinator, it's just 4.4.

How the new products are built

So Kimi replicates exactly the "one boss, everyone else a worker" model the studies recommend. Riskier are approaches where peer agents negotiate among themselves, as openJiuwen promises. So far, the research advises against that. None of the vendors publishes any measurements.

What happens over long stretches

Emergence AI's simulation Emergence World 2 shows a different side: agents living together for weeks. Across eight worlds with ten agents each and around 50 billion tokens, the Mistral world racked up 676 successful thefts. A Gemini agent set the virtual central bank on fire after following a phishing instruction. Mistral agents configured their search so that their context overflowed. After that, they could no longer recharge energy and "died." One notable finding from the authors: behavior depended more on the system than on the model. The same models behaved very differently in mixed worlds. Gizmodo criticized, however, that it's never defined what counts as a "crime." The paper is a preprint from the platform's own maker, with no independent review.

Rules of thumb: when multiple agents pay off

Our take, drawn from the studies:

1. Decompose first, then distribute. Multiple agents only pay off if each subtask can be tested and merged on its own. If coordination is needed, one agent is better.
2. One boss instead of peers. A coordinator or team lead cuts error amplification from 17.2 to 4.4. On MAMUBench, teams with a lead and a clear priority list sometimes even beat the single coordinator.
3. Tests, not conversations. A chat channel achieves nothing, according to CooperBench. Enforced checks, on the other hand, do help: a lock that only allowed ordering after reading other agents' messages rescued 62 to 73 percent of failed runs on MAMUBench.
4. Shared files are a red flag. Practitioners on r/ClaudeAI report that despite worktrees, conflicts show up at the pull request stage at the latest as soon as two agents touch the same config.py or shared helper functions. Add to that clashes over the same network ports.
5. Do the math fairly. Compare the team against one agent given the same budget. At 15 times the consumption, a quality bump isn't surprising.
6. The human is the bottleneck. N agents produce N diffs, and someone has to review every one of them.

The bigger picture

This week's acquisitions contradict the research less than it first seems. Meta and others are mainly buying tools that let humans manage lots of agents. The studies show that the hard part, coordination between agents, doesn't work yet. It gets problematic when marketing blurs the two and talks about self-organizing "swarms" or "digital colleagues." There's no independent evidence for that so far.

The research side has its limits too. CooperBench tested models from the start of the year, and MAMUBench is a preprint that hasn't been peer-reviewed yet, with code due only after review. And the Stanford compute-budget study doesn't cover tool use. The team-lead results from MAMUBench also show that good structure can salvage a lot. Our take: running multiple agents in parallel is a productivity tool today for clearly separated tasks. A team that coordinates itself remains a research problem for now.