How to Design AI Agent Handoff Protocols That Don't Create New Failure Points

Agentic Business Design

21 May 2026 | By Ashley Marshall

Most multi-agent AI systems don't fail inside any single agent. They fail in the gaps between them. Handoff design is where production deployments succeed or collapse.

Why Handoffs Are Where Agentic Systems Break

The demos always look clean. One agent researches, another writes, a third reviews and publishes. The workflow runs flawlessly in a controlled prototype environment. Then you deploy it to production and something breaks, not inside any one agent, but in the space between them.

This is the handoff problem. It is one of the most underdiagnosed failure modes in agentic AI design, and it is where the majority of production multi-agent systems fall apart. A 2025 RAND study found that 80 to 90 per cent of AI agent projects fail in production, and the cause is rarely a bad model. It is bad system design. Specifically, it is the failure to treat the boundary between agents as a first-class design concern.

The fundamental challenge is that most organisations build each agent as if it is the only actor in the system. The prompt is optimised for what the agent receives. The output is formatted to look coherent to a human reviewer. But when that output becomes the input for the next agent in the chain, format assumptions break, context is dropped, and errors propagate silently through the pipeline.

Unlike a single-agent failure where a human sees the output and can catch a hallucination or a formatting problem, multi-agent failures are invisible by default. One poorly structured response from Agent A becomes trusted input for Agent B, which builds on it and passes a compounded error to Agent C. By the time the output reaches a human, the failure is three layers deep and almost impossible to trace back to its source.

A concrete example from production: in a finance pipeline test, one agent hallucinated a five-times cost difference. The error propagated through three downstream agents before reaching output. It reached production because no one was monitoring the inter-agent communication channel. The model was performing correctly from its own perspective. The handoff design had no verification layer between agents.

That is the core issue. Handoffs are not a model problem. They are a systems design problem. Solving them requires deliberate attention to three things: what gets transferred between agents, how it gets structured, and who or what validates it before the next agent picks it up. Organisations that get this right build agentic systems that compound in value over time. Those that get it wrong build systems that compound in failure.

The Three Root Causes of Handoff Failure

Research from enterprise engineering teams studying production multi-agent systems identifies three recurring sources of handoff failure that appear across almost every deployment. Understanding these distinctly matters because each requires a different fix.

Lost state is the most common failure mode. When a workflow pauses, restarts, or times out, the context the originating agent had at the start of the task is gone. The receiving agent, whether it is another AI or a human reviewer stepping in, has to reconstruct intent from whatever fragment of context was passed across the boundary. This reconstruction is almost always incomplete. Engineers end up reverse-engineering what the agent was doing, why it made certain choices, and what it was about to do next.

The fix for lost state is not making the model smarter. It is architecture. A three-tier memory design, separating prompt context (what is in the active window), retrieved knowledge (what can be pulled from a vector store or structured database), and serialisable task state (a durable record of what has happened and what remains to do) gives each agent a stable foundation that survives restarts and handoffs. If you build agents with monolithic context where everything is jammed into a single expanding prompt, you will keep losing state every time a workflow pauses.

Weak escalation design is the second failure mode. Most early agentic systems have one escalation behaviour: the agent either finishes or it stops and asks for help. There is no gradient. An agent that is 80 per cent confident on a routine data extraction task gets the same treatment as one that is 60 per cent confident about whether to delete a customer record. The result is that review burden accumulates everywhere, humans stop paying attention because most escalations are unnecessary, and genuinely risky actions slip through because the system cried wolf too often.

Good escalation design is tiered. Routine, low-risk, high-confidence outputs proceed automatically. Medium-confidence outputs are flagged for lightweight review. Irreversible or high-stakes actions require explicit human approval before execution. This is a design choice that must be made explicitly. Left undefined, agents default to the behaviour that made the demo look impressive, which is usually far too autonomous for production use.

Unclear uncertainty signals are the third failure mode and the subtlest. When an agent is not confident in its output, it often does not say so clearly, or it expresses uncertainty in prose that gets buried in a longer response. Downstream agents treat the output as authoritative. Human reviewers see a formatted response and assume accuracy. The confidence level was embedded in a sentence somewhere in the middle of a paragraph that no one read carefully.

The Stack Overflow Developer Survey 2025 found that 84 per cent of developers use or plan to use AI tools, but only 29 per cent trust AI outputs to be accurate. That gap is precisely the cost of unclear uncertainty signals. If your system is not surfacing confidence levels in a machine-readable, actionable way, you are relying on human reviewers to maintain vigilance across every output. That does not scale as agent adoption spreads across an organisation.

