Why agent handoffs are becoming the real scalability limit in multi-agent workflows

Agentic Business Design

25 April 2026 | By Ashley Marshall

Your multi-agent workflow is not failing because the models are weak. It is failing at the seams between them, and the production data on this is now embarrassing.

The handoff is the new bottleneck

The fashionable answer to scaling AI work is to add more agents. Stack a planner on top of a researcher on top of a writer on top of a reviewer, and watch throughput climb. The reality on production teams is that throughput does not climb. It collapses. The slowest, most fragile part of any multi-agent system in 2026 is no longer the model. It is the moment one agent finishes and another picks up.

In the field, most so-called agent failures are not capability failures at all. They are coordination failures at the seam. Anthropic's own engineering guidance on when to use multi-agent systems makes the same point in plainer language: every additional agent multiplies token spend and risk, and only a narrow band of problems actually pays back the cost. Yet vendors keep selling org charts of agents as though more boxes equalled more output.

The numbers from production deployments are sobering. The GitHub engineering blog reports that production agent systems typically run at 5 to 15 percent failure rates, with coordination breakdowns accounting for as much as 35 percent of those failures inside enterprise estates. State synchronisation alone is responsible for roughly 40 percent of multi-agent system failures, according to telemetry summarised in the Atlan multi-agent scaling analysis. None of those numbers reflect a model getting the answer wrong. They reflect agents getting the wrong answer to each other.

If you are running a business workflow that touches more than two AI agents in sequence, that is the metric that should worry you. Model accuracy is largely solved at the level your workflow needs. Handoff fidelity is not, and the gap is widening as teams keep adding hops.

What the production data actually shows

A study by independent researcher Jeremy McEntire, summarised in CIO magazine in March 2026, ran the same business task through agent topologies of increasing complexity. A single agent solved the task 28 out of 28 times, a clean 100 percent. A hierarchical multi-agent setup dropped to 64 percent. A self-organising swarm fell to 32 percent. An 11-stage gated pipeline, the kind every vendor demos on stage, got the answer right zero times out of 28.

That is not a rounding error. That is a structural collapse. As CrowdStrike principal engineer Diptamay Sanyal put it in the same piece, failure rates climb fast as complexity increases, and orchestrated chaining outperforms true collaboration. Cisco's Nik Kale was blunter, calling the marketing vision of autonomous agent collectives a fantasy that violates information theory. Both engineers ship to large regulated customers. Neither is a contrarian voice on the fringe.

The production telemetry tells the same story from a different angle. Atlan's multi-agent scaling research found coordination latency growing from roughly 200 milliseconds with five agents to 2 full seconds with fifty, before any agent has done useful work. Multi-agent patterns also consume around 200 percent more tokens than single-agent equivalents on the same task, because agents spend most of those tokens restating, reconciling and justifying context to each other at every handoff. The bill arrives long before the value does.

The takeaway is not that multi-agent systems are bad. It is that every handoff carries a real, measurable cost in accuracy, latency and spend, and you only get to absorb so many of them before the system stops being a system and starts being a slot machine.

Why context dies at the seams

The intuition most teams start with is that if we just pass more context, the next agent will figure it out. That intuition is wrong, and it is expensive to be wrong about.

Engineering writeups from teams running multi-agent pipelines in production now refer to this as the context dump fallacy. Transferring more raw context between agents does not improve decision quality. It increases noise, it degrades downstream reasoning, and it strips out the decision logic of the agent that ran first. The receiving agent gets a wall of text and has to reverse-engineer what it is supposed to do. Under time pressure, with completion incentives, it often does not bother.

The XTrace blog on agent context handoff is more specific about what gets lost. When one agent finishes and another takes over, what disappears is not the raw data, it is the decisions, reasoning and evidence that justified the previous step. The next agent sees an outcome and re-derives a plan from scratch, which is exactly how agents end up convincing each other of fabricated facts. Both have an incentive to agree because both are trying to satisfy a completion objective, and neither is auditing the other.

What this means in practice is that the failure mode bites finance, legal and clinical teams hardest. A research agent surfaces three sources, the synthesiser drops two, the reviewer cannot tell which two were dropped or why, and the result reads like a confident answer that no one in the chain can defend. At that point the value of the system is negative, because a human still has to redo the work, and now they have to undo the wrong work first. That is not automation. That is the appearance of automation.

Typed handoffs are now table stakes

The pragmatic fix is unsexy and well understood. Treat every agent-to-agent handoff as a public API. Constrain the output of the upstream agent to a typed schema, ideally enforced at generation time using structured-output features or JSON Schema. Validate it on receipt. Reject anything malformed before it reaches the next model.

GitHub's engineering team put this directly in their guide to engineering multi-agent workflows that do not fail: typed schemas are table stakes, and without them nothing else works. That is a strong claim from a team that ships agent infrastructure for a living. It also matches what Asymbl's chief digital labour officer Shivanath Devinarayanan reports from running more than 150 agents in production. Their team only got there by mapping every handoff in advance, defining roles narrowly, and refusing to let agents negotiate scope with each other in free text.

The deeper principle is borrowed from distributed systems. If two services communicate, you do not let them invent the protocol at runtime. You version it, you test it, and you fail loudly when it changes. AI agents are services. The fact that they happen to use language models inside does not exempt them from that discipline. If anything, the non-determinism of language models makes the discipline more urgent, not less, because a free-text handoff that worked yesterday can quietly drift tomorrow with no code change at all.

What this means in practice for a team building agent workflows today: any field passed between two agents should have a name, a type, an example, and a validator. Anything that cannot be expressed that way probably belongs inside one agent, not crossing a boundary at all.

