Voice agent handover to a human and looping failures

A voice agent gets stuck in a loop when it keeps asking the same question or repeating the same answer because nothing in its design lets the call move on. The usual cure is a clear way out to a person. A good handover happens when the caller asks once, the agent says yes, and the human picks up already knowing why they called.

Key facts

• Retell's docs describe a cold transfer as "The call is transferred to a destination number and that's it" (Retell).
• Vapi says the ended reason assistant-forwarded-call "does not prove that the destination rang, answered, or spoke with the caller" (Vapi).
• Twilio says that if a REFER transfer fails, the SIP endpoint will typically resume the original call (Twilio).
• Deepgram says a warm handoff payload carries "verified identity, intent, entities" (Deepgram).
• The CFPB describes chatbot "doom loops" as repetitive replies without an offramp to a human (CFPB).

This guide covers what a good handover looks like, how it goes wrong, and how to test it.

What does a good handover to a human look like?

The caller says "can I talk to a person?" one time. The agent does not argue, quiz them or offer a menu first. It says what is happening, such as "I'll put you through to the bookings team", and then it does it.

On the other end, the human sees who the caller is, why they rang and what the agent has already done. Deepgram's write-up on handoffs says the payload that keeps a transfer warm carries "verified identity, intent, entities" along with a short summary. The caller never repeats a name, a reference or the story so far.

Two terms matter here. In a cold transfer the agent hands the call over and steps out, and Retell's docs put it as "The call is transferred to a destination number and that's it". In a warm transfer the agent stays involved after the destination answers, for example to check a live person picked up and to introduce the caller. Neither is better in every case. Warm costs more to build and gives the human a briefing, while cold is simpler and has fewer moving parts.

How do voice agent handovers fail?

Most of these are quiet. The call just ends badly, and nothing in a dashboard looks red.

• The agent will not let go. The caller asks for a person and gets "I can help with that" instead. The agent may treat the request as one more intent to handle. The US consumer finance regulator describes this pattern in chatbots as "continuous loops of repetitive, unhelpful jargon or legalese without an offramp to a human", and calls them "doom loops". Most of its examples are text chat, but it also covers a bank assistant that mainly responds to voice prompts, and the shape is the same on a phone.
• The agent says it will transfer and does not. The words on the call and the action that moves the call are separate things. A test that only reads the transcript will pass this failure, so check that the transfer really started.
• The destination does not answer. The line is busy, rings out, goes to voicemail or is closed for the day. Vapi's debugging page says the ended reason assistant-forwarded-call "does not prove that the destination rang, answered, or spoke with the caller". So a forwarded label on its own does not tell you what the caller heard.
• The platform cannot tell what happened. Twilio's docs for the REFER verb say a transfer replaces the Twilio leg with a new call, and that if it fails the SIP endpoint "will typically resume the original call with your Twilio app". So your application has to be ready to speak to the caller again.
• The set-up is wrong for the line. Retell's docs say that when caller ID override is not supported by the provider, "the transfer would fail". That is a configuration problem found only by placing a real call.
• Context is dropped. Deepgram points out that everything the caller said "travels nowhere unless your application persists it". The human starts from zero and the caller starts again.
• No safe fallback. Retell's flow builder has an edge that fires when a transfer fails, and it is only useful if someone connects it to something. LiveKit's warm transfer docs say the agent can "return to the original caller, explain the situation" and try another transfer or end the call. If your set-up has no such path, the caller hears silence or hold music.

Why do voice agents get stuck in loops?

A loop is not always the model being dim. Common causes are a lookup that returns nothing and a prompt that reads "ask for the policy number" with no rule for the third failed attempt. A caller who is not understood keeps being asked to repeat, and the agent keeps asking.

There is also the loop between two tools or two agents, where one hands work to the other and gets it handed straight back. In a test it shows up as a call that runs long with no progress and no end. A loop that never ends also keeps costing money, so find out what limit your platform puts on call length.

Repeating after a failed lookup is the most common version. The caller gives a surname, the search fails, and the agent asks for the surname again in the same words. A better agent changes approach after one miss, for example by asking for a different detail, offering to spell it out, or moving to a person.

What to test

Run these over a real phone line where you can, since a transfer needs a real destination to ring. RingTru's hand-off tests work this way.

• Ask for a person in the first sentence. Ask for one after a failed lookup. Ask for one while upset, and ask politely and then flatly three times in a row.
• Ask in different ways: "agent", "someone real", "your manager", "I want to speak to a human being".
• Send the transfer to a line that is busy, rings out, answers late, goes to voicemail, picks up and hangs up, and one that is closed. Hear what the caller hears each time.
• Make the lookup fail on purpose, with an empty result and a timeout, and listen for the same question twice.
• Interrupt just before the transfer starts, then let the call continue to see if it stalls.
• Give your name, reason and a reference before asking for a person. Then check what the human side was told.
• Leave a call running with a caller who says nothing, to see when and how the agent ends it.

What to measure

• Asks before transfer. How many times the caller had to ask. The target is once.
• Turns before transfer. How many exchanges pass between the request and the transfer starting. Fewer is better.
• Repeated questions. Count any question the agent asks again after the caller already answered it, or after a lookup failed.
• Transfer success. Did a human actually answer and speak to the caller? Do not trust a platform label alone, since a log that says forwarded may not mean answered. Check the carrier's call record if you can.
• Context arrival. Did the human receive the name, the reason and what was already tried?
• Fallback quality. When the transfer fails, was the caller told, offered a callback or another route, and not left in silence?
• Call end. In a loop, who ended the call, and when?

Each of these comes from one real call, so run each scenario more than once. The same prompt can pass on Monday and fail on Tuesday. For how many runs to make, see the call tester guide. Related: how voice agents handle interruptions, identity checks and the wider guide to testing a voice agent.

Platform details change often. Everything here was checked against the linked pages on 27 October 2026. If you would like these calls placed for you, RingTru runs them with simulated callers (see hand-offs).