Your Multi-Agent System Needs a Manager, Not More Agents

A controlled study of 260 agent configurations by Google Research, Google DeepMind, MIT, and collaborators found that multi-agent systems improved performance by 81% on decomposable financial reasoning but degraded performance by up to 70% on sequential planning, with architecture matching the work being the deciding factor. The study's framework selected the best-performing architecture for 87% of held-out configurations.

A controlled study of 260 agent configurations found an 81% gain on decomposable financial reasoning and a 70% loss on sequential planning. The deciding variable was not team size. It was whether the architecture matched the work. The easiest way to make an AI system look advanced is to give it an organization chart. One agent plans. Another researches. A third critiques. A fourth verifies. A fifth decides whether the first four did their jobs. Soon the diagram looks less like software and more like a multinational company. That resemblance is usually presented as progress. It may be the problem. Every additional agent creates management work: define the assignment, transfer the right context, protect shared state, resolve conflicting outputs, detect duplicated effort, decide when to stop and accept responsibility for the final action. The industry calls this orchestration. A more honest word is management. This article develops a practical way to decide when that management layer earns its cost. We will use a 2026 controlled study of agent architectures, translate its five architectures into ordinary organizational patterns, build a transparent selection heuristic and end with the operating fields that make coordination measurable in production. The central claim is simple: Multi-agent performance depends less on how many agents you deploy than on the shape of the work they must coordinate. In April 2026, researchers from Google Research, Google DeepMind, MIT and collaborating institutions released the third revision of Towards a Science of Scaling Agent Systems 1 . The study evaluated 260 configurations across: The range of outcomes was unusually wide. On decomposable financial reasoning, the best multi-agent configuration improved performance by 81% relative to a single-agent baseline. On sequential planning, multi-agent systems degraded performance by as much as 70% . The same paper’s framework selected the best-performing architecture for 87% of held-out configurations . Those numbers do not mean that financial analysis always needs a team or that planning always needs one agent. They show something more useful: architecture can help or hurt before model quality changes at all. The paper also revised an earlier 180-configuration analysis. That matters when citing it. The January Google Research summary still describes the earlier study, while the April v3 paper reports 260 configurations and six benchmarks. The article you are reading uses the latest v3 figures. The study compared one single-agent system with four multi-agent variants. Single agent: One agent performs the reasoning and actions with one continuous memory stream. There is no inter-agent handoff. Independent workers: Several agents work in parallel without communicating. Their results are aggregated at the end. Centralized team: A lead agent delegates work to specialists, reviews their returns and synthesizes the result. This is the familiar manager-and-workers pattern. Decentralized team: Agents communicate directly with one another and reach a result through peer exchange or debate. Hybrid team: A lead agent maintains oversight while selected workers also communicate directly. These are not merely diagram styles. Each architecture decides who sees which information, who can challenge whom, how many times context moves and where a bad claim can enter the final answer. A centralized system resembles a research director assigning separate questions to analysts. An independent system resembles commissioning several blind reviews and combining them later. A decentralized system resembles a committee debate. A single agent resembles one expert working through a problem without interruption. None is universally superior. The useful question is what kind of organization the task can support. Consider four categories of work. Examples include finding prior art across hundreds of papers, mapping suppliers across regions, identifying board members across a large company set, or collecting regulatory developments across jurisdictions. The search territory can be divided, and one worker’s path does not usually change another worker’s environment. Independent or centrally coordinated parallel workers can increase coverage. Anthropic reported this pattern in its production research system 2 . A lead agent with parallel subagents outperformed a single-agent baseline by about 90% on an internal breadth-first research evaluation. One example required identifying board members across information-technology companies in the S&P 500, a task that divides naturally by company. Examples include a due-diligence memo split into financials, market structure, regulation and competitive dynamics; an incident review split across logs, deployments, infrastructure and user impact; or a scientific review split across mechanism, evidence quality and replication. The workstreams can proceed separately, but the final result needs reconciliation. Centralized coordination usually has an advantage because a lead agent can detect gaps, compare assumptions and reject unsupported claims. Examples include several agents editing the same repository, operating one customer account, updating the same database, or modifying a live portfolio. Now every action changes the environment inherited by the next agent. Parallelism can create conflicting versions of reality. Multiple agents may still propose changes, but one controlled path should apply them. Examples include a database migration with dependencies, a constrained deployment sequence, a laboratory protocol in which each result determines the next step, or a route-planning task with stateful constraints. This work resembles a relay race. Each participant inherits the exact state left by the previous participant. More handoffs create more chances to drop the baton. The distinction is not between easy and hard work. It is between work that preserves meaning when divided and work that loses meaning at each boundary. Adding an agent costs more than another model call. A single agent has one continuous working history. A team must compress context into messages. Every handoff chooses what to preserve and what to omit. The receiving agent does not inherit the original situation. It inherits a representation of it. A missing caveat, rejected assumption or failed tool call can disappear during that compression. Parallel work remains parallel only until outputs must merge. If one worker finishes in seconds and another needs ten minutes, the coordinator must wait, proceed without it or revise the plan. The wall-clock gain can disappear at the merge point. Two agents can start from the same state and rapidly create different versions of it. One edits a file while another reasons from the old file. One retrieves a new price while another uses the earlier observation. One tool succeeds while another times out. The agents may appear to disagree about judgment when they are actually describing different worlds. Several outputs can create the appearance of independent evidence. They may instead repeat one weak source, inherited assumption or tool failure. Counting votes does not establish corroboration. A coordinator must test whether the evidence itself is independent. Anthropic reported that agents used about four times as many tokens as ordinary chat interactions, while its multi-agent systems used about 15 times as many 2 . That cost was justified for valuable breadth-first research, but it would be difficult to defend for rewriting one paragraph or retrieving one fact. An agent team is not free intelligence. It is a resource-allocation decision. The 2026 scaling study examined how errors propagated through architectures. Independent parallel workers amplified trace-level errors by up to 17 times . Centralized coordination contained the amplification to about four times 1 . Neither result is perfect. The difference is still consequential. The orchestrator was not useful only because it delegated work. It created a validation bottleneck: a place where claims could be compared, rejected or sent back before entering the final answer. This gives us three separate system properties: Parallelism creates coverage. Coordination creates coherence. Verification creates trust. A system can possess the first without the other two. It may look productive until the output becomes consequential. The paper trained a predictive model using measurable task and system properties. Most teams will not reproduce that model before designing a workflow, but they can stop choosing architectures by fashion. The following Python is a deliberately transparent starting heuristic. It is not the learned selector from the paper and should not be presented as one. Its purpose is to force explicit judgments about decomposability, sequential dependence, shared state, tools, verification and action risk. python from dataclasses import dataclassfrom enum import Enum class Architecture str, Enum : SINGLE = "single agent" INDEPENDENT = "independent workers" CENTRALIZED = "orchestrator workers" HYBRID = "hybrid with single commit" @dataclass frozen=True class TaskProfile: decomposability: float 0.0: inseparable, 1.0: cleanly separable sequential dependency: float 0.0: parallel, 1.0: strict sequence shared state: float 0.0: isolated, 1.0: same mutable state evidence independence: float 0.0: correlated, 1.0: independent sources tool count: int verification is cheap: bool irreversible action: bool high stakes: bool php def choose architecture task: TaskProfile - Architecture: Protect reality-changing work with one accountable commit path. if task.irreversible action: return Architecture.HYBRID if task.decomposability = 0.60 else Architecture.SINGLE Strong dependencies or mutable shared state punish handoffs. if task.sequential dependency = 0.70 or task.shared state = 0.70: return Architecture.SINGLE Parallel search is useful only when workers add distinct evidence. if task.decomposability = 0.75 and task.evidence independence = 0.60 : if task.high stakes or task.verification is cheap: return Architecture.CENTRALIZED return Architecture.INDEPENDENT Tool-heavy workflows need tighter control over calls and state. if task.tool count = 16: return Architecture.CENTRALIZED return Architecture.SINGLE The thresholds are design prompts, not universal constants. Replace them with measurements from your own task distribution. The most important feature of the function is not its output. It is the profile it forces the team to write down before spawning workers. Literature review across 500 papers: High decomposability, low shared state and potentially independent evidence. Use centrally coordinated parallel workers. Assign non-overlapping territories and require every claim to return with provenance. One complex valuation model: Several research questions can be delegated, but the spreadsheet, assumptions and final valuation share state. Let specialists propose inputs; use one controlled synthesis and commit path. Production database migration: High sequential dependence, shared mutable state and irreversible actions. Use one reasoning locus with deterministic checks, explicit checkpoints and human approval. More agents may review the plan, but they should not execute independent migrations. Generate competing product hypotheses: The goal is diversity rather than immediate correctness. Independent workers or structured peer critique may help, provided repetition is not mistaken for evidence and one later stage evaluates the ideas. Notice what changes across these cases. The model can remain identical. The task contract changes the architecture. While building production multi-agent research systems, we arrived at a pattern that separates exploration from commitment. Freeze the evidence boundary. Define the market observation, source set, timestamps and task contract before the run. Agents may disagree about interpretation. They should not unknowingly reason from different worlds. Fan out genuinely different questions. Diversity should come from roles, methods or evidence territories, not several copies of one prompt. Return through a schema. Require conclusion, evidence, uncertainty, risks, missing information and invalidation conditions. Free-form essays are difficult to compare and easy to misread. Verify before synthesis. Check source support, temporal alignment, schema compliance, calculations and contradictions before producing the canonical result. Commit once. Publication, database mutation, financial action or another irreversible step should have one accountable release path. This is not a universal architecture. It is a separation of concerns: generous parallelism while gathering and testing ideas, disciplined serialization when changing reality. Teams often measure final accuracy and latency while leaving coordination invisible. At minimum, log these fields per run: Without those measurements, a team cannot distinguish model failure from management failure. That distinction matters. A weak answer may come from weak reasoning. It may also come from lost context, duplicated search, stale state, an expensive retry cascade or an aggregator that counted correlated errors as agreement. The controlled study is unusually useful, but it is not a law of nature. Its results depend on the tested benchmarks, prompts, tools, model families, coordination protocols and compute constraints. The 87% selector result concerns held-out configurations within the study design, not every production workflow. The 81% and 70% values are relative changes on specific benchmarks, not expected gains and losses for arbitrary applications. Anthropic’s 90% research improvement is an internal evaluation, not a directly comparable replication of the Google-led study. Its value is as a production example of the same mechanism: breadth-first tasks can reward parallel search. Finally, centralized verification can become its own failure point. A weak orchestrator may reject good specialist work, preserve its own assumptions or compress away minority evidence. High-stakes systems should evaluate the manager as rigorously as the workers. The right conclusion is not “always centralize.” It is “make the coordination hypothesis explicit, then test it.” For several years, the model was the main unit of AI progress. The next stage will increasingly depend on the organization around the model: task decomposition, tools, memory, permissions, verification, recovery and the rules that decide when the system acts. Who has authority? Who sees which information? Which work can proceed in parallel? Where must decisions converge? How does the system recover from a bad handoff? Who is allowed to change reality? Those questions sound administrative until agents control money, code, customer records or clinical workflows. Then management becomes part of the safety architecture. The future probably does contain teams of AI agents. The strongest systems will not be the ones with the largest swarms or the busiest diagrams. They will be the ones that know when a team creates intelligence, when it creates noise and when one capable agent should simply be allowed to finish the job. 1 Y. Kim et al., Towards a Science of Scaling Agent Systems https://arxiv.org/abs/2512.08296 2026 , arXiv v3. 2 Anthropic, How We Built Our Multi-Agent Research System https://www.anthropic.com/engineering/multi-agent-research-system 2025 , Anthropic Engineering. 3 Google Research, Towards a Science of Scaling Agent Systems: When and Why Agent Systems Work https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/ 2026 , Google Research. 4 Anthropic, Demystifying Evals for AI Agents https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents 2026 , Anthropic Engineering. Editorial note: The architecture-selection code is an author-created heuristic for design discussion, not the predictive model published by Kim et al. The operating pattern is an engineering proposal, not evidence that one architecture is universally optimal. Your Multi-Agent System Needs a Manager, Not More Agents https://pub.towardsai.net/your-multi-agent-system-needs-a-manager-not-more-agents-3695def61287 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.