The UK regulatory backdrop sharpens the problem

This is not just an engineering issue. It is rapidly becoming a governance issue, and the UK is one of the markets making that explicit.

The Department for Science, Innovation and Technology published its AI Playbook for the UK Government alongside the AI Opportunities Action Plan One Year On report on 29 January 2026, which confirmed that 38 of 50 commitments from the original plan have been delivered. The direction of travel is clear: more public-sector AI, more regulated-sector AI, and growing pressure on suppliers to evidence how decisions were made. The Public Sector AI Adoption Index 2026 ranks the UK sixth out of ten with a score of 47 out of 100, which Whitehall has framed as evidence that adoption inside organisations, not strategy from the top, is the bottleneck.

In parallel, Security Minister Dan Jarvis told CYBERUK 2026 that the National Cyber Security Centre is actively seeking industry collaboration on safe AI adoption, and warned that frontier AI tools can be unreliable, difficult to validate, and hard to integrate safely. The NCSC's own blog on supporting AI adoption for UK cyber defence reinforces the same point. The government will fund AI ambitiously, including the £500 million Sovereign AI Unit announced in April 2026, but it expects auditability in return.

What this means in practice for a UK business deploying agentic workflows: regulators will not accept the agents talked to each other as a description of how a regulated decision was reached. The Information Commissioner's Office, the Financial Conduct Authority and clinical governance bodies all expect a defensible audit trail. A multi-agent workflow with free-text handoffs cannot produce one. A workflow with typed, logged handoffs can, and the gap between those two designs will become the gap between approved and blocked.

How to design handoffs that actually scale

The fix is not to abandon multi-agent systems. It is to design them like software, not like staff.

Start by counting handoffs. If your workflow has more than three or four agent-to-agent transitions, ask whether the work could be done by one agent with better tooling. The McEntire data is unambiguous on this: every additional handoff costs you accuracy, and the curve is steeper than most teams assume. Cisco's thin orchestration layer is a better mental model than agent team. The autonomy you think you are buying with extra agents is mostly being spent on coordination, not on output.

Second, make every handoff explicit. Define the schema. Validate it on both sides. Log the full input, output and decision rationale at each boundary. If your platform cannot replay a handoff after the fact, you cannot debug it, and if you cannot debug it, you cannot trust it in production. That replay log is also the audit trail the ICO and FCA will want to see when something inevitably goes wrong, and you do not want to be retrofitting one under regulatory pressure.

Third, put humans where the consequences are highest. Anthropic's own guidance recommends reserving multi-agent setups for high-value, parallelisable, fault-tolerant tasks, and inserting human review at the points where errors cost most. That is the opposite of the fully autonomous pitch, and it is the pattern that actually ships.

Finally, treat coordination as a budget. Token spend, latency and failure probability all grow with handoffs. Allocate a budget per workflow and refuse to exceed it without a clear reason. A two-agent system that works is worth ten times a fifteen-agent system that almost works. The teams shipping reliable agent products in 2026 are the ones who internalised that and stopped trying to build a digital org chart.

Frequently Asked Questions

What exactly counts as an agent handoff?

A handoff is any point where one AI agent passes work, data or context to another agent for the next step. It includes orchestrator-to-worker delegation, sequential pipeline stages and peer-to-peer agent calls. It does not normally include tool calls back to the same agent, although the boundary blurs in some frameworks.

Are multi-agent systems just a bad idea then?

No. They are the right pattern for genuinely parallel, fault-tolerant work where you want different specialisations running concurrently. They are the wrong pattern for sequential, high-stakes decision chains where every step depends on the last. The error most teams make is using multi-agent for the second case because it sounds modern.

How do typed schemas help in practice?

They turn each handoff into a contract the receiving agent can rely on. Field names, types and examples are fixed. Malformed output fails validation rather than silently corrupting the next step. They also give you a predictable, loggable boundary you can replay during debugging or audit, which free text cannot.

What is a sensible number of agents in a workflow?

There is no magic number, but the production data is consistent: accuracy drops sharply as you go past three or four sequential handoffs. If you find yourself reaching for more, look for opportunities to fold steps into one agent with better tools, or run agents in parallel rather than in series.

Does this affect compliance under UK rules?

Yes. The ICO, FCA and DSIT all expect organisations to be able to explain how an automated decision was reached, particularly in regulated sectors. Free-text agent-to-agent communication produces a chain that cannot be reconstructed reliably. Typed, logged handoffs produce one that can. That distinction is increasingly the deciding factor in whether a workflow is allowed to ship.

How do you actually debug a failing handoff?

You need three things: the exact input the upstream agent saw, the exact output it produced, and the exact moment the schema or validator rejected it. Without those, you are reading model rationalisations rather than facts. Most observability platforms now expose this if you wire it in deliberately, but only if your handoffs are typed in the first place.

Are tool calls the same as handoffs?

Not quite. A tool call is an agent reaching out to a deterministic external system, like a database or an API, and getting a structured response back. A handoff is an agent passing work to another non-deterministic agent. Tool calls are usually safer because the response is bounded. Handoffs are riskier because both sides are language models making judgement calls.

Which frameworks support typed handoffs today?

LangGraph, CrewAI and the Anthropic SDK all support structured outputs and schema-validated handoffs to varying degrees. The Model Context Protocol is also pushing the industry toward stricter typing at agent boundaries. The framework matters less than the discipline. Any framework can be used badly, and any framework can be used well if the team treats handoffs as a contract.