Agent-Human Handoff: Why Pause/Resume and Handoff Aren't the Same Pattern
"Escalate to a human" is actually two different behaviors: a pause that waits for approval before the agent continues, and a handoff where the agent gives up ownership entirely. Conflating them is why a handoff so often means a human starting over from zero.
Part of: Agentic Workflow Design: The 4 Decisions That Keep an AI Agent Safe in Production
"Escalate to a human" sounds like one behavior, but it's actually two different ones wearing the same name. Sometimes the agent needs a human to say "go ahead" before it keeps doing its own job. Sometimes the agent has hit the edge of what it can do at all, and the job needs to become someone else's entirely. Building both as if they were the same pattern is why "escalation" so often means a human staring at a half-finished task with no idea what already happened.
Two Different Escalations, One Trigger Point
Decoupling Pause/Resume from Human Handoff
These are two distinct lifecycle patterns, not two names for the same thing. In a pause state, the agent saves its current progress to a checkpoint and suspends, waiting on authorization from a human - but it remains the owner of the workflow and will resume execution once approved. Resume is the second half of that contract: the agent wakes up from its checkpoint and continues, but if the wait was long enough for the world to have moved, it first runs a staleness check - re-verifying any input that could have gone stale during the wait, before it mutates anything. A human handoff is a different event entirely: the agent permanently relinquishes ownership, packages up everything gathered so far into a handoff payload, and transfers the task to a human to finish end to end. It doesn't resume - the human owns the rest of it.
Running example: InsuranceClaimBot - an agent that processes auto-insurance claims: reviewing submitted damage photos, checking policy coverage, and approving or routing payouts.
Two Claims, Two Different Escalations
A claim for $6,000 in collision damage clears every automated check and just needs an adjuster's sign-off because it crosses a payout threshold. The agent pauses, checkpoints the claim, and sends the adjuster an approval card. Four days later the adjuster approves it. This is a pause, not a handoff - InsuranceClaimBot still owns finishing the payout, it just needed a "go ahead" partway through.
A different claim comes in with photos that are blurry and inconsistent with the accident description, and the policy document itself won't parse. The agent retries its extraction three times and still can't get a clean read. There's no approval to wait for here - there's nothing valid yet to approve. This is a handoff: the agent packages the raw photos, its partial extraction attempts, and a specific description of what failed, and routes the claim to a human's queue. It doesn't come back to the agent afterward.
Routing InsuranceClaimBot's Escalations
Three claims, three reasons the agent stops - only one of them gets the claim back afterward.
Every automated check passes. The claim is valid - it's just large enough to require an adjuster's sign-off before disbursement.
The agent checkpoints the claim and waits for the adjuster. Once approved, it resumes - but first runs a staleness check: re-verify the policy is still active and the repair estimate hasn't been revised since the claim was paused.
The Staleness Check Is the Contract That Makes Resume Safe
The failure mode unique to pause/resume is assuming that whatever was true when the agent paused is still true when it resumes. It usually isn't, and the gap between those two moments is exactly the length of the wait. If InsuranceClaimBot pauses for a payout approval and the adjuster takes four days, resuming by immediately disbursing the payout at the exchange rate or claim valuation calculated four days earlier absorbs whatever drifted in the meantime - a currency move, a revised repair estimate, a policy that lapsed in the interim. The staleness check is what turns "resume" from a blind continuation into a safe one: re-query whatever inputs are time-sensitive before the next mutating step runs, not after.
The Longer the Pause, the Stricter the Staleness Check
Length of the wait → how much of the checkpointed state can be trusted on resume
Fast approvals rarely need re-verification - the data was current when checked, and very unlikely to have moved in under an hour.
Time-sensitive fields - exchange rates, price quotes, promotional terms - can drift within a day. Re-check anything that updates on that cadence before resuming.
Anything that can change day-to-day - policy status, credit standing, availability - needs a full re-check before resuming, close to treating the request as freshly submitted.
The instinct after a multi-day approval delay is to resume immediately and move on - the claim's been waiting long enough already. That instinct is backwards:the longer the wait, the more has had time to drift underneath it
These wait-length bands are illustrative, not universal - which fields actually go stale, and how fast, depends on your own domain (currency rates move by the minute, policy status by the day, credit standing by the week). Map your own time-sensitive fields to their actual drift rate rather than assuming this exact scale.
Handoff Is a Data Contract, Not a UX Behavior
Serious guidance on multi-agent and agent-human handoff treats it first as a data contract, and only second as a workflow step: the side handing off has to know exactly what to package, and the side receiving it has to know exactly what to expect. A handoff that just says "this claim needs a human" forces the adjuster to start from zero - reread the photos, re-run the same checks the agent already ran, and rediscover the same problem the agent already found. A handoff payload done right includes what was already gathered (photos, extracted fields, partial results), what the agent's own checks concluded (a specific similarity score, a specific field that failed to parse), and the specific reason execution stopped - not "extraction failed," but "VAT field unreadable after 3 OCR attempts on a smudged receipt region." The difference is a human picking up mid-task versus a human re-starting the same task the agent already tried.
Common Pitfalls in Agent-Human Handoff
A handful of mistakes recur across teams building their first pause/resume and handoff logic: skipping the staleness check on resume because the wait "was probably fine," which is exactly the assumption that fails after a multi-day approval delay; sending a handoff with no payload beyond "needs human review," forcing a full re-investigation from scratch; treating every escalation as the same pattern instead of deciding upfront which ones are a pause the agent will finish and which are a handoff it won't; and leaving a paused task with no expiry or reminder, so it sits waiting on a human who forgot it exists.
Handoff is where the other three decisions in agentic workflow design meet their limit: a well-scoped tool surface, a correctly calibrated autonomy tier, and a solid recovery plan all assume the agent can keep going. Handoff is the honest admission of the case where it can't - and a good one hands a human a task they can actually pick up, instead of one they have to start over.