When should an AI agent escalate to a person: how to design the handoff

Two true pilot stories, same product, opposite outcomes. In the first, the agent handles a complaint from one of the company's biggest customers and insists on resolving it with the standard returns policy. Technically it isn't wrong; commercially, the damage takes months to repair. In the second, the agent escalates practically everything that comes in, "just in case". Three weeks later the team is handling the same volume as always, only now with one more tool in the middle, and the pilot is cancelled for adding nothing.

Neither agent failed for lack of capability. Both failed for the same reason: nobody had designed the boundary between what the agent resolves and what goes to a person. That boundary —when to escalate, with what context, to whom, and what happens next— is the most important design decision in an operational agent, ahead of tone, scripts, or integrations. It's also the most neglected one, because it doesn't show up in a demo.

This article explains how to draw it. We're talking about agents that run real operational flows —calls, emails, follow-ups, with states and logging—, like the ones we describe in how AI agents are transforming B2B operations, not chatbots answering isolated questions.

Escalation isn't a failure of the agent: it's part of the design

The most widespread wrong intuition is treating escalation as a defeat: "if the agent escalates, it isn't working." That's how you end up with agents configured to resolve everything, which is exactly how the first visible mistake in front of a customer who matters gets manufactured.

The correct logic is the opposite. An operational agent is worth two things: what it resolves alone, and the quality with which it hands over what it shouldn't resolve. The second half protects the first: the team trusts the agent with real volume precisely because it knows the sensitive cases will reach it in time and with context. Without that trust, someone ends up reviewing everything "just in case", and the savings disappear.

That's why escalation is designed before launch, with the same seriousness as the main flow. In practice, it's part of scoping —the states, what gets resolved alone, the stop conditions— that we already recommend defining when choosing the first process to automate.

The two ways to fail: escalating too much and too little

A badly drawn boundary fails in two directions, and it's worth recognising both because they're fixed differently.

Escalating too little produces visible mistakes: a complaint treated as a routine query, a special condition granted without commercial judgement, a case with legal implications answered with a template. Each of these mistakes is expensive on its own, but the real cost is something else: the project's credibility. A single sensitive case badly resolved in public outweighs a hundred routine cases dispatched well.

Escalating too much produces a silent failure: the agent works, makes no mistakes, and still serves no purpose. If half the cases end up with a person, the team hasn't recovered hours; it has added a step. This failure mode is more treacherous because it generates no incidents to investigate: simply, at the end of the pilot, the savings metrics never show up, as you can see quickly when putting a number on how much an agent saves.

Both failures share the same root: a boundary defined by feel ("this seems delicate") instead of explicit rules. The solution isn't a smarter agent, it's a better-drawn boundary.

Resolve, suggest, escalate: the boundary is drawn in three zones

The practical tool for drawing the boundary is classifying every case type in the flow into one of three zones.

Resolve. The agent acts end to end: answers the opening-hours query, confirms the appointment, logs the reason for the call, sends the reminder. This is where cases with a definable correct answer and a low cost of error go. It's the zone that generates the savings.

Suggest. The agent prepares the work and a person approves: drafts the reply to a claim, proposes a doubtful classification, prepares the lead's file with its recommendation. It's the middle zone for cases where the agent contributes 80% of the effort but the final decision needs human judgement. In a shared inbox, for instance, this zone is the difference between a prudent pilot and a reckless one.

Escalate. The agent transfers the complete case, with context, to the right person, and stops acting on it. This is where the cases that are sensitive by definition go, whether the agent could resolve them or not: the zone doesn't exist because the agent doesn't know how, but because it isn't its call.

The design exercise consists of walking through the process's case types and assigning each one to a zone, in writing. The golden rule: whatever isn't explicitly assigned ends up in "resolve" by default, because that's what the agent will do if nobody tells it otherwise. The gaps in the map are the future incidents.

The signals that should trigger a handoff

With the zones defined, what's missing are the triggers: the concrete conditions that move a case to "escalate" even if it started out as routine. In practice, eight come up again and again, almost regardless of the flow:

• The customer asks for a person. Always honoured, first time. Insisting on resolving after that request is the fastest way to burn trust in the channel.
• Hostile language or high emotional charge. Anger, threat of cancellation, mention of a formal claim. The agent's goal shifts from resolving to landing the handoff well.
• Strategic account or high amount. A list of accounts and an economic threshold checked before acting, not after.
• Legal or compliance implications. Mentions of claims, data protection, contractual terms. A person's zone, no exceptions.
• Requests for special conditions. Discounts, deferrals, exceptions to policy. The agent can capture the request; the decision is commercial, as we saw with payment reminders.
• Insufficient or contradictory data. If the source of truth doesn't respond or contradicts itself, the agent doesn't invent: it escalates with what it has.
• Low confidence in its own interpretation. An ambiguous case that fits no known pattern. Better one escalation too many than one made-up answer.
• Retries exhausted. If after the defined number of attempts the case doesn't move (nobody confirms, nobody signs, nobody replies), it goes to a person instead of insisting without limit.

Every flow adds its own —emergencies in after-hours calls, intent signals in lead qualification—, but these eight cover most sensitive cases from day one.

A good handoff is a case file, not a notification

This is where half the experience is decided. An escalation that only says "you have a pending case" forces the person to reconstruct the story and, worse, forces the customer to repeat it. That "I already told your assistant all this" is the exact moment the customer concludes that automation makes the service worse.

