Human handover in conversational AI: context, permissions and fallback

Separate human conversation, action approval and AI delegation

Conversational AI includes voice and text experiences, but their handover paths need not be identical. Google's current overview provides product context, not a universal handover protocol or evidence that a particular organisation supports every channel. The architecture starts with the receiving system, the permitted action and the user's actual route to help. [1]

• Conversation handover: a person accepts responsibility for helping the user in the current or an explicitly agreed follow-up interaction.
• Action approval: an authorised person approves, edits or rejects a specific proposed operation while the conversation may remain with the AI.
• AI-to-AI delegation: control passes between automated components; this is not human oversight.

LiveKit's human-in-the-loop article describes a proposal, pause, review and execute-or-abort pattern. That is a useful distinction, not a reason to treat a media transfer as approval for a CRM write or to adopt the article's outcome figures and broad regulatory examples as facts about your workflow. An approval must bind to a specific action and current authority. [2]

Define permitted actions before choosing escalation triggers

Describe what the AI may read, propose and execute separately. Use an explicit tool/action allowlist with tenant, record, field, purpose and operation constraints, enforced outside the model. Validate arguments and current authorisation at execution time. A model's tool choice, a retrieved document or a caller's instruction cannot grant a capability.

Place required human approval before the relevant side effect. Bind approval to the action identity, permitted parameters, recipient, scope and expiry; edits may require a new approval. Recheck policy and permissions before committing. A human click or a remembered approval is not a permanent grant, and an already submitted operation may not be cancellable merely because escalation began.

• An explicit request for a person should enter the defined escalation path, rather than force the user through repeated AI clarification.
• Missing or conflicting evidence, repeated misunderstanding or an unsupported task can require escalation; do not guess facts to keep automation running.
• A proposed action outside the tool's permission boundary must be rejected or held for the appropriate authorised process.
• Organisation-defined risk, complaint or specialist-review policies can require a human; responsible legal/security owners must define any mandated process.
• Speech, language or channel limitations should have an accessible alternative appropriate to the actual service—not an invented promise of universal language support.

Uncertainty is not one universally calibrated confidence number. Evaluate the relevant evidence and failure modes for the deployed system. Inferred emotion or sentiment is not a verified fact about a person and should not be the sole basis for a consequential decision. Deterministic policy checks and a usable human-request route should not depend entirely on the model deciding to call an escalation tool.

Make the ownership transition explicit

In this conservative illustrative model, escalation requested stops new AI mutations while the permitted handover is prepared. Waiting means a request has been dispatched, not that a human is present. Human-owned requires authoritative acceptance by the intended permitted recipient for the current attempt and interaction generation. A model statement, queue acknowledgement or ringing phone is insufficient.

Separate media state from application authority. A person joining an audio room does not prove their permission to read a customer record or approve a transaction. Conversely, a logged-in reviewer approving one action does not mean they have taken over the conversation. Use the actual routing, identity and permission evidence required by the receiving system.

Use an attempt identifier and context generation to reject late acknowledgements after cancellation, timeout or a channel/session change. Enforce ownership consistently across concurrent workers and tool execution. The diagram describes intended policy; it does not implement distributed locking, authentication or transport.

Pass a minimal context package with provenance

Give the receiving person enough permitted information to understand the request and outstanding work. Do not send every transcript, customer field or credential by default. Define the receiving role, lawful/approved purpose, access, retention and disclosure boundaries with the responsible owners. If a larger record is legitimately needed, use an authorised retrieval path rather than copying it into every queue, prompt and log.

• Correlation: a permitted interaction reference, handover attempt and current context generation.
• Reason and channel: the trigger, actual current channel and any agreed continuation—not an assumed verified identity across channels.
• Verification state: what has and has not been established, by which approved process; caller ID or AI inference is not verification.
• A concise summary labelled as generated, user-stated, tool-derived or human-reviewed, with necessary freshness/source references and visible uncertainty.
• Pending actions: stable operation references and whether each is only proposed, approved, submitted, confirmed, failed or of unknown outcome.
• Recipient access requirements and a reference to the authoritative policy/ledger; these are not bearer credentials or instructions that override policy.

