AI service operations guide

When should an AI agent hand over to a human?

Handover is part of a reliable service, not a failed conversation. Define when the agent stops, who takes responsibility and what context travels with the request.

Assess the handover Jump to handover triggers

Published 3 September 2026 · 8 minute read

The short answer

An AI agent should hand over when a person requests it, the request exceeds its approved scope, available evidence is insufficient, a dependency fails repeatedly or a decision requires human judgement or authority. The handover should create an owned work item, preserve relevant context and tell the user what happens next.

This guide focuses on customer-service and internal-request operations. It does not define specialist emergency, clinical or legal triage. Those services need a separately designed escalation process with the appropriate accountable experts.

Use observable handover triggers

Trigger	Agent response	Receiving team needs
User asks for a person	Stop trying to retain the conversation and offer the handover	The user's goal and preferred contact route
Missing or conflicting evidence	Explain the gap without inventing a resolution	Sources checked and the unresolved question
Identity or permission is unresolved	Withhold protected information or action	A safe verification path, not a request to bypass controls
Business exception	Describe the request without making an unauthorised commitment	The relevant rule and the decision required
Repeated failure or unclear system outcome	Stop retries that could duplicate the action	Operation reference, last known state and reconciliation task
Material harm or security concern	Contain the action and follow the approved incident route	The appropriate restricted evidence and incident owner

Do not treat an agent's self-reported confidence as proof that an answer is safe. Use source availability, successful verification, explicit policy rules and tested failure limits. A confident response can still be outside the agent's authority.

Separate an approval checkpoint from a transfer of responsibility

An approval checkpoint asks an authorised reviewer to decide whether one specific proposed action may proceed. Handover asks a person to take responsibility for the request itself. A workflow may need both, but an approval button does not replace a service queue.

OWASP's agent-security guidance recommends human oversight appropriate to consequential actions. Apply that principle through explicit application states rather than a prompt that merely asks the model to be cautious.

Handover requested→Queued→Owner accepts→Human handling→Resolved or returned

Once a person owns the conversation, prevent automated replies from competing with them. Returning control to the agent should be deliberate and include updated context. If the customer replies while the transfer is pending, attach that message to the same work item.

Give the person a useful handover packet

Goal: what the user is trying to achieve, in their own terms where practical.
Verified facts: identifiers, source references and relevant status, with freshness recorded.
Uncertainty: missing information, conflicting answers and unverified inferences.
Actions: what was attempted, what succeeded and what remains pending.
Reason: the specific escalation trigger and the decision needed.
Ownership: receiving queue, urgency rule and the person who accepts it.
Customer expectation: what the user was told about the next step.

Use a short operational summary with access to relevant evidence, not an indiscriminate transcript dump. Let the reviewer distinguish a customer's claim from a value confirmed by the system. Keep restricted information visible only to staff authorised to handle it.

For example, “Customer says the booking is confirmed” is not equivalent to “Booking service returned confirmed reference ABC.” That distinction prevents a summarisation error becoming a business commitment.

Design for unavailable staff and channel limits

If the team is offline, state that plainly. Confirm that the request has been recorded only after the queue accepts it. Provide an alternative support route when appropriate, and use a response expectation the actual service team has agreed to support.

For WhatsApp, the Business Messaging Policy requires clear escalation paths from automation. Its customer-service-window and template rules also affect later replies. A delayed human response must still follow the channel's current messaging rules.

Define queue overflow, unassigned work and missed ownership alerts. If the normal team cannot accept a case, route it to a named backup rather than leaving it in an invisible backlog. Do not label a queued request as a live transfer.

A hypothetical service-change request

A customer asks to change an order after dispatch. The agent can retrieve the permitted order state but cannot decide whether the company should make an exception. It records the requested change and routes the case to the operations team.

A suitable message might be: “This order is already marked as dispatched, so I cannot confirm the change here. I have sent your request and order reference to our operations team for review. The current order remains unchanged.” Use that wording only after the handover is actually recorded and the unchanged state is verified.

If the handover service fails, say the transfer was not confirmed and provide the approved alternative. If the agent previously attempted a change, include that attempt in the case so the human does not unknowingly repeat it. See the integration guide for handling uncertain write outcomes.

Measure appropriate handover, not maximum containment

Track the reason for transfer, queue acceptance, time to ownership, resolution and repeat contact. Sample cases to find missed escalations and unnecessary transfers. Keep customer abandonment separate from successful self-service.

A lower handover rate is not an improvement if customers cannot reach a person or the agent makes unauthorised decisions. Review queue workload alongside answer quality and business outcomes. Staff should be able to flag missing context and feed corrections back to the maintained knowledge source.

Test the uncomfortable cases before launch

A user explicitly requests a person before answering the agent's questions.
The user disputes an answer or corrects an important fact.
A tool fails after a possible write, leaving the outcome unknown.
The receiving team is offline or no one accepts ownership.
The user sends another message while handover is pending.
A reviewer rejects the proposed action and returns the case with instructions.
The same case is retried after a restart without creating duplicate work.

Record the expected customer message, queue state, allowed next action and owner for each test. Pair this operating design with server-side access controls and the broader AI agent service workflow.

Sources

Sources and review date

Primary sources checked on 3 September 2026. The queue design and examples above are recommended implementation patterns, not measured client results.