Google's Multi-Agent Research: Task Structure, Not Agent Count, Determines Architecture Value

Google Research: Task Determines Architecture

Google Research's Towards a Science of Scaling Agent Systems studied five architectures: Single-Agent, Independent, Centralized, Decentralized, and Hybrid. The difference lies in information flow and control relationships. Single-Agent handles the full task alone; Independent runs multiple agents in parallel then aggregates; Centralized uses an orchestrator to dispatch and synthesize; Decentralized lets agents communicate directly; Hybrid combines centralized scheduling with peer-to-peer collaboration.

The evaluation focused on tasks requiring multi-step environment interaction, repeated information gathering under uncertainty, and strategy adjustment from feedback—excluding static Q&A or one-shot generation. Early experiments (Jan 2026 blog) used 180 configurations across 4 benchmarks; the Nature Machine Intelligence paper (Jul 2026) expanded to 260 configurations and 6 benchmarks. Both stages are consistent, not contradictory.

Results contradict "more agents = stronger" intuition. On Finance-Agent (parallel exploration), multi-agent brought clear gains: Centralized improved 81% . On PlanCraft (strict sequential planning), all multi-agent variants dropped 39% to 70% . Multiple agents sharing intermediate state break continuous reasoning with communication and context-splitting overhead.

Tool count increases coordination cost—a "tool coordination tradeoff": more tools mean more state to sync, and parallel gains are offset by scheduling and handoff costs. Error propagation also differs: trace-level analysis shows Independent error amplification at 17.2× , Centralized at ~4.4× . The orchestrator becomes a coordination bottleneck but also a unified checkpoint that intercepts some errors before they spread.

A predictor model trained on tool count, task decomposability, and other attributes achieved 87% accuracy selecting the optimal architecture on unseen task configurations. The paper also identifies a ~45% capability saturation threshold : above this baseline, adding collaboration tends to yield negative returns. This threshold is an experimental selection rule, not a universal switch.

These results don't directly become a production auto-selector, but they point to architecture selection via measurable task properties rather than intuition-driven role addition.

Teamwork: Collaboration Needs Verification

Google Antigravity's Teamwork addresses a common failure: multiple agents working, results looking complete, but all sharing the same flawed premise and deepening the same error path. Teamwork structures collaboration as a loop: generate multiple candidates, assign agents to stress-test and find counterexamples, synthesize evidence-backed parts, then iterate.

Goal: each collaboration round must change candidate quality, not just exchange more messages. A key design: rejected branches are not discarded; critiques and failure reasons attach to the branch, becoming input for later synthesis and search. For open-ended research and complex engineering, failed paths often contain boundary conditions—retaining them is more useful than keeping only the final answer.

Teamwork separates collaboration mode (how candidates are generated, criticized, synthesized) from agent roles (who does what in the current task). This lets the same adversarial-check pattern transfer to math proofs, code optimization, and document review without writing a fixed pipeline per domain.

Team size and iteration count adjust at runtime: counterexamples shift resources to other branches; high candidate redundancy contracts search; insufficient evidence continues iteration. This differs from fixed agent groups that wait for all results then summarize.

Teamwork's core: collaboration must produce new evidence, counterexamples, or executable results—not just another summary layer.

Is the Task Worth Splitting?

Task complexity is only a starting point. Many steps ≠ suitable for different agents. Financial due diligence suits splitting: regulatory info, operations, industry trends explore independent sources with independent goals and verifiable results—yielding parallel exploration and cross-verification. Strict sequential operation chains differ: step N needs step N-1's output; mid-stream state changes invalidate other agents' contexts. Splitting adds waiting, sync, and retries.

Three conditions for splitting:

Subtasks have relatively independent inputs and goals;

Sub-results can be independently verified against explicit criteria;

Parallel time savings cover communication, retry, context-copy, and human verification costs.

The second condition is often underestimated. If sub-results can only be merged by another agent's gut feel, the system just splits one hard problem into several interdependent black boxes. Tool count alone isn't a splitting criterion—more tools may mean larger exploration space, or that every agent must master a full call chain.

Contain Errors at Boundaries

Topology differences ultimately manifest in error propagation. Independent reduces coordination but rarely cross-checks; Centralized eases unified state but concentrates judgment pressure on the orchestrator; Decentralized allows direct challenge and exchange, but replay and diagnosis get harder with more messages; Hybrid is flexible but role boundaries blur.

The real design question: when an error appears, which layer sees it, and which layer stops it from propagating downstream?

This mirrors runtime boundaries seen in Pi Agent, DeepSeek Harness, Claude Code. Pi separates steering, followUp, nextRun for input redirection, post-task additions, and next-run input. DeepSeek Harness separates tool calls, session events, and recovery state—distinguishing "what happened" from "can we retry." Claude Code's memory reminds us: shared context ≠ re-verified facts.

Multi-agent systems need explicit boundaries: what is exchanged—raw evidence, tool outputs, conclusions, or sourced intermediates? On subtask timeout: retry, degrade, or mark unknown? After external side effects: can the system recover to an acceptable state? Without clear answers, complex architecture diagrams produce unexplainable results.

Reviewer Must Change the Flow

A Reviewer at the pipeline end doesn't mean quality control is done. A working Reviewer needs three concrete properties:

Independent input: not just the previous agent's conclusion, but raw evidence, tool results, or executable tests.

Specific veto criteria: can state exactly which condition fails—insufficient evidence, contradiction, constraint violation.

Veto changes flow: return to last stable node, switch branch, narrow task, or request human confirmation. Critique without consequence is just more text.

Shared whiteboards reduce duplicate work but don't auto-convert judgment into fact. Unverified conclusions on a whiteboard just propagate faster.

Five Engineering Controls

Role names (Planner, Executor, Reviewer) don't constitute architecture. Control relationships between roles determine system quality:

What is exchanged: conclusions, evidence, tool outputs, confidence scores, next-step suggestions? Unclear formats force downstream guessing.

Who challenges: who is responsible for critique, what evidence they examine, what issues trigger rollback. Reviewer is a control path with authority, not a noun.

When to stop: what state ends the run, what continues exploration, what marks "temporarily undecided." Without stop conditions, collaboration burns budget on repeated confirmation.

Failure handling: are failed branches retained? Which states are retryable? Which are marked unknown? How are external side effects rolled back? These decide recoverability.

Budget ownership: agent count, model tier, tool calls, context length, latency, human intervention all need ceilings. Post-budget degradation logic must live in the runtime.

Conclusion

Google's two works jointly show: agent count is not an architecture metric. Tasks already solved stably by a single agent gain little from added collaboration. Tasks needing parallel exploration, independent verification, and multi-round synthesis justify collaboration only when it covers communication and coordination costs.

If agents are added, each must bring new evidence, new counterexamples, new execution capability, or explicit veto responsibility. Otherwise the system adds only more messages and a longer error propagation path.

References

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/)

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

arXiv: Towards a Science of Scaling Agent Systems (https://arxiv.org/abs/2512.08296)

Google Antigravity: Teamwork: When AI Becomes a Research Partner (https://www.antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner)

Google Antigravity Docs: Teamwork agent teams (https://antigravity.google/docs/teamwork/)

Yubin Kim: public research share (https://www.linkedin.com/posts/yubinkim95_agents-multiagentsystem-agentscaling-activity-7404401911262572544-qIL5)

Anthropic: Multi-agent research system (https://www.anthropic.com/engineering/multi-agent-research-system)

Google Cloud: What is agentic AI? (https://cloud.google.com/discover/what-is-agentic-ai)