The AI Orchestration Trap — why agent networks fail at scale.

The most sophisticated AI deployments in production today are not failing because the models are bad. They are failing because the organizations operating them confused orchestration with strategy.

Over the past six months, we have had dozens of conversations with product executives, CTOs, and heads of AI at companies running multi-agent systems in production. The pattern is remarkably consistent. A company starts with one or two AI agents handling specific tasks — summarizing support tickets, drafting code reviews, routing customer inquiries. The results are genuinely impressive. Leadership gets excited. The mandate comes down: scale it.

So the team builds more agents. Specialized agents for compliance checking, contract analysis, lead scoring, inventory forecasting, meeting summarization, internal documentation. Within six to twelve months, the organization is running thirty, forty, sometimes fifty or more distinct AI agents across departments.

And then something strange happens. Decision quality and speed drops.

01The microservices parallel nobody wants to hear

Software engineering already learned this lesson. Between 2015 and 2020, thousands of companies ripped apart monolithic applications and rebuilt them as microservices. The promise was compelling: independent deployment, team autonomy, technological flexibility. Netflix, Amazon, and Spotify became the poster children.

What most companies actually got was distributed complexity. Services that could not be understood in isolation. Debugging sessions that required tracing requests across fifteen different systems. Deployment pipelines that took longer than the monolith ever did. By 2022, even committed microservices advocates like Segment publicly documented their migration back to a simpler architecture after discovering their engineering team spent more time managing service coordination than building features.

Multi-agent AI systems are repeating this pattern — but the consequences are worse. When a microservice fails, it throws an error. When an AI agent fails, it hallucinates a confident answer and passes it downstream to the next agent in the chain. The failure mode is not a crash. It is a plausible-sounding wrong decision that nobody catches until it matters.

02The orchestration tax

Every agent added to a system introduces coordination costs. This is not a theoretical concern. It is measurable.

Consider what happens when a company deploys a customer support agent that handles initial triage, a knowledge retrieval agent that pulls relevant documentation, a sentiment analysis agent that flags escalation risks, and a response drafting agent that composes the actual reply. Four agents. Reasonable-sounding architecture.

But now each agent needs context from the others. The triage agent's classification becomes an input to the knowledge agent. The sentiment score influences the response tone. The knowledge retrieval results shape what the drafting agent can reference. That is twelve directional context dependencies across four agents — and that is the simple version.

Cognition, the company behind the Devin coding agent, made the case directly in its 2025 post Don't Build Multi-Agents: splitting a task across agents makes it harder to ensure each one has appropriate context, and in coding specifically, the coordination overhead frequently exceeded the benefit of specialization. (Cognition's own position has since softened — the firm now documents multi-agent setups that do work, typically by keeping writes single-threaded and letting additional agents contribute intelligence rather than actions.)

Anthropic's engineering team reached a complementary conclusion from the opposite direction. Its multi-agent research system outperformed single-agent Claude Opus 4 by 90.2% on Anthropic's internal research eval — so the upside is real when work is genuinely parallelizable. But the cost is real too: agents use roughly 4× the tokens of a chat interaction, and multi-agent systems roughly 15×. Anthropic is explicit that domains requiring all agents to share the same context, or involving many dependencies between agents, are not a good fit for multi-agent systems today.

The term both converged on — context engineering — reveals the core problem. The difficulty of multi-agent systems is not building agents. It is building the connective tissue between them. In a naïve all-to-all architecture, potential coordination relationships grow roughly with the square of the number of agents, while the value of each additional agent scales linearly at best. Well-designed systems avoid that topology through orchestration, hierarchy and bounded responsibilities — but avoiding it is a deliberate design act, not a default.

03The hallucination cascade

Single-agent hallucination is a known problem with known mitigations. Retrieval-augmented generation, structured outputs, human-in-the-loop verification — the toolkit is well-established.

Multi-agent hallucination is a fundamentally different beast.

If provenance, confidence and source lineage are not explicitly carried through shared state, downstream agents can treat an upstream inference as fact. Agent A produces a subtly wrong output and passes it to Agent B, which has no signal that the input was an inference rather than a finding. It builds upon it. Agent C receives Agent B's output — now two layers removed from reality — and incorporates it into a synthesis that gets presented to a human decision-maker as a coherent analysis.

This is an architectural failure, not an inevitability. Anthropic's own research system addresses it with a dedicated CitationAgent that processes the source documents and the draft report to attach specific citations to specific claims — a working demonstration that attribution can be preserved through a chain if you design for it. The cascade happens when nobody does.

The dangerous part is that the final output often looks more polished and confident than any single agent would produce alone. The chain of reasoning appears rigorous. The citations look real. The recommendations seem considered. But the foundation was wrong three steps ago, and nothing in the chain was designed to surface that.

04A starting heuristic: fewest roles that finish the work

The companies getting genuine, sustained value from multi-agent deployments share a counterintuitive characteristic: they use fewer agents than they could.