Designing Your Output Contract

The most consequential design decision in a multi-agent system is not the model you choose or the prompt you write. It is the output format of each agent at the point where it passes work to the next stage.

In a single-agent system, output is designed for humans. Conversational, readable, loosely formatted. That is fine when a person is the direct consumer. The moment you chain agents together, the same logic that governs API design applies: a consumer depends on a producer, and if the producer's output format changes without notice, the consumer breaks. Unlike a traditional API, agents do not throw typed errors when they receive malformed input. They hallucinate a response based on what they received and carry on, propagating the error downstream.

A well-designed output contract has three components. First, a status field. Every agent handoff should include an explicit status indicator: complete, partial, failed, or uncertain. Downstream agents and orchestrators route based on status. Without it, they have to infer completion from the content of the response, which is unreliable, especially for edge cases that were not covered by the original prompt.

Second, typed fields for any data that will be read programmatically. Contract metadata, financial figures, customer identifiers, dates, flags, and confidence scores should be extracted into named fields in a structured format, not left embedded in prose. A contract extraction agent should return something like: status, party names, effective date, contract value, flags such as renewal clauses or arbitration requirements, and a confidence score as a decimal. The downstream agent reads named fields. It does not parse sentences looking for numbers.

Third, a versioned schema when multiple systems depend on the output. Schema versioning is basic API hygiene that almost no one applies to agent outputs. It should be standard practice for any output that feeds more than one downstream consumer, particularly in systems where different teams or business units are adding new agents over time. Without versioning, a change to one agent's output format can silently break consumers that were never updated.

The choice between JSON, Markdown, and plain prose as a serialisation format depends on the downstream consumer. JSON is the right default for machine-to-machine communication. Markdown works well when the output may be reviewed by a human before being processed further: it is legible to people and parseable by structure. Plain prose is only appropriate when the direct consumer is a human and no further automated processing is expected.

What this means in practice: before you design an agent's prompt, design its output schema. Define the fields. Define the types. Define the confidence representation. Document the schema version. Only then write the prompt that produces it. Most teams do this in reverse, which is precisely why their pipelines break at the boundaries between agents rather than inside them.

Escalation Patterns That Actually Work in Production

Effective escalation design is not about making agents ask for help more often. It is about making them ask for help at the right moments, with enough context that the help is actually useful when it arrives.

There are two core escalation patterns that consistently work in production environments. The first is threshold-based confidence escalation. Rather than a binary complete or incomplete state, you define escalation thresholds based on measurable proxies: confidence score, number of retries, tool-call count, elapsed reasoning time. When any threshold is exceeded, the workflow escalates to human review before the output moves downstream.

An Anthropic study measuring agent autonomy found a revealing behavioural pattern: experienced users auto-approve agent actions in over 40 per cent of Claude Code sessions, more than double the roughly 20 per cent rate for new users. Experienced users also interrupt more often during execution. This is not random behaviour. Experienced users have developed a calibrated sense of when to trust agent output and when to scrutinise it. They vary their scrutiny based on what the agent is doing and the stakes involved. Your escalation system should replicate that calibration in code, not rely on individuals developing it through experience.

The second core pattern is the high-risk action gate. Any action that is irreversible or has significant external effects should require explicit approval before execution. This covers writing to production databases, sending emails or messages to customers, making financial transactions, deleting or modifying files outside a sandboxed environment, and triggering any downstream system that cannot be rolled back easily.

Microsoft's AG-UI framework implements this through an approval_mode flag on sensitive tools. When a tool is marked as always requiring approval, the framework generates a FUNCTION_APPROVAL_REQUEST event, pauses execution, surfaces the pending action to a human reviewer, and resumes only after explicit sign-off. LangGraph implements the same checkpoint pattern through its interrupt() function: the first invocation pauses at the interrupt, stores the complete workflow state under a stable thread identifier in the configured checkpointer, and waits. A subsequent invocation with the same thread identifier and an explicit resume command restores the paused state and continues from exactly where it stopped. The workflow does not lose context. The reviewer does not have to reconstruct intent from scratch.

What organisations typically get wrong is treating escalation as a catch-all mechanism rather than a calibrated system. If every borderline output escalates, humans stop reviewing carefully because most of what reaches them is unnecessary. If nothing escalates, risky actions proceed unchecked until something goes wrong. The right balance is tiered: automatic for routine and high-confidence work, lightweight review for medium-confidence outputs, and hard gates for irreversible actions. Define those thresholds explicitly, document them, and treat them as a governance decision rather than a technical parameter to be tweaked later.

The MAP study, which analysed 86 production or pilot multi-agent systems drawn from 306 survey responses, found that 68 per cent execute at most 10 autonomous steps before human intervention. That is not a limitation imposed by immature technology. That is a design choice made by teams who understand that each additional autonomous step compounds the probability of a silent failure that will be very difficult to trace back. Short autonomy loops with clear escalation points are not a sign of weak agents. They are a sign of mature system design.

What This Means for UK Businesses and Regulatory Compliance

UK businesses deploying agentic AI systems operate within a regulatory framework that directly shapes where handoff design needs to be most careful. Understanding that framework is not optional for organisations in regulated sectors, and is increasingly relevant for everyone else.

There is no UK AI Act, and none is currently on the legislative timetable. The framework instead sits across three layers: UK GDPR as amended by the Data (Use and Access) Act 2025, sector regulators applying their existing rules to AI systems including the ICO, FCA, Ofcom, and PSR, and DSIT policy direction coordinating across the Digital Regulation Cooperation Forum. In February 2025, the government confirmed its position: most AI systems should be regulated at the point of use, by existing expert regulators rather than by a new dedicated body.

For agentic systems, this has specific practical implications. The ICO's position on automated decision-making under UK GDPR requires that decisions with significant effects on individuals cannot be made solely by automated systems without human review rights. If your agent pipeline makes recommendations about customer creditworthiness, employment suitability, pricing structures, or service access, you need a human-in-the-loop at the point where that decision is made, not just upstream in the research phase. Your escalation gates need to be placed at the right points in the workflow. A human reviewer who signs off on the research brief but never sees the final recommendation does not satisfy this requirement.

For financial services firms, the FCA's Consumer Duty requires that firms take reasonable steps to ensure good outcomes for retail customers. For agentic AI systems in customer-facing workflows, this means the handoff between your research agent and your recommendation agent cannot be a black box. If something goes wrong, you need an audit trail that shows what each agent received, what it produced, what confidence level it assigned to that output, and what was validated before anything reached the customer. That audit trail is not a nice-to-have. It is the mechanism by which you demonstrate compliance when a regulator asks what happened.

The broader practical implication for all UK businesses is accountability chain design. In a well-designed multi-agent system, every handoff produces a structured log record: what was passed, what schema version was used, what the confidence level was, whether a human reviewed it, and who or what took the subsequent action. This is good engineering practice regardless of regulatory status. For organisations in finance, healthcare, insurance, or legal services, it is also the audit trail that makes compliance demonstrable after the fact rather than theoretical at the design stage.

For most UK businesses outside formally regulated sectors, the compliance pressure is lower but the operational risk is identical. An agent pipeline that breaks silently because of a poorly designed handoff does not care whether you are subject to FCA oversight. The financial or reputational cost of a bad output that propagated through three agents before reaching a customer is real regardless of your regulatory classification.

The Counterargument: Will Better Models Just Solve This?

The most common objection to investing time in handoff protocol design is that it is an engineering problem that better models will eventually solve. If the next generation of foundation models is better at following instructions, maintaining context, and producing consistent structured outputs, the handoff problem diminishes on its own. This is a reasonable intuition. It also has a significant structural flaw.

Model capability and system design are solving different problems. A better model reduces the frequency of bad outputs from any individual agent in isolation. It does not change the structural fact that in a multi-agent pipeline, one bad output becomes trusted input for the next agent downstream. If Agent A produces a wrong answer with a 5 per cent error rate, Agent B inherits that error, builds on it, and passes a compounded error downstream. Even if next year's model reduces Agent A's error rate to 2 per cent, the propagation problem remains. You still need validation at the boundary between agents.

The finance pipeline example is worth returning to here. The model was not performing badly on its own. The initial error rate was low. The problem was structural and invisible: there was no verification layer between agents, so a single low-probability error passed through three stages unchallenged before reaching production. A significantly better model would have reduced the chance of the initial hallucination. It would not have added the verification layer that was missing from the architecture.

There is also a competitive dynamics argument. Better models are available to every organisation at roughly the same time, at roughly the same price point. The competitive advantage in agentic AI does not come from which organisation is first to upgrade their model version. It comes from which organisations have built reliable, observable, correctly-escalating agentic systems that can absorb new model improvements without structural changes. The harness around the model compounds in value over time. A team that has built proper handoff validation, tiered escalation, and durable state management in 2025 gets more value from a better model in 2026 than a team that is still debugging broken boundaries.

The enterprise teams who have deployed multi-agent systems for large insurance, finance, and professional services clients are consistent on this point: the quality of an agent depends more on how well its components are integrated than on the raw capability of the underlying language model. A well-integrated system with a mediocre model outperforms a loosely integrated system with an excellent one, because integration failures compound and model capability improvements do not cancel out structural design gaps.

The honest state of production agentic AI in 2026 is that the model is the least of your problems once you are beyond the prototype stage. The boundary conditions between agents are where the real work is. That is also where the real differentiation is. Organisations that invest in handoff design now are building infrastructure that gets more valuable as agent capability increases, not less.

Frequently Asked Questions

What is an agent handoff protocol?

An agent handoff protocol is the structured mechanism by which one AI agent passes control, context, and data to another agent or to a human reviewer in a multi-agent workflow. It defines the output format, the state information that must be preserved, the confidence level associated with the output, and the conditions under which human review is required before the next agent proceeds.

Why do multi-agent systems fail at handoffs rather than inside individual agents?

Individual agents fail visibly: a human sees the output and can catch a problem. Multi-agent failures are invisible by default. When Agent A produces a bad output, Agent B treats it as authoritative input, builds on it, and passes a compounded error downstream. By the time the failure reaches a human, it has propagated through multiple stages and is very difficult to trace back to the original source. The failure is structural rather than model-level.

What is hallucination propagation and why does it only appear in multi-agent systems?

Hallucination propagation occurs when an incorrect output from one agent is accepted as trusted input by the next agent in a pipeline, which then builds on the error and passes a compounded version further downstream. In a single-agent system, a hallucination reaches a human and can be corrected. In a multi-agent pipeline, it travels through stages that have no reason to question it, because each agent treats the previous output as ground truth unless the architecture explicitly includes a validation step.

How should I structure agent output to make handoffs reliable?

Every agent output that feeds another agent should include: a status field (complete, partial, failed, or uncertain), typed named fields for any data that will be processed programmatically, a confidence score as a decimal value, and a schema version identifier if multiple consumers depend on the output. JSON is the right default format for machine-to-machine handoffs. Markdown works when the output may be reviewed by a human before further processing.

What does a high-risk action gate actually look like in practice?

A high-risk action gate is a hard pause in the workflow before any irreversible or externally visible action is taken. In LangGraph, this is implemented through the interrupt() function, which pauses execution and stores state under a stable thread identifier. A human reviewer approves the pending action, and execution resumes from exactly the point it paused. Microsoft's AG-UI implements the same pattern through a FUNCTION_APPROVAL_REQUEST event. The key requirement is that the gate must preserve the full workflow state so the reviewer has context, not just a yes or no prompt.

Does UK GDPR apply to AI agent pipelines?

Yes, where agent pipelines make or significantly influence decisions with effects on individuals. Under UK GDPR as amended by the Data (Use and Access) Act 2025, individuals have rights regarding solely automated decisions with significant effects on them. The ICO's position means that for customer-facing decisions about creditworthiness, pricing, service access, or similar matters, you need a human-in-the-loop at the decision point itself, not just upstream in the workflow. Your escalation gates need to be positioned accordingly.

How many autonomous steps should an agent pipeline take before requiring human review?

The MAP study of 86 production multi-agent systems found that 68 per cent execute at most 10 steps before human intervention. That figure reflects deliberate design choices by teams who understand that each autonomous step compounds the chance of a silent failure. There is no universal answer, but as a starting point: keep autonomy loops short, define escalation thresholds explicitly, and increase the loop length only after you have established observability and demonstrated that the system behaves correctly across the range of inputs you actually receive.

Is it better to build one complex agent or chain multiple simpler agents?

For most production use cases, a single well-designed agent or a Level 2 to 3 workflow with conditional logic is preferable to a full multi-agent pipeline. Multi-agent systems are appropriate when tasks genuinely split into subtasks requiring different tools or models, and when the specialisation provides measurable value over a single agent approach. The MAP study found that adding agents is most valuable when it shrinks each agent's responsibility. If your agents are all using the same tools and passing similar context back and forth, the orchestration overhead is adding cost without adding capability.