Your multi-agent default is the bug.

Two papers landed on arXiv this week and they say the same thing: the architecture decision most AI product teams are making by default is wrong.

Ask any PM building an agent product why they went multi-agent and the answer is usually some version of "it's what everyone does." Divide the work across specialists. Have one agent plan, another execute, another review. It mirrors how human teams operate — so it must be better.

It isn't. Automatically generated Multi-Agent Systems (MAS) — the kind scaffolded by frameworks like AutoGen or CrewAI — consistently underperform a single agent using Chain-of-Thought with Self-Consistency (CoT-SC) across both traditional reasoning tasks and interactive multi-step workflows including BrowseComp-Plus, according to a June 13 arXiv paper by Jwalapuram, Joty, Carenini et al. 1

The cost penalty is stark: automatic MAS are up to 10x more expensive than single-agent baselines while delivering worse results. The paper's diagnosis is blunt — "architectural bloat that prioritizes superficial complexity which does not translate into functional utility." 1

A second paper published June 15 narrows in on one specific failure mode inside MAS: anchor collapse. When you run parallel agent rollouts to scale test-time compute, each thread starts with a query to the same retrieval system. Because the rollouts share the same model, they issue nearly identical first-turn queries — and retrieve nearly identical evidence. Every subsequent turn in every thread is then conditioned on overlapping context. You haven't added diversity; you've added copies.

The result: scaling from 4 to 8 to 16 parallel rollouts delivers essentially no accuracy improvement without intervention. 2 The paper, under review at EMNLP 2026, calls out that "when models issue similar first queries across rollouts, the threads retrieve overlapping evidence, and subsequent turns are conditioned on this shared retrieval."

The proposed fix — DivInit (Diverse Query Initialization) — draws multiple candidate queries from a single model call, picks the most semantically distinct subset, and uses those as seeds for parallel rollouts. Tested across 5 open-weight models and 8 benchmarks, it delivers 5–7 point gains on multi-hop QA at matched compute, and sustains near-linear scaling benefits up to 32 parallel rollouts instead of plateauing at 4–8. Code is at github.com/cxcscmu/diverse-query-initialization. 2

Accuracy gains (approximate, based on reported 5–7 point improvement at matched compute and near-linear scaling to 32 rollouts vs. plateau at 4–8). 2

What makes this week's signal particularly strong: the academic result isn't isolated. Two production practitioners landed on the same conclusion independently.

Bogdan Sergiienko, CTO of MasterofCode, published an engineering guide on June 14 covering production-grade agentic systems. His takeaway: "A well-tooled monolithic agent often outperforms a poorly designed multi-agent topology. The right granularity is an engineering judgment, not a default." He specifically flags that "many small agents add latency, coordination overhead, and handoff failures" — the same surface the academic paper calls architectural bloat. 3

Then, at Data + AI Summit 2026 on June 16, Databricks described what they learned after processing over 1 quadrillion tokens/year across 100,000+ agents built on their platform: "The core agent loop is just 1% of the work. The other 99% is the hidden technical debt of agentic systems." 4 That debt — token capacity management, security, evaluation, monitoring, context handling — doesn't get cheaper when you add more agents. It compounds.

The paper isn't arguing that multi-agent architecture is never the right call. It draws a sharp distinction that matters for PMs: automatically generated MAS consistently underperforms; expert-architected MAS consistently outperforms both automatic MAS and single-agent baselines in raw performance and cost-efficiency.

The problem isn't multi-agent as a concept. It's reaching for a framework that auto-generates the topology — CrewAI, early-AutoGen-style orchestration — and assuming the scaffolding handles the architectural decisions. It doesn't. Assigned agent roles are frequently redundant. The paper introduces a diagnostic benchmark specifically designed to test whether a task actually has the decomposition properties MAS needs: explicit decomposition boundaries, context that can be cleanly separated, and work that can genuinely run in parallel. Most enterprise tasks don't satisfy all three.

Three decision points for PMs building on agent stacks:

1. Start single-agent with strong tooling. Before spinning up multi-agent orchestration, test whether a single agent with CoT-SC and well-structured tool access can match the performance target at the cost you need. Databricks' own RL-trained data agent is "competitive with frontier models such as Opus and Sonnet in Genie-related tasks, while being significantly lower cost per query." 4 A well-tuned single-agent loop is the correct default, not the fallback.

2. If you're running parallel rollouts for agentic search, audit your first query. Products like internal enterprise search, document QA, or research assistants that use parallel sampling to improve answer quality may be hitting the anchor collapse ceiling already. The fix (DivInit-style query diversification) is training-free: it's a sampling strategy, not a model change. Teams at companies like Glean, Perplexity, or Hebbia building enterprise search agents should evaluate whether their parallel rollouts are actually exploring diverse retrieval paths or just amplifying the same first query. 2

3. If multi-agent is required, design the topology explicitly. Use a deterministic state graph where control flow is code-defined, not model-decided. Compress agent context into structured JSON handoff objects rather than passing raw conversation history between agents. The paper's diagnostic dataset offers a useful pre-mortem test: can you clearly identify the decomposition boundary, confirm that context separates cleanly at that boundary, and verify that the parallel work doesn't depend on shared retrieval? If any of the three is unclear, you're not ready for multi-agent — and you'll pay 10x to learn that lesson in production.

The industry has been comparing multi-agent against weak single-agent baselines. When you compare against a properly prompted single agent, the case for defaulting to multi-agent collapses. This week's papers give you the numbers to push back on that default.