When Should an AI Agent Hand Off to a Human? A Decision Framework

Every conference talk about AI agents contains the same diagram: the agent handles a conversation, then "escalates if needed".

Nobody defines "if needed". That undefined word is where most deployments fail — in one of two directions.

The two failure modes

Everything escalates. The agent is cautious, refuses anything ambiguous, and hands off 40% of calls. You have paid for a router to a human queue, and the human workload barely moved. This is the most common outcome in the first month.

Nothing escalates. The agent is confident, answers everything, and invents policy when it does not know. Customers get confident wrong answers. This is the more expensive outcome, and it usually surfaces as a complaint rather than an error.

Both come from the same root cause: the split was never decided explicitly. It was left to the agent's judgement, which is another way of saying it was left to chance.

The split: lookups versus judgements

The line that has held up across every deployment I have seen is this:

Automate the lookup. Leave the judgement to a person.

A lookup has a verifiable answer in your material. A judgement has an answer that depends on context, consequence, or a relationship.

Lookups an agent should own:

• Is there availability on Thursday
• What are your hours, address, parking situation
• What does this service cost, and what is included
• What do I need to bring
• Where is my order
• How do I cancel, and what is the notice period

Each has a single correct answer that exists somewhere in your documents.

Judgements a human must own:

• Whether to refund, and how much
• Whether to waive a fee
• What to do about a complaint, especially an angry one
• Anything medical, legal, or financial
• Whether this customer's situation is an exception
• Anything that could damage the relationship

Each depends on factors outside the transcript: history, margin, risk appetite, how the customer has behaved before.

The awkward middle

There is a third category, and it is the one that actually needs design work: collect-then-route.

The agent cannot decide, but it can do the intake. Booking a plumber for an emergency, taking a claims report, gathering details for a quote — these are judgements, but the judgement is not immediate.

Handled well, the agent collects structured information and hands off a brief. Handled badly, it hands off a phone number and a first name, and the human starts from zero.

The rule: if you escalate, escalate with work already done.

A decision table you can copy

• Situation — Answer exists in your documents Who owns it — Agent Why — Verifiable, repeatable
• Situation — Answer requires a policy exception Who owns it — Human Why — Consequence and precedent
• Situation — Answer involves money out Who owns it — Human Why — Margin and risk
• Situation — Answer involves health, law, or finance Who owns it — Human Why — Liability
• Situation — Customer is upset Who owns it — Human, quickly Why — Relationship, and de-escalation is a skill
• Situation — Customer wants to cancel Who owns it — Human, but with retention context Why — One conversation decides the relationship
• Situation — Details needed, decision later Who owns it — Agent collects, human decides Why — Intake is mechanical, decision is not
• Situation — Emergency or safety Who owns it — Human immediately Why — Never queue safety

The last row deserves emphasis: anything that might be an emergency should not wait behind a routing decision or a queue. It should reach a person, and the agent should say clearly that it is doing so.

The two rates to watch

Escalation is not a failure to be minimised. It is a control. But it needs to be measured in both directions.

Escalation rate. What share of conversations reach a human? If it is above roughly a third, the agent's knowledge is probably thin, not its judgement. Check the coverage before adding conditions.

Missed-escalation rate. Sample twenty conversations a month where the agent resolved the issue without a human. Read them. You are looking for cases where it should have escalated and did not — a refund it promised, a medical question it answered, an exception it granted.

The second number is invisible in any dashboard and is the one that determines whether the deployment is safe.

What "escalate" should mean

Three different things get called escalation, and conflating them causes most of the confusion:

• Consult: ask a specialist for an answer, keep talking to the customer yourself.
• Transfer: hand the conversation over, with full context.
• Escalate: stop, and route to a human.

The distinction matters because they have different costs and different failure modes. A consult that silently becomes a transfer drops context. A transfer that should have been an escalate strands someone in a queue.

Decide which one each scenario needs, and write it down. "Escalate if needed" is not a specification.

The honest summary

An agent is good at being consistent and fast on questions that have answers. It is bad at being accountable for decisions that have consequences.

Design the split around that, measure it in both directions, and keep the escalation path tested — because the day it stops working is the day you find out whether it was real.

Disclosure: I work on RingBot, an Agent-as-a-Service platform where agents can consult another agent, transfer a conversation with context, or escalate to a person — each configured per scenario. The framework above is what I would apply to any platform; the hard part is your own judgement split, which no vendor can decide for you.

Related: missing default route, the handoff brief, transfer is five features, why agents answer wrongly.