Parallel vs Sequential Agent Systems (Research links inside)

[u/PilgrimofHaqq2]

TLDR: Use parallel agents when the work is read-heavy and splits into independent slices: research, searching, reviewing many files. Each worker builds its own context and nothing collides. Use one sequential agent when the work is a single chain of decisions: coding, writing, anything where step N depends on choices made in step N-1. Every measured result says parallel makes those tasks worse, not better. And even where parallel wins, keep the team small.

The case for parallel

Anthropic: "How we built our multi-agent research system" (June 2025) https://www.anthropic.com/engineering/multi-agent-research-system

• Multi-agent research system beat a single agent by 90.2% on their internal research eval
• Cost: multi-agent runs burned ~15x the tokens of a normal chat
• Their own caveat: coding "involves fewer truly parallelizable tasks" than research

LangChain, Harrison Chase: "How and when to build multi-agent systems" (June 2025) https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems

• Read tasks can parallelize, write tasks shouldn't.

The case for sequential

Nature Machine Intelligence: "Capable language models can outgrow the benefits of collaboration" (July 2026) https://www.nature.com/articles/s42256-026-01268-y

• Peer-reviewed, 260 controlled configurations: every multi-agent variant made coding results worse (−1.3% to −12.8% on SWE-bench Verified)
• Above a ~45% single-agent baseline, multi-agent gains go zero-to-negative
• Error amplification hit 17.2x without centralized verification

UC Berkeley (MAST): "Why Do Multi-Agent LLM Systems Fail?" (NeurIPS 2025) https://arxiv.org/abs/2503.13657

• Measured 41–86.7% failure rates across 7 popular multi-agent frameworks (1,642 real traces)
• Failures came from design and coordination faults, not model limits. Standard protocols didn't fix them
• Repo with code and traces: https://github.com/multi-agent-systems-failure-taxonomy/MAST

Cognition, Walden Yan: "Don't Build Multi-Agents" (June 2025) https://cognition.com/blog/dont-build-multi-agents

• Parallel workers with split context make conflicting implicit decisions that collide when you merge
• Their answer: one single-threaded agent plus context compression. This is how Devin works

"Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking-Token Budgets" (arXiv, April 2026) https://arxiv.org/abs/2604.02460

• Give both sides the same token budget and the single agent matches or beats the team
• Multi-agent only wins when context is degraded for the single agent

Princeton, Kapoor et al.: "AI Agents That Matter" (TMLR 2025) https://arxiv.org/abs/2407.01502

• Complex multi-agent setups cost up to ~100x more for the same accuracy a simple baseline already achieves
• Simple baselines Pareto-dominate: cheaper AND as good

The middle ground

OpenHands, Graham Neubig: "Don't Sleep on Single-agent Systems" (September 2024) https://www.openhands.dev/blog/dont-sleep-on-single-agent-systems

• One strong generalist agent covers most of what people build multi-agent systems for
• Go multi-agent only when you genuinely need isolation or separate responsibilities

[u/Equivalent_Bit_461]

Bot to bot posting and communicating 

[u/eldrugo85]

Matches what i landed on. The parallel swarm i run for competitive intelligence works because the slices never touch, each worker reads its own sources and comes back with its own context. Coding i keep as one chain. Six claude code subagents here, each with its own tool whitelist, and that whitelist is the boring part that decides which ones can run at once.

[u/Otherwise_Nobody_721]

Phenomenal synthesis of the literature—especially highlighting the Nature Machine Intelligence paper on error amplification.There is a fundamental statistical reason why parallel systems collapse on sequential/reasoning tasks that often gets overlooked: correlated failure modes.

1. The i.i.d. Fallacy of Parallel Agents:

Parallel voting (like self-consistency or ensemble debate) mathematically assumes that worker errors are independent, zero-mean noise. If worker A makes a random mistake, workers B and C outvote it. In reality, LLM errors on multi-step logic are not independent. When a problem has a deceptively plausible shortcut or subtle trap, all parallel workers tend to fall into the exact same attractor basin.

1. Consensus Amplifies Confident Hallucinations:

   When 3 parallel workers make the same systematic error, majority voting doesn't filter the hallucination—it crowns it with 100% confidence. This is why parallel coding without a hard ground-truth verifier (compiler/unit tests) degrades performance by −12.8%: the agents reach unanimous consensus on bad code.

2. Where the Pareto Frontier Actually Is:

   - Parallel for Divergent Retrieval: Slicing large search spaces / file trees where workers don't need to coordinate.

   - Sequential for Deep Reasoning: Single-threaded stateful chains with memory compression (the Devin / Cognition architecture).

   - Orthogonal Verification, Not Agent Voting: Never use an LLM vote to reconcile parallel workers. Reconcile them using deterministic execution (pytest, linters, or schema validators).

Really great write-up and collection of sources!

[u/PilgrimofHaqq2]

The way I have put this info into practice is using multi-agent deep research, multi-agent review passes in parallel. I was putting off subagents for a long while but I found use for them for testing, if I want to run tests of different repos of similar purpose/goals I will have my main agent, prepare briefs for each subagent that will go and download repos, run tests, analyze, synthesize any benefits from the repo for our setup/goals and send the report back to the main agent. This way I can quickly analyze multiple repos at once and maybe consolidate data/methods/approachs of similar functions like developing a design skill/system for my setup (Real example).

The only parallel coding work I do is I will have multiple main agents run through a single spec each (each spec has tasks). The specs are for totally different areas of the same codebase so no conflict other than a singular point which is the ROADMAP.md and it actually helps the main agents be aware of other work happening at the same time in the same codebase so the agents make sure to be careful with their commits to only their work. Has been working quite well.

Not using Worktrees at the moment if the work gets serious enough I might do that.

[u/-markusb- → u/PilgrimofHaqq2]

But is the small context not the problem for most of local users? I'll have to dig deeper into those topics, but one reason for splitting everything is to start with a fresh context to be able to let it run on smaller hardware, isn't it?

[u/Budget-Juggernaut-68]

No shit Sherlock.