When to hand an agent back to a human.

Test escalation alongside successful runs. The demo works, the agent answers correctly on the cases the team tested, and escalation logic gets bolted on as a generic "if unsure, ask a human" prompt instruction. That instruction does almost nothing, because the model's sense of "unsure" is not reliable and not measurable.

An escalation path written only in the system prompt needs enforcement in code and tests against failure cases. The result is an agent that occasionally answers a customer question it shouldn't have, with total confidence, because nothing in the architecture stopped it. This is one of the most common reasons AI pilots never ship: the team can't answer "what happens when it's wrong," and that question doesn't go away just because it's uncomfortable.

The common advice in 2026 is "add a confidence score and escalate below a threshold." This sounds rigorous but usually isn't, because the confidence score comes from asking the model to rate its own certainty, and LLMs are notoriously bad at self-assessment. A model can produce a wrong answer with a stated confidence of 95%, because confidence language is generated the same way the rest of the response is: as plausible-sounding text, not a calibrated probability.

The fix isn't to abandon confidence scoring, it's to source the signal from outside the model's own narration. Retrieval score from your vector search, schema validation pass or fail, number of retries needed, and agreement between two independent model calls are all measurable, external signals. A self-reported "I'm 90% sure" is not a signal, it's a sentence.

1. Confidence below a measured threshold. Use an external signal, not self-report: retrieval relevance score, schema validation result, or agreement rate across repeated sampling. Set the threshold using your eval set, not a guess, and tune it over the first month in production.
2. Action above a defined blast radius. Any action that writes data, moves money, or sends a customer-facing message above a dollar or reach threshold should route through a human, regardless of the agent's confidence. Blast radius is a policy decision, not a model decision.
3. Repeated failure loop. If the agent has retried the same tool call or the same reasoning path more than twice without progress, it escalates instead of looping a third time. Loops are the single most common way an agent burns tokens and a customer's patience simultaneously.
4. Explicit user request for a human. Always honor this immediately, on the first ask, without a "let me try one more thing" delay. Users who ask for a human have usually already tried the automated path and lost patience.

Each of these triggers should be tested against your eval suite before launch, the same way you'd test any other piece of production logic. If you're building this into an MCP tool layer, the blast radius trigger belongs in the tool's server-side authorization logic, not just the agent's prompt.

An escalation that dumps a customer back into a queue with no context is worse than no automation at all, because now a human has to re-discover everything the agent already knew. A good handoff payload includes:

• Full conversation history, not a summary. Summaries lose the specific phrasing that matters for tone and intent.
• Every tool call made and its result, so the human doesn't repeat lookups the agent already did.
• The specific escalation reason, tied to one of the four triggers above, not a generic "needs human review."
• A suggested next action, if the agent has one, framed as a recommendation the human can accept or override in one click.
• A confidence breakdown of what the agent did know versus what triggered the escalation, so the human isn't starting from zero.

This payload should be visible in whatever tool the human uses day to day, whether that's a support desk, a CRM, or an internal dashboard. Building a new tool just for escalation review is a common mistake, since it adds friction exactly where speed matters most.

• Have you defined blast radius thresholds in writing, signed off by whoever owns the risk (finance, legal, support leadership)?
• Is your confidence signal external to the model's self-report, and is it logged for every request?
• Does your eval suite include at least 10 cases where the correct answer is "escalate," and does the agent pass all of them?
• Is the handoff payload rendered in the tool your human team already uses, not a new interface?
• Do you have a dashboard tracking escalation rate, false escalation rate, and missed escalation rate from day one?
• Has someone on your team manually reviewed 20 real escalations in the first week to confirm the payload is actually useful?

If this is what is holding your product back, send the project brief. I look at what exists, keep what works, and agree the journey that has to work before any build starts.

Two numbers matter more than raw escalation rate. False escalations are cases where a human reviews the handoff and confirms the agent could have handled it alone. A high false-escalation rate means your thresholds are too conservative, and you're paying human time for cases the agent has already mastered. Missed escalations are cases where a human catches a mistake the agent should have flagged but didn't. This is the more dangerous number, since it means bad outputs are reaching customers undetected.

Track both weekly for the first month, then monthly. A healthy trend looks like escalation rate slowly decreasing as trusted paths expand, while missed escalations stay near zero throughout. If missed escalations rise as escalation rate drops, you've loosened a threshold too fast. This kind of tuning is exactly the ongoing work covered in our agent orchestration guide.

The teams who get buy-in to expand an agent's scope are almost never the ones with the highest raw accuracy. They're the ones who can show a stakeholder a dashboard of clean escalations: cases where the agent correctly identified its own limit and handed off with full context, resulting in a fast human resolution. That visible discipline builds more trust than a black-box number claiming "94% accuracy," because nobody outside the team can verify a black-box number, but everyone can see a well-handled handoff.

This is why escalation design belongs in the first week of any agent build, not as a fix applied after a customer complaint. It's the difference between an agent that earns expanded scope over time and one that gets shut off after the first visible mistake.