How to Fix a VAPI Voice Agent That Goes Silent After an IVR Transfer

ussama assad — Tue, 21 Jul 2026 14:56:59 +0000

If you're running a VAPI voice agent in production and it goes dead silent right after navigating an IVR and getting transferred to a live person — the agent can't hear the human, even though everything worked up to the transfer — this is almost always a transport-level problem, not a prompt or config mistake. Here's how to find it and fix it.

The symptom

The agent dials out, navigates the phone menu correctly with DTMF tones, gets bridged to a live operator — and then goes silent. You can hear the agent fine. The agent cannot hear the person. On the telephony provider's own recording (Twilio, etc.) the human's audio is clear and complete. Inside VAPI, it's just fragments or nothing.

What's actually happening

The moment the far end bridges the call to a live person, the audio transport reconnects. Right after that reconnect, inbound audio starts arriving in broken chunks — large gaps where it should be a smooth stream every few milliseconds. The transcriber gets nothing usable, so the agent behaves as if no one is speaking. The audio reaches the telephony layer fine and then breaks inside the pipeline after the reconnect. That's the core fault: it's a transport reconnect issue at the hand-off, not the agent "ignoring" anyone.

How to diagnose it (don't guess — confirm)

Pull the failing call log and read it line by line. Look for the transport reconnect event right at the transfer point, and check whether inbound audio timestamps go irregular immediately after it.
Rebuild the same pattern on a rig you control — an agent that navigates a menu, gets bridged to a live person, then has to converse. Run it once over the transport you're using now, and once over a different transport path.
Compare. If the handoff breaks on one transport and survives on the other, you've isolated the fault to the transport leg — not VAPI as a whole, and not your prompt.

How to fix it

Test the same failing flow with the near-end number on a VAPI-native path (or a clean SIP trunk) instead of an imported number. If the agent can hear the person after transfer on the native path, you've found your working route.
On the current setup, rule out audio processing on that leg — turn background noise filtering fully off and run it once. Broken inbound audio sometimes sits right on that part of the pipeline.
If it's confirmed transport-level, raise it with your platform with both call IDs (the failing one and your clean repro) and a one-line description: after a far-end bridge, the transport reconnects and inbound audio breaks on this transport path but not on the native one. That's a clean, reproducible report and gets a real fix.

The takeaway

When a voice agent goes silent specifically after a transfer, stop tuning the prompt. The prompt is fine. Isolate whether it happens on every transport or just the one you're on — that single comparison tells you where the fix actually lives. Most "the agent stopped responding" incidents in production are transport reconnects, not intelligence failures.

FAQ

Why does my VAPI agent go silent after an IVR transfer?
Usually the audio transport reconnects when the call bridges to a live person, and inbound audio arrives fragmented after the reconnect — so the transcriber gets nothing and the agent appears deaf.

Is this a prompt problem?
No. If the agent worked up to the transfer, the prompt is fine. This is a transport-level audio issue at the hand-off.

How do I confirm it's the transport and not VAPI itself?
Rebuild the same transfer flow on a rig you control and run it over two different transport paths. If it breaks on one and survives on the other, the transport leg is the fault.

Who fixes production VAPI voice agent problems like this?
Engineers who can read call logs at the transport level and build controlled reproductions — not just follow the quickstart. This kind of production voice-agent debugging is what I do — you can reach me at https://www.linkedin.com/in/assadua/