{
  "example": "synthetic-only",
  "interactionRef": "SYN-I1",
  "handoverRef": "SYN-H1",
  "generation": 1,
  "channel": "voice",
  "trigger": "human_requested",
  "verification": { "status": "not_established", "authority": "none" },
  "summary": {
    "text": "The person requests help from a human.",
    "provenance": "Invented teaching example, not a transcript",
    "review": "unverified"
  },
  "pendingActions": [
    { "operationRef": "SYN-OP1", "status": "unknown" }
  ]
}

Treat conversation text, retrieved material and generated summaries as data, not authoritative instructions. A malicious message saying that permission has been granted must not alter the tool gate or receiving person's role. Preserve the distinction between an unverified claim and a confirmed system result. Missing nonessential summary detail need not block connecting a person; missing internal security/correlation bindings must not be replaced by guessed customer data.

Keep pending business actions separate from conversation ownership

Before dispatch, identify actions already proposed or in flight. Pause what can safely be paused, but do not claim cancellation of an operation whose target may already have committed it. An unknown outcome remains unknown until the authorised integration establishes the result. Neither the human nor a resumed AI should repeat it blindly.

Use stable operation identity, target-supported deduplication/conditional behaviour where available, and controlled reconciliation. Ending a call or closing an escalation does not make an unresolved write successful or failed. Record who owns the remaining investigation and keep its access and retention rules distinct from the conversational UI.

LangGraph's current JavaScript interrupt guide documents checkpointing and resume using the same thread, with a durable checkpointer needed for production persistence. It also explains that the interrupted node restarts from its beginning on resume, so earlier code may run again. Even a post-approval side effect can repeat after a failure following commit. An interrupt is not a transaction, a permission check or an exactly-once guarantee. [6]

Check what the platform's handover signal actually means

The current Dialogflow CX v3 Fulfillment reference describes LiveAgentHandoff as indicating that a conversation should be handed to a live agent. It says Dialogflow uses the signal for measurement and leaves the rest to your handoff procedures; the metadata has no imposed structure. Your integration still needs routing, recipient acceptance, authority, payload validation and failure handling. This API-specific signal is not evidence of a completed human takeover across Google's products. [3]

LiveKit's current transfer documentation distinguishes cold forwarding via SIP REFER from agent-assisted warm transfer with context and failure handling. Its WarmTransferTask documentation describes a consultation room, dialing a human, hold audio and transfer tools. The current page distinguishes Node.js v1.5+ workflows naming from Python's beta.workflows path; its API examples should not be copied from an older blog without checking the selected release. This guide does not install or execute that SDK. [4][5]

The warm-transfer task's documented ringing timeout can return an error and resume the caller conversation. That framework behaviour does not automatically restore permission for the AI to perform previously blocked actions. Apply your policy when handling the result, explain actual availability and preserve unresolved work. A valid media workflow is still not proof of the receiving person's business-system role. [4]

This guide uses the full vendor overview and human-in-the-loop article alongside current API/task references and the LangGraph guide—not search snippets alone. Vendor claims about performance, full-context sharing, legal mandates or training feedback are not adopted as icommunix outcomes or default data-handling rules.

Design unavailable, timed-out and interrupted paths

Define a bounded wait and an honest status appropriate to the channel and organisation's actual staffing. If no human is available, say so. Offer a callback, asynchronous follow-up or another channel only when that route genuinely exists, is permitted and can capture the request appropriately. Do not promise a response time, continued queue position or a saved message without evidence.

An interrupted utterance is not necessarily cancellation of the handover. Distinguish a user asking to cancel, a dropped media connection, barge-in during speech and a genuine channel change. Invalidate stale authority where necessary and determine whether the user is still present before delivering further private information.

A move from voice to chat or asynchronous messaging needs a new authorised binding to the correct participant and permitted context. Re-evaluate verification, consent/disclosure, outstanding actions and the current recipient. Do not assume a phone number, link or old session token proves the same person controls the new channel.

After a human takes ownership, a participant leaving or a timeout must not silently re-enable autonomous action. Any return to AI handling needs an explicit, separately authorised transition under current policy and user expectations. The conservative model below intentionally has no automatic resume-to-AI path.

Run synthetic state and failure cases offline

Save the following JavaScript as handover-example.mjs and run node handover-example.mjs. It is a pure, serial teaching model with invented identifiers and no dependencies, network, speech, model, SDK, tools or credentials. The authorised and contextValid booleans stand in for separately verified server-side decisions; this code does not establish them. Every case starts with one artificially unknown business action to show that changing conversation state does not settle it.

