Stop Running 100 Solo AI Agents — 10 Teams of 10 Beat Them by 27%

You have a hard task and a budget of 100 AI agents. What do you do? The obvious answer is to run 100 agents in parallel, keep the best result, and go home. The ambitious answer is to put all 100 in one giant team and let them collaborate. A new paper from Duke University, Modal Labs, Princeton University, and New York University says both answers are wrong — and the fix costs nothing extra.

The paper is "Test-Time Compute Scales Better with Parallel Agent Teams" by Junlin Wang, Haozhe Chen, Ang Li, Rahul Chalamala, and Zhuang Liu (arXiv:2611.09798, 6 November 2026). Their method is almost embarrassingly simple: split your 100 agents into ten teams of ten, let each team work on the problem independently, and keep the best team's result. Averaged across 12 long-horizon tasks, the best team-of-ten scored 27% higher than the best of 100 solo agents. On one maths task, the gap was nearly threefold. Same model, same budget, same tasks — just a different way of organising the agents.

What the researchers did

First, the setup. The researchers were studying test-time scaling: improving a fixed model's performance by spending more computation at inference time, rather than training a bigger model. When you can score every attempt with a verifier — a test suite, a proof checker, a benchmark — there are two standard ways to spend that compute on agents. Best-of-N sampling runs many independent agents and keeps the best result, but it saturates quickly: after a point, more solo agents barely help. One large team of collaborating agents can score higher, but it stops improving as it grows: a single team is still just one sample, and one sample gets no benefit from variance.

Their proposal, parallel agent teams, takes the best of both. Many small teams run in parallel, and you keep the best team's result. Each team in their experiments had ten agents. The setup inside a team is deliberately simple: every agent has its own sandbox and its own context, but the team shares a forum where any agent can post and read notes at any time. There are no roles, no manager, and no assigned work — the agents organise themselves around the shared forum. The agents ran in the Codex harness inside Modal sandboxes, and the main model was Qwen3.8-27B, a 27-billion-parameter open model.

They tested the idea on 12 long-horizon tasks — from writing GPU kernels and formalising mathematical proofs to exploit development — all tasks where a verifier can score the result. The headline numbers, all with a budget of 100 agents:

• Parallel teams of ten beat 100 solo agents on 10 of the 12 tasks.
• They beat one team of 100 on all four tasks where such large teams were run, by a margin of 8% to 30%.
• On the Carleson Formalization task, the best of 100 solo agents scored 19.0 out of 100. The best team of ten scored 54.8 — nearly three times as much.
• At equal dollar cost, the same parallel teams beat a frontier model on half the tasks.

The only exceptions are instructive. Solo agents came out ahead on just two tasks — Kimi-Linear Decode, and Active Learning by a small margin — which tells you the team advantage is large but not universal. And the paper backs the result with a simple statistical model: individual agents lose because their many samples have a low average quality, while one large team loses because a single sample gets no gain from variance. Many small teams balance a high average with the gain from variance — the best team is usually much better than the average team, and the average team is already better than the average solo agent.

Why it matters

First, it changes the cheapest lever you have. Most teams trying to get more out of AI agents reach for a bigger model or more samples. This paper says the organisation of the agents matters as much as the model or the budget — and reorganising costs nothing. Ten teams of ten beat a hundred solo agents using the same 27B model and the same total compute. For anyone running agents at scale, that is a free 27%.

Second, it explains two failures you have probably seen. If you have ever run best-of-N and watched the tenth sample add almost nothing over the ninth, you hit the saturation the paper describes: solo samples cluster around a low average. If you have ever thrown a huge team at a problem and watched it stall — agents talking past each other, context ballooning, one confused thread poisoning the rest — you hit the other failure: a single team is a single sample, and it cannot benefit from the luck of the draw. Small parallel teams dodge both traps at once.