Box's 2026 executive commentary lands in the same place. Box COO Olivia Nottebohm has argued that as organizations focus their agentic AI efforts, they are learning that a few strategic agents will outperform many scattered ones. CEO Aaron Levie has made the adjacent point that the real impact arrives when agents are deployed into workflows and business processes, rather than used solely by individuals.

There is no universal ceiling on agent count, and we would be overstating the evidence to claim one. Anthropic's own guidance scales with the work: simple fact-finding may need a single agent, direct comparisons 2–4 subagents, and complex research more than ten when the work is genuinely parallelizable.

Our operating heuristic is narrower and deliberately conservative: start with the fewest agent roles that can complete the workflow. In many business processes, three roles are a useful starting pattern — an executor that does the work, a challenger that tests the output against known constraints, and a decision/orchestrator role that owns sequencing and escalation. Add agents only when specialization or parallelism creates measurable value.

This is not a claim about what models can support. Modern models can absolutely run more complex architectures. It is a claim about organizational clarity: every additional role adds context-engineering burden, hallucination surface area, and debugging complexity for the humans who remain accountable for the output. Those costs are worth paying when parallelism buys something real, and not otherwise.

05The organizational mirror

Here is the insight that most AI strategy discussions miss entirely: multi-agent architectures mirror organizational structures. And most organizational structures are already broken for the AI world.

When a company deploys an agent for each department — one for sales intelligence, one for marketing content, one for engineering documentation, one for HR policy — it is not building an AI strategy. It is automating its own silos. The agents inherit the same coordination failures, information asymmetries, and misaligned incentives that plague the human organization. They just execute those failures faster.

Companies that skip this question end up in a predictable place. They have impressive agent infrastructure generating impressive-looking outputs that do not connect to actual business decisions. They have what we call organizational noise at machine speed — the same fragmented, uncoordinated information production that already plagued their human workflows, now happening faster and with more confidence.

The pivot from "AI everywhere" to "AI where it matters" is becoming mainstream. This is not a retreat. It is a maturation. The companies that deployed agents broadly are now asking a harder question: which of these agents actually changed a decision we made? In our experience, the answer is uncomfortably often: very few.

06From orchestration to organizational design

The trap is thinking that agent orchestration is a technical problem. It is not. It is a design problem — specifically, an organizational design problem.

The companies that will extract lasting value from AI agent networks are doing something structurally different. They are designing the organizational logic first — which decisions matter, where information flows, what quality thresholds exist — and then mapping agents to that logic. They are not building agent networks and hoping organizational clarity emerges.

This means starting with three questions that have nothing to do with AI:

• Which handful of decisions most determine our performance?
• Where does the information for those decisions originate, and how does it reach the decision-maker?
• What would need to be true for those decisions to be made faster without being made worse?

Only after answering those questions does agent architecture become relevant. And when it does, the architecture is almost always simpler than what the team originally proposed.

The companies that understand their own decision-making structures will deploy fewer agents, more effectively, with clearer outcomes. The companies that do not will build increasingly complex orchestration layers to coordinate increasingly numerous agents that produce increasingly confident outputs that change increasingly few actual decisions.

That is the orchestration trap. And the organizations most likely to fall into it are the ones most excited about AI.

07From diagnosis to competitive advantage

The diagnostic is clear: your multi-agent infrastructure is a reflection of your organizational structure. And if that structure was not explicitly designed to move faster and clearer, your agents have inherited its faults at machine speed.

The next step is not buying better AI tools or hiring more engineers to coordinate your existing agents. It is asking a different question: what would it look like if we designed the organization first, then built AI infrastructure to serve it?

The questions to ask yourself

• Which handful of decisions in your organization most determine your performance? Can your executive team agree on the answer in one conversation?
• Of your current AI agents, how many directly serve one of those decisions — and how many are solving departmental problems that do not move them?
• If you turned off 50% of your AI infrastructure tomorrow, would anyone notice? If the answer is no, the agents are not paying rent.
• How would your business be different if your AI infrastructure were half as complex but three times as clear about what it was optimizing for?

The three moves that matter

Not all decisions are created equal. Until you can articulate which decisions disproportionately determine your performance, you cannot know which deserve AI support and which deserve human judgment. We have worked with dozens of organizations through this exercise. The pattern we see is consistent: the decisions that matter most rarely align with the departments currently building AI systems.

Once you know which decisions matter, the next question becomes: where does the signal come from? How does information reach the decision-maker today, and what would need to change for that decision to happen faster without being made worse? This is where most teams discover their AI is solving the wrong problem — accelerating information gathering when the real bottleneck is clarity about what to trust and when to act.

Only after answering the first two questions does agent architecture become relevant — and when it does, it is almost always simpler than the engineering team originally proposed. Fewer agents, clearer boundaries, explicit handoff points, and human oversight at inflection moments. This is not limiting your ambition. It is amplifying your execution.

Our work spans the three layers that determine whether your AI investment succeeds or fails: