agent·interface

Handoff design: escalation without losing context

The failure mode isn't escalating — it's escalating badly

Every agent hits a wall eventually: a request outside its authority, a low-confidence read on intent, a user who just wants a person. What happens next is the part most teams under-design. The agent stops, and a human picks up — but picks up what, exactly?

Nielsen Norman Group names this directly in its framework for site-specific chatbots: "handoff willingness" is one of five qualities that separate trustworthy bots from frustrating ones. Escalate too fast and you undermine the point of having a bot; refuse to escalate when a user asks, or when the bot plainly can't help, and you do worse damage (NN/g, "The 5 Qualities of Site-Specific AI Chatbots"). Willingness to hand off is necessary. It's also not sufficient — a bot that escalates freely but drops everything it learned just moves the customer's frustration downstream to a human who now has to reconstruct it.

A handoff is a transfer of state, not a transfer of blame

The instinct in a lot of shipped products is to treat escalation as an exit: the agent stops, a ticket appears in a queue, and the human starts from the transcript (if they're lucky enough to get one). That's a cold transfer, and it has a predictable cost — the person repeats themselves, the human re-derives what the agent already tried, and any time pressure that motivated the escalation compounds.

Intercom's own guidance for its Fin AI Agent calls out the two ways this goes wrong in practice: escalation notes that are too vague to be useful, forcing the agent to restart the conversation, and — worse — an escalated conversation with no context at all, which Intercom's team argues is worse than not automating in the first place (Intercom, "AI-Human Collaboration: Procedures & Handoffs"). Their fix is structural, not cosmetic: Fin and the human support team work off the same customer record, so a handoff doesn't require moving data between tools, and Fin is designed to collect the diagnostic information for a query before it escalates, so the human's job becomes a judgment call at the end rather than the whole investigation (Intercom Help, "Hand over Fin AI Agent conversations to another support tool").

Salesforce's Agentforce takes a similar view for voice: escalation is a first-class topic in the agent's logic, not an exception path bolted on afterward. A user can trigger it explicitly ("let me talk to a person"), or the agent's own policies can trigger it dynamically based on the conversation. Either way, the handoff routes through Salesforce's Omni-Channel engine, which checks for available human agents, passes conversation metadata (customer type, issue category) for routing, and keeps the full conversation history attached to the session as it transfers — with an explicit fallback path (queue, callback, or a case for later) if no human is free (Salesforce, "The Art of the Handoff: How Agentforce Voice Escalation Works").

The common thread across both: the thing being handed off isn't a conversation transcript, it's working state — what the agent tried, what it ruled out, what it's still uncertain about, and why it stopped.

What the protocols actually carry

Handoff has no dedicated standard the way tool-calling has MCP, but three specs each carry a piece of the wire format:

  • A2A's input-required state. In the Agent2Agent protocol's task lifecycle, a task in progress can transition to input-required when the agent needs something from the client to continue — missing information, a clarifying answer, or a secondary credential it doesn't hold. The client resumes the same task by sending a new message against the same task and context IDs, rather than starting over (A2A Protocol Specification).
  • LangGraph's interrupt(). For agents built as graphs, interrupt() pauses execution at a specific node, surfaces a value to whatever's driving the graph, and requires a checkpointer so the paused state is durable — a real recovery point, not just a paused function call. Resuming re-enters the node with the human's input available (LangGraph interrupts).
  • AG-UI's interrupt outcome. On the agent-to-frontend side, AG-UI standardizes the event stream that carries this same pause-and-resume shape to a UI, so a frontend doesn't have to invent its own polling or state-reconstruction logic per agent.

None of these three talk to each other. A2A's input-required is about client-agent messaging, LangGraph's interrupt is a framework-internal checkpoint, and AG-UI's event is about what a frontend renders. That's consistent with where the site's tracker already puts this: fragmented, convention-level, no unifying spec (our tracker on interrupt/resume). What they agree on, without coordinating, is the shape of the problem — a handoff has to be resumable from a durable, inspectable state, not a live process you either keep running or kill.

Designing the trigger, not just the transfer

The transfer only matters if the trigger fires at the right moment. In practice, teams building customer-facing agents combine a small set of signals rather than relying on one:

TriggerWhat it catchesRisk if missing
Explicit requestUser says "talk to a person"Refusing this erodes trust fast — NN/g's point above
Confidence thresholdAgent's own uncertainty on intent or next actionSilent wrong answers instead of a stop
Policy/compliance ruleRegulated actions (refunds, account changes, medical/legal topics)Agent acts outside its authority
Sentiment or repetitionUser frustration, repeated rephrasingAgent grinds the user down before conceding

The mistake to avoid is tuning only for the trigger and treating the transfer as an afterthought. A handoff that fires at exactly the right moment but arrives at the human as a bare transcript has just relocated the failure, not fixed it. The design questions that actually determine whether a handoff works are about the payload: What did the agent already try? What did it rule out? What's the specific, stated reason it stopped? A human who can answer "what does this person need" without asking the person again is the actual bar — everything else is plumbing to get there.

Handoff remains the least standardized of the core human-agent patterns; the tracker calls it out as still convention-only, with no protocol or vendor treating it as a first-class citizen the way approval gates or permission modes are now handled (our tracker on handoff & escalation). That gap is worth building toward deliberately rather than backing into it through a support queue's default behavior.


Tracking this space daily on the agent-interface tracker. Start at the hub if you're new to the term.