AI agent handoffs: designing escalation to a human

Every agent deployment we have worked on has eventually turned on the same question, and it is never the one the client expected. It is not what the agent can do. It is what it does when it reaches something it should not decide.

That question gets deferred because it is unglamorous. A demonstration shows the happy path — the agent reads the document, matches the transaction, sends the reminder. Nobody demonstrates the ambiguous case, so nobody designs it, and the agent ships with escalation as an afterthought: a queue, an email alert, a flag on a record. Within a month that queue has several hundred items in it, no owner, and no defined resolution time. The agent is technically working. The process is not.

Handoff design is the difference between an agent that reduces work and one that relocates it. The relocation is worse than the original state, because at least a manual process had someone accountable at every step.

Why this matters

An unresolved escalation queue fails in three ways simultaneously, and they compound.

The work does not get done. Items in an unowned queue age. In finance processes, ageing has consequences — an unresolved reconciliation exception becomes a close delay, an unresolved invoice query becomes an overdue payable, an unresolved order exception becomes a customer who did not receive their goods.

Trust in the agent collapses on the wrong evidence. When something goes wrong, the failure is attributed to the agent even though the agent behaved correctly by escalating. What failed was the handoff. But the organisational memory records "the AI got it wrong," which makes the next deployment harder to fund.

Nobody learns anything. A well-designed handoff produces information: which cases the agent could not resolve, why, how a human resolved them, and whether that resolution could be encoded. A badly designed one produces a queue. The first improves the agent monthly; the second guarantees the same exceptions recur indefinitely.

There is also a governance dimension that matters in regulated and audited environments. If you cannot demonstrate where the boundary between automated and human decision-making sits, and evidence that the boundary held, you have a control weakness — regardless of whether the agent has ever made a mistake.

At a glance: the four handoff triggers

Most implementations build the first and neglect the other three. Confidence thresholds are the easiest to reason about and the least sufficient on their own. An agent can be entirely confident about an action it has no business taking — paying an invoice above a delegated limit, changing a supplier's bank details, releasing an order to a customer on credit hold. That is an authority boundary, and confidence is irrelevant to it.

The consequence trigger is the one clients resist most, because it means deliberately escalating cases the agent would probably get right. That is the point. When the downside of a wrong action is large and asymmetric, "probably right" is not the standard.

What works, and what to be honest about

What works:

A named human owner per escalation type, not per queue. "Finance reviews the exceptions" is not ownership. A person, with a backup, and a defined response time. Where volume justifies it, a rota — but always resolving to an individual.

Escalations arriving with the agent's reasoning attached. The single largest determinant of resolution speed. What the agent was trying to do, what it found, what it considered, why it stopped, and the candidate resolutions ranked. An escalation that says "manual review required" wastes the work the agent already did.

A defined resolution path, not just a destination. Each escalation type needs an owner, a target time, an action set, and a rule for what happens when the target is missed. Without the last of those, the queue silently absorbs the failures.

Resolutions fed back as training signal. Every human resolution is either a case the agent could have handled with better rules, or a genuine judgement call that should always escalate. Categorising resolutions into those two buckets monthly is what makes an agent improve. Most deployments never do it.

Escalation volume as a monitored metric. Both directions matter. Rising volume means the agent is degrading or the input distribution has shifted. Falling volume is not automatically good — it can mean thresholds have been loosened past the point of safety.

What to be honest about:

Escalation design costs more than the matching logic. Frequently a majority of the build. Clients consistently underestimate this and it is where scope pressure lands first. Protecting it is the main thing that separates deployments that survive their second year.

Anomaly detection is genuinely hard. Detecting failure is straightforward; detecting that a case is unlike anything previously seen is not, and no current approach is reliable. The practical mitigation is conservative authority and consequence boundaries, which catch novel cases as a side effect.

Humans stop reading queues they do not trust. If a queue contains a high proportion of non-problems, reviewers begin clearing it mechanically, and the genuine exception in position forty gets cleared with the rest. Queue precision matters more than queue completeness.

Some escalations should go nowhere. Not every exception needs resolving. Some cases are best written off, tolerated or batched quarterly. Routing everything to a human treats all exceptions as equally worth human time, which they are not.