const initial = () => ({ state: 'ASSISTED', generation: 1, attempt: '', aiMayMutate: true, pending: 'unknown', denied: false });
function step(s, e) {
  if (s.state === 'CLOSED') return s;
  if (e.type === 'unsafe-tool') return { ...s, denied: true };
  if (['cancel', 'disconnect', 'channel-change'].includes(e.type))
    return { ...s, state: 'SAFE_FALLBACK', generation: s.generation + 1, aiMayMutate: false };
  if (e.type === 'close')
    return { ...s, state: 'CLOSED', generation: s.generation + 1, aiMayMutate: false };
  if (s.state === 'ASSISTED' && e.type === 'request')
    return { ...s, state: 'REQUESTED', attempt: 'SYN-H1', aiMayMutate: false };
  if (s.state === 'REQUESTED' && e.type === 'dispatch')
    return e.contextValid === true ? { ...s, state: 'WAITING' }
      : { ...s, state: 'SAFE_FALLBACK', generation: s.generation + 1 };
  if (s.state === 'WAITING' && ['timeout', 'unavailable'].includes(e.type))
    return { ...s, state: 'SAFE_FALLBACK', generation: s.generation + 1 };
  if (s.state === 'WAITING' && e.type === 'accept' && e.authorised === true
      && e.attempt === s.attempt && e.generation === s.generation)
    return { ...s, state: 'HUMAN_OWNED', aiMayMutate: false };
  return s; // no automatic restoration of AI authority
}
const request = { type: 'request' };
const dispatch = { type: 'dispatch', contextValid: true };
const accept = { type: 'accept', authorised: true, attempt: 'SYN-H1', generation: 1 };
const waiting = [request, dispatch];
const cases = [
  ['human request', [request]],
  ['dispatch accepted by queue', waiting],
  ['invalid internal context', [request, { type: 'dispatch', contextValid: false }]],
  ['authorised current recipient', [...waiting, accept]],
  ['unauthorised acceptance', [...waiting, { ...accept, authorised: false }]],
  ['stale generation', [...waiting, { ...accept, generation: 0 }]],
  ['late acceptance after timeout', [...waiting, { type: 'timeout' }, accept]],
  ['no human available', [...waiting, { type: 'unavailable' }]],
  ['changed channel', [...waiting, { type: 'channel-change' }, accept]],
  ['disconnected user', [...waiting, { type: 'disconnect' }]],
  ['unsafe tool proposal', [{ type: 'unsafe-tool' }]],
  ['human leaves without reauthorisation', [...waiting, accept, { type: 'resume-ai' }]],
  ['duplicate escalation trigger', [...waiting, request]],
  ['close with unknown business action', [...waiting, accept, { type: 'close' }]]
];
console.log(JSON.stringify(cases.map(([name, events]) => ({ name, ...events.reduce(step, initial()) })), null, 2));

The test for an unsafe proposal sets a denial flag; it executes no tool. ASSISTED means only the separately approved scope remains available, not that the unsafe operation is allowed. The model uses fixed fixture identity and no elapsed-time calculation; it cannot prove authentication, concurrency, media transfer, durable recovery or language quality. There is no code path that resolves the unknown action or silently resumes AI mutations after human ownership.

Require evidence for the real workflow

• AI/integration review: confirm policy triggers, model/tool boundaries, user-request handling and the exact platform/SDK response contracts.
• Security review: test authenticated recipient acceptance, tenant/channel bindings, tool argument validation, malicious context and permission changes.
• Failure exercises: reproduce unavailable recipients, timeout, duplicate/late acknowledgements, interruption, unknown action outcomes and recovery under the chosen transport.
• Human experience: verify accessible status, cancellation and alternative help, and whether a reviewer can distinguish generated claims from confirmed facts.
• Data review: approve the minimal payload, retrieval permissions, retention and operational diagnostics; do not default to full transcripts or training reuse.
• Release evidence: assign ownership of unresolved actions and prove the policy boundary in an approved synthetic/sandbox environment before making production claims.

These checks reduce ambiguity in the design; they do not make AI infallible or guarantee that a human will always be available. Record the limitations and approved operating procedures rather than presenting escalation as a universal safety guarantee.

Resources

• Agentic and conversational AI capabilities →
• Explore CX solution areas →
• Discuss permitted actions and escalation requirements →