Voice Agent Human Handoff: What Happens on the Call When the Agent Lets Go
Voice agent human handoff mechanics: the handoff as a tool that ends the agent's session, barge-in during the transfer announcement, what the caller hears on hold and on failure, a context payload schema, and a real-call test checklist.
- A voice agent handoff is a tool call that ends the agent's own turn, so the design questions are what the caller hears during the transfer, what travels to the human, and what happens when nobody answers.
- The customer-support-agents reference says a request for a human should be honored immediately, which on a call means the transfer announcement itself must never be talked over or restarted by caller speech.
- As the author's inference, a handoff needs three audible failure paths: transfer rejected, no answer within a timeout, and line dropped, each with a spoken sentence and a fallback such as a callback or voicemail.
- The voice-realtime-agents reference records that Amazon Nova Sonic integrates with Amazon Connect and telephony providers Vonage and Twilio, which is integration support only and says nothing about transferring a call.
- The corpus does not cover call transfer, SIP REFER or contact-centre routing, so any transfer mechanism must be taken from the telephony vendor's documentation and proven with real test calls.
A voice agent handoff is the moment the agent stops being the caller's counterpart and a person takes over on the same live call, and its design is mostly about what the caller hears and what the human receives. This article covers the voice-only mechanics inside the voice AI agent in production cluster. Trigger design, warm versus cold handoff and deflection are in that pillar and in the AI customer support agents reference, and are not repeated here.
Labels used below: "corpus" means a claim from a named reference, "inference" means the author's reasoning with no published source. Most of this article is inference, because the corpus says very little about phone transfers.
Why is a handoff a tool that ends the session?
A handoff is a tool call whose side effect is that the agent leaves the call, which makes it a tool the agent is least able to retry, observe the result of, or apologize after. The classes of tool are covered in function calling in a voice agent; this section covers only the exit. Everything here is inference.
- The call is the last action. Once the transfer starts, the agent may never see the outcome, so the outcome has to be reported back by the telephony layer, or treated as unknown.
- Order matters. Announce, then act, then release. If the tool runs before the announcement finishes, the caller may hear half a sentence and then a ringing line.
- One shot. A repeated handoff call can create two transfers. Give the call a unique key per conversation, as with any side-effecting tool.
- State before exit. Write the context payload and the trigger category to your log before the transfer starts, not after, because the session may end the moment the transfer succeeds.
What should happen to barge-in during the transfer announcement?
The transfer announcement should be protected from barge-in, with one exception: a caller who says they do not want to be transferred must be able to stop it. Both halves are inference; the corpus describes barge-in generally but gives nothing specific to announcements.
The risk is a cascading restart. A caller who says "okay" or "hello?" during "I'm transferring you now" can interrupt the agent, trigger a new model turn, and produce a second, different answer while the transfer is already under way. Two defences follow:
- Mark the announcement as non-interruptible by acknowledgements, and listen only for explicit refusals.
- Once the handoff tool has fired, ignore further model turns, so that stray speech cannot start a second action.
Test both with recorded audio, using the method in how to test turn detection and barge-in.
What does the caller hear during the transfer?
The caller should hear a single announcement, then either a ringing or hold signal or a human greeting, and never open silence. That is inference. The corpus does not describe hold music, ringback or telephony audio, so no vendor claim is made here.
| Moment | What the caller should hear | Inference-based reason |
|---|---|---|
| Decision to transfer | One sentence: transferring, why, what happens next | A caller cannot scroll back, so say it once and clearly |
| Connecting | Ringback or a short hold message | Silence reads as a dropped call |
| Human answers | A human greeting that references the reason | Avoids the caller restating the problem |
| Nobody answers | A spoken apology and a fallback offer | See next section |
The customer-support-agents reference says an explicit request for a human should be honored immediately ("do not require a customer to repeat the request or argue with a deflection loop"). On a call, that means the agent's next utterance after the request is the transfer announcement, not another clarifying question.
What if the transfer fails or nobody answers?
A transfer needs a defined spoken fallback for every failure, because a caller who is told "please hold" and then hears nothing has been worse served than one who was never transferred. The failure list and the fallbacks are inference.
| Failure | Spoken response | Fallback |
|---|---|---|
| Transfer rejected or target unavailable | Say the person is not available | Offer a callback or return to the agent |
| No answer within timeout | Apologize, name the timeout was reached | Voicemail or a scheduled callback |
| Line drops mid-transfer | Nothing can be said | Log it and call back if a number is on file |
| Caller hangs up while on hold | Nothing can be said | Log as abandoned, with the payload attached |
Choose the no-answer timeout deliberately and record it. The corpus gives no safe figure, so pick one with your operations team and revisit it from your own abandonment logs. Return the caller to the agent only if the agent can do something useful, such as take a callback number; otherwise a loop back into the same queue repeats the original failure.
What context payload should reach the human?
The payload should carry the four things the customer-support-agents reference names for a warm handoff, which are the transcript, structured data already collected, in-progress tool state and the escalation reason, plus call metadata that only voice has. The reference states those four categories (corpus); the field names below are the author's inference, not a standard.
{
"call_id": "c_8f2a",
"handoff_key": "c_8f2a:handoff:1",
"reason": "caller_requested_human",
"trigger_category": "explicit_request",
"summary": "Wants to change delivery address on order 1042; identity not yet verified.",
"collected": { "order_id": "1042", "intent": "change_address" },
"tool_state": [{ "tool": "lookup_order", "status": "done" }, { "tool": "update_address", "status": "not_run" }],
"transcript_ref": "c_8f2a/transcript",
"caller_number_known": true,
"transcript_confidence": "asr_unverified",
"interrupted_turns": 2
}
The last three fields are the voice-specific ones, and all are inference. A spoken transcript is machine-transcribed, so the human should be told it is unverified. Whether the caller's number was known decides if a callback is possible. A count of interrupted turns hints at frustration, though the pillar's own inference is that a cascaded pipeline may discard tone. Send a short summary rather than only a transcript link, since a human cannot read a full transcript while greeting the caller.
Which integrations does the corpus actually support?
The corpus supports one fact: the voice-realtime-agents reference records that Amazon Nova Sonic "integrates with Amazon Connect and telephony providers (Vonage, Twilio)". That was web-verified on 2026-07-09 and not re-verified on 2026-09-28. It says the model connects to those platforms. It does not say the model can transfer a call to a person on them, and this article does not claim it. For the transport side, see voice agent transport: WebRTC vs WebSocket, and where SIP fits.
What does the corpus not say about handoff?
The corpus is silent on the transfer itself: it has no entry on call transfer mechanics, SIP REFER, bridging versus redirecting a call, contact-centre queues, agent availability, hold music or voicemail. It also gives no timeout, no per-vendor handoff event, and no data on how callers react to announcements.
- Not covered: how a vendor hands a live call to a person, or whether it can.
- Not covered: what happens to the model session after the transfer.
- Not covered: any measured abandonment or satisfaction figure for voice handoffs.
Treat those as questions for the telephony vendor, and answer them by test, not assumption.
How do you test a handoff on real calls?
Test a handoff by placing real calls through the real telephony path, because a simulated session cannot reveal what the caller hears. The checklist is inference.
- Happy path. Request a human, hear one announcement, reach a person, and confirm the payload is on their screen before they speak.
- Barge-in on the announcement. Say "okay" and "hello?" during it, and confirm no second model turn or second transfer starts.
- Refusal. Say "no, don't transfer me" during the announcement and confirm it stops.
- No answer. Let the target ring out and confirm the spoken fallback and callback or voicemail path.
- Rejected transfer. Point the handoff at an unavailable target and confirm the spoken failure.
- Mid-transfer hang-up. Drop the call and confirm the log still holds the payload and trigger category.
- Duplicate protection. Trigger the tool twice and confirm only one transfer occurs.
- Latency. Time the gap between the announcement ending and the line ringing, using the legs in the voice agent latency budget.
What does ChangeGamer know first-hand about voice handoff?
Nothing: as of October 2026 ChangeGamer runs no voice agent and has handled no calls, so there is no measured result here. The warm-handoff categories come from the customer-support-agents reference, the one vendor line from voice-realtime-agents, and the rest is labelled inference. See the voice agents cluster for the remaining decisions, and how a voice agent handles callers who speak another language for transfers triggered by an unsupported language.
Frequently asked questions
- How does a voice AI agent transfer a call to a human?
- The corpus does not describe the transfer mechanism. As the author's inference, the agent calls a handoff tool, announces the transfer, and the telephony layer connects a human. The mechanism belongs to the telephony vendor's documentation, so verify it with real test calls before launch.
- What should a voice agent say while transferring a caller?
- A voice agent should say that it is transferring the caller, why, and what happens if nobody answers, in one short sentence. As the author's inference, the announcement must be protected from barge-in, and silence during the transfer should be avoided or explained.
- What if no human answers the transferred call?
- The corpus does not specify this case. As the author's inference, set a no-answer timeout, return the caller to the agent with a spoken explanation, and offer a callback or voicemail rather than leaving the line in silence or looping the caller back into the same queue.
- What context should a voice agent pass to the human agent?
- The customer-support-agents reference says a warm handoff passes the transcript, structured data already collected, in-progress tool state and the escalation reason. The field-level schema in this article is the author's inference, not a corpus standard.
This guide is free and stays free. The reference corpus behind it — machine-readable contracts, verified primary sources, continuously refreshed — is the paid product: a €5 starter key unlocks every premium reference for one agent via API; a €25 corpus license delivers the full corpus as RAG / fine-tuning data with an explicit AI-use grant; the €150 enterprise license adds commercial redistribution rights.