The boundary needs periodic renegotiation. As an agent accumulates evidence, some decisions can move from human to agent — but that should be a deliberate, documented, reviewable change, not threshold drift nobody signed off.

Decision framework: designing the handoff

Run in order. Stop at the first match.

1. Have you written down which decisions the agent may never make?
Start here, before building. Authority boundaries derive from delegation policy, not from technical capability, and they should be enforced in configuration so they cannot be crossed by a threshold change.

2. Does every escalation type have a named individual owner and a target resolution time?
If not, assign both. An escalation path ending in a shared mailbox or a team name is not a path.

3. Do escalations carry the agent's reasoning and candidate resolutions?
If not, fix the presentation before tuning the matching. This is usually the largest available improvement in total process time and it is routinely overlooked in favour of match rate.

4. Do you have a defined rule for a missed resolution target?
If not, define it: escalate to a second owner, alert a manager, or apply a default action. Without this, your escalation path has no floor.

5. Are you categorising resolutions into "should have been automated" and "correctly escalated"?
If not, start a monthly review. This is the mechanism by which the agent improves, and skipping it means paying for the same exceptions forever.

6. Are you monitoring escalation volume and precision in both directions?
Instrument both. Add an alert on any material change in either, in either direction.

7. All of the above in place and the queue still growing?
Your problem is upstream. A persistently growing queue means input quality is deteriorating or the agent's scope exceeds what its rules can support — neither is fixed by adding reviewers.

Indicative cost and effort

Assumes a single agent on one process. Multi-agent deployments require an additional layer deciding which agent owns an escalation, which adds materially. Get a quote for a scoped estimate.

Frequently asked questions

What is the right confidence threshold?
There is no general answer, because it depends on the cost asymmetry of your two error types. Where a wrong action is expensive and a delayed action is cheap — supplier payments, customer-facing communication — set it high. Where the reverse holds, lower it. Derive the number from consequences, not from the agent's performance statistics.

Can one agent escalate to another?
Yes, and it is often sensible — a document agent handing a pricing discrepancy to an order agent. But every chain must terminate at a human within a bounded number of steps, and the chain must be logged end to end. Circular escalation between agents is a real failure mode and needs an explicit guard.

How do we stop reviewers rubber-stamping the queue?
Keep precision high so the queue is mostly genuine, keep volume within actual capacity, make individual accountability visible, and audit a sample of resolutions. Rubber-stamping is a symptom of a queue that is too large or too noisy, not of inattentive people.

Does an auditor need to see this?
In audited environments, yes — expect questions about where the automated/human boundary sits, how it is enforced, and how you evidence that it held. Document the boundary, the enforcement mechanism and the audit trail before the question arrives.

What if the agent escalates almost everything at first?
That is the correct starting state. Begin conservative, gather evidence, and move the boundary deliberately. Deployments that start permissive and tighten after an incident lose organisational trust that is difficult to recover.

How quickly can the systems side of a handoff like this be built?
Faster than the design work above, typically. A certified partner such as Stacksync can put the real-time sync an escalation handoff depends on live within weeks. The slower part is deciding, as this article covers, exactly when an agent should stop and who it hands to — that's a policy decision, not an integration one.

Closing — Next steps

The instinct with agents is to measure how much they handle autonomously. The more useful measure is what happens to the remainder — because that is where the risk sits, where the learning comes from, and where the process either holds together or quietly falls apart.

A practical starting point on an agent already running: take a week of escalations and, for each, identify the owner, the time to resolution, and whether the resolution could have been a rule. If you cannot name an owner for every one, that is the finding, and it matters more than the agent's match rate.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

• NIST, AI Risk Management Framework — human oversight and accountability — https://www.nist.gov/itl/ai-risk-management-framework
• European Commission, EU AI Act — human oversight obligations — https://digital-strategy.ec.europa.eu
• European Data Protection Board, guidance on automated decision-making — https://www.edpb.europa.eu
• COSO, Internal Control — Integrated Framework — control design and delegation of authority — https://www.coso.org
• Atypical Tech engagement experience, mid-market agent deployments across Iberia
• Stacksync, real-time integration and sync platform blog — https://www.stacksync.com/blog