Third, the "equal dollar cost" result is the one to watch. The same parallel teams beat a frontier model on half the tasks while spending the same money. That suggests that for verifiable work — code with tests, proofs with checkers, anything with a score — a well-organised swarm of a smaller open model can genuinely compete with a much larger model. The moat is not the model. It is the harness.

Fourth, the design is radically simple. No roles, no manager, no assigned work. The winning structure is just a shared forum plus separate sandboxes. That simplicity is the point: the coordination overhead that kills giant teams never appears, because each team is small enough to stay coherent, and the competition between teams supplies the diversity that a single team lacks.

How YOU can use it

You do not need the paper's exact harness to use the idea. The recipe is three ingredients: small teams, a shared forum, and a verifier to pick the winner. Here is how to apply it this week — the workflow below is illustrative, inspired by the paper's setup, not paper code.

Step 1: Pick a task with a score. This only works where you can judge the result. A coding task with a test suite, a data pipeline with a validation check, a document with a checklist of requirements. If you cannot score attempts, you cannot pick the best team — and the whole trick collapses. Open-ended creative work is the wrong place for it.

Step 2: Split your budget into teams of about ten. If you run 20 agents, make two teams of ten. If you run 50, make five teams. The paper's sweet spot was ten per team at a budget of 100, and the logic holds at smaller scales: each team is big enough to collaborate and small enough to stay coherent. One team of 50 is not five teams of ten — it is one sample.

Step 3: Give every team the same brief and a shared notes board. Copy this template into each team's starting prompt — it mirrors the paper's forum setup:

"You are one of several teams solving the same task independently. RULES FOR YOUR TEAM: Each of you works in your own sandbox. Do not wait for permission. Share EVERYTHING useful in the shared forum: findings, dead ends, partial solutions, error messages. Read it before starting new work. No roles, no manager. If you see a better approach in the forum, switch to it. If your approach is failing, say so in the forum and try another. Your goal is the best VERIFIED result: the solution must pass [your tests / checks] before you submit it. Post your final solution to the forum with its score."

Step 4: Run the teams in parallel and keep the best verified result. This is the step most people skip — and it is the whole method. Do not average the teams' answers, do not merge them, and do not pick the one that sounds most confident. Run your verifier on each team's final submission and keep the highest score. The paper's 27% gain comes from selection, not from any single team being smarter.

Step 5: Steal the winner's notes. After you pick the best team, read its forum. The winning team's dead ends and discoveries are the most valuable output of the run — they tell you what the next run should try first. Feed the best solution back as the starting point for the next round, and you have turned a one-shot trick into an improving loop.

A quick reality check before you rebuild your whole pipeline around this: the paper only tested tasks where a verifier can score every attempt, and it is a preprint with no peer review or independent replication yet. The 27% figure is an average across its 12 tasks, and on two of them solo agents still won. Treat teams-of-ten as the default shape for verifiable agent work — and measure it on your own tasks before assuming the same margin.

Key takeaways

• With a fixed budget of 100 agents, ten teams of ten beat 100 solo agents by 27% on average across 12 long-horizon tasks — and beat one team of 100 on every task where that was tested.
• Best-of-N saturates because solo samples cluster around a low average; one giant team stalls because a single sample gets no benefit from variance. Small parallel teams balance a high average with the gain from variance.
• Inside a team, the setup is minimal: each agent has its own sandbox and context, and the team shares a forum where anyone can post and read notes. No roles, no manager, no assigned work.
• At equal dollar cost, the parallel teams beat a frontier model on half the tasks — for verifiable work, organisation can matter as much as model size.
• Your move today: only use it where you can score the result, split agents into teams of about ten, give each team a shared forum, and keep the best verified submission — never the most confident one.

Read the original paper: "Test-Time Compute Scales Better with Parallel Agent Teams" by Junlin Wang, Haozhe Chen, Ang Li, Rahul Chalamala, and Zhuang Liu (Duke University, Modal Labs, Princeton University, and New York University). Link: https://arxiv.org/abs/2611.09798 — code: https://github.com/modal-projects/parallel-agent-teams-scaling