A well-designed handoff delivers five things:

• The full thread: every message, call, or attempt, in order, with no summaries replacing the original.
• An operational summary: what the customer wants, what has already been done and —crucially— why it's being escalated, citing the specific trigger.
• The captured data: customer, reference, dates, amounts, pending document. Everything the agent already validated, so nobody asks for it again.
• The case state: where in the flow it stands and which automatic actions have been stopped.
• The urgency: a query that can wait until tomorrow is not the same as an angry customer with a service down.

The quality test is simple: the person receiving the case should be able to act without asking the customer a single question the agent had already asked. If they can't, the handoff has failed, even if the routing worked perfectly.

Who each case reaches: routing and urgency

"Escalating to a person" is a simplification: in a real operation there are several possible people, and getting the destination wrong costs almost as much as not escalating. Complaints from strategic accounts go to the account owner; requests for conditions, to sales; technical emergencies out of hours, to the on-call rota; everything else, to the team's general queue with its priority.

The minimum design is a two-column table —case type, destination— plus an urgency rule: which cases can wait until the next working day and which alert immediately through the channel the team actually watches. Without that table, every escalation lands in the same tray, the urgent ones queue behind the trivial ones, and the advantage of escalating in time is lost in the backlog.

It's also worth defining the internal response commitment: a flawless handoff is useless if the case waits two days for someone to open it. The agent can tell the customer "someone from the team will contact you today" only if the routing and the internal commitment make it true.

What happens after the handoff

Three decisions close the design and tend to be forgotten.

The agent stops. From the moment of the handoff, no more automatic actions on that case: no reminders, no retries, no courtesy messages. Nothing erodes trust more than a customer who is already talking to a person and keeps receiving messages from the agent.

The closure gets logged. When the person resolves, the case is closed with its outcome in the same record where the agent documented its part. Without that, the process metrics break exactly on the most important cases.

Every escalation teaches something. Periodic review of escalated cases is the boundary's improvement mechanism: the ones the person resolved in a minute with a standard reply are candidates to move to "resolve" or "suggest"; the cases the agent resolved alone that later got reopened are candidates for new triggers. Day one's boundary is a hypothesis; week eight's should be better.

The metrics that tell you the boundary is well drawn

Four numbers are enough to know whether the design works, and they should be read together because they trade off against each other:

• Resolution rate without intervention: the share of cases the agent closes alone. It's the savings metric.
• Escalation precision: of the escalated cases, how many truly needed a person. The "false positives" —cases the person sends back or dispatches in a minute— point to an over-prudent boundary.
• Leaks: cases the agent resolved alone that ended in a reopening, complaint, or correction. These are the "false negatives", the most expensive ones; they should tend to zero on sensitive case types.
• Time to person: how long an escalated case takes to be picked up. It measures whether the routing and internal commitments work.

The usual trap is optimising the first at the expense of the third: pushing up automatic resolution by letting through cases that shouldn't pass. That's why they're read together. A good boundary adjustment raises resolution without intervention and keeps leaks in check; if it only achieves one of the two, the boundary is in the wrong place.

In the first weeks, a high escalation rate isn't a bad sign: it's a prudent boundary while everything gets calibrated. The alarm signal is that it doesn't evolve: the same share of escalations in week one and week eight means nobody is reviewing and adjusting.

Where BeeAgent fits

In BeeAgent, escalation isn't a bolt-on feature: it's part of the flow from the design stage. Each agent is configured with its three zones —what it resolves alone, what it prepares as a suggestion, what it transfers—, its triggers (request for a person, flagged accounts, thresholds, risk signals, exhausted retries) and its routing by case type and urgency. The handoff travels with the full thread, the summary, the captured data, and the reason for escalation, and the case stays stopped for the agent until a person closes it.

And since it's a no-code platform, adjusting the boundary —adding a trigger, moving a case type from "resolve" to "suggest", changing a destination— is something the operations team does in minutes, without a development project. That short adjustment cycle is what lets the boundary improve week after week, as the guide to setting up your first agent without code explains. It is, in fact, the underlying difference between an operational agent and an answer bot, which we develop in customer service bot vs AI agent.

Design the boundary this week

You don't need a project to start: you need one afternoon and the people who know the process.

First, list the case types of the flow you want to automate and assign each one to a zone: resolve, suggest, or escalate. Treat anything left unassigned as a gap to close, not a minor detail. Second, write the triggers starting from the eight in this article and adding your own: your list of strategic accounts, your thresholds, your emergencies. Third, draw the routing table —case type, destination, urgency— and agree the internal response commitment with each destination.

With that launched, set aside 30 minutes a week for the two lists that sharpen the boundary: escalations that weren't needed and resolutions that leaked. Four weeks of that cycle are worth more than any perfect initial configuration.

Conclusion

An operational AI agent isn't judged only by what it resolves, but by how it hands over what it shouldn't resolve. The boundary between the two —the zones, the triggers, the handoff with context, the routing, and the metrics that watch it— is design, not chance: it's defined before launch and sharpened every week with data. Drawn well, it's what lets the team trust real volume to the agent without fear of the visible surprise; drawn badly, it's the reason most failed pilots fail.

If you're designing that boundary for your operation, the use cases show how it takes shape in real flows —from customer service to outbound calls— or write to us and we'll draw it together over your process.