Five agents is not a strategy. It's a bill you pay every request.

The whiteboard diagram is always the same. Five boxes, arrows between them, one labeled Orchestrator. It looks sophisticated. Then someone runs the numbers and the whole thing sags. If you are about to sign off on a multi-agent product, stop for a second. Let me catch you up on what the tests and the field reports actually say.

The task decides, not the diagram

Google Research ran a controlled test of 180 agent setups across five architectures. The result is blunt. On sequential reasoning tasks, every multi-agent variant they tested degraded performance by 39 to 70 percent. Same graph-style setups on parallelizable tasks boosted results by up to 81 percent.

Read that twice. The architecture is not good or bad on its own. It matches the shape of the work or it fights it. If your steps have to happen in order, a graph of agents makes things worse. If your steps can truly run at the same time, a graph helps.

So the first question in your next review is not "how many agents." It is "is this work sequential or parallel." That one answer tells you which way to build.

The word people are using is distributed monolith

Sandeep Chaudhary put the plain version on paper. Five single agents is not microservices, it is a distributed monolith. You get the operational pain of a distributed system and the tight coupling of a monolith, with non-deterministic failures on top.

The cost is real, not theoretical. On a retail customer service project, his team ran four agents for routing, retrieval, response, and validation. Six weeks in they scrapped it and rebuilt it as one agent with four tools. Response times dropped from 4.2 seconds to 1.1. Token use fell 62 percent. Same job, cleaner audit trail.

Here is the rule worth stealing: if the steps always run in a fixed order, they are tools, not agents. A tool is a function the agent calls. An agent is a separate reasoning engine with its own context. Splitting sequential steps into agents buys you latency and a bigger bill and nothing else.

When splitting actually earns its keep

Multi-agent is not junk. It is a specialized tool for four cases. True parallelism, where an inventory check and a price check and an eligibility check must fire at once to hit an SLA. Context limits, where one model cannot hold 500 supplier records without its reasoning falling apart. Hard security boundaries, where one agent touches PII and another talks to untrusted users. And independent deploy cycles, where finance owns pricing and ships weekly while logistics owns inventory and ships quarterly.

Snowflake's ArcticSwarm shows the payoff when the problem fits. It coordinates up to 16 agents through a Gated Bulletin Board with three modes: isolate, collaborate, then synthesize. Agents explore alone first so they don't all chase the same lead. The value comes from a structural rule, not a prompt. An agent in isolation mode physically cannot read the board.

The test for you is one sentence. Write down the business domain each agent owns, on its own, no "and." If you can't, it's not a separate agent.

The plumbing is finally catching up

While teams argue architecture, the connective layer got simpler. The Model Context Protocol, the standard way models reach your tools and data, dropped its biggest revision since launch. Sessions are gone and stateless HTTP is in. Any request can now land on any server instance behind a plain load balancer.

Why this matters to you: the old session model was, in Arcade's words to TechCrunch, a serious pain at scale, and part of why so few companies shipped first-party integrations despite the hype. Cheaper to run, easier to maintain. If your team held off on an MCP integration because scaling was ugly, that reason just weakened.

The deep cut

Building inside SAP Joule Studio, Kunal found the language model was the easy part. The work was API contracts, auth, data formats, and explicit guardrails. His single sharpest lesson: the less freedom you give the agent, the better it performs. A "Compliance Monitoring Specialist" behaves. A "Business Assistant" wanders and, when an API drops, invents data.

That is the practical payoff hiding under the whole debate. Reliability comes from narrowing scope and hardening the boundary, not from adding more agents. And when you do go multi-agent, MongoDB's point on observability lands hard: once five agents each log to their own output with no shared trace ID, a small diagnosis turns into a multi-hour reconstruction. Budget for tracing before you split, not after your first bad incident.

Three questions for your team

1. Is the workload we're designing sequential or parallel? If sequential, why are we drawing more than one agent box?
2. Can each proposed agent's domain be written in one sentence with no "and"? If not, which of them collapse into tools inside a single agent?
3. If we ship multi-agent, do we have a shared trace ID across every agent before launch, or are we planning to debug blind?