Debugging Dead Air on an AI Voice Agent: A Production Checklist

Dead air is the worst failure mode a voice agent has. The call connects, the caller hears the line open, and then nothing. No greeting, no beep, no error. The caller waits three or four seconds, says "hello?", waits again, and hangs up. Nothing in your dashboard flags it as a failure, because from the platform's point of view the call was answered and completed normally.

I run several live voice agents for one telecom client plus a pile of demo agents, and dead air has bitten me more than any other single problem. Every time, my first instinct was wrong. It always feels like a carrier issue, a codec mismatch, something deep in the SIP layer. It almost never is. In production, dead air is usually a boring config bug that happens to fail silently.

Here is the order I work through it now, fastest and most likely causes first.

Step 1: Confirm it is actually dead air

Before you debug anything, get precise about what the caller heard. There are three different failures that all get reported as "the bot didn't answer":

• Never answered. The call rang out or went to carrier voicemail. This is a routing problem, not an agent problem. Jump to phone forwarding for AI agents.
• Answered, total silence, call stayed up. The media path is open and the agent produced no audio. This is real dead air and the rest of this guide is about it.
• Answered, greeting played, then silence mid-conversation. Different animal. Usually a tool call hanging or a model timeout partway through a turn. Covered further down.

Pull the call record and look at the duration. A 30 to 60 second call with zero agent turns in the transcript is classic dead air. A 2 second call is a routing or answer failure.

Step 2: Check dynamic variables

This is the one that cost me the most time, so it goes first now.

On an agent configured to take dynamic variables at call time, an empty variables payload can produce total silence on answer. Not a fallback greeting, not an error message, silence. The agent's instructions reference variables that resolve to nothing, the prompt collapses into something the model can't act on, and the first turn never gets generated.

What makes this so nasty is that it looks exactly like a carrier fault. The call connects. The audio path is live. If you record the call you get a clean, silent file. Everything downstream of the platform is healthy and everything upstream is healthy, so you go hunting in the wrong place.

The tell: the agent works perfectly when you test it in the platform's own simulator, and fails only on real inbound calls. That is because the simulator hands the agent a populated variable set, and the live inbound path does not. See testing voice agents for why simulator-only testing hides a whole class of bugs like this.

The fix is to make the agent survive an empty payload. Give every dynamic variable a sane default in the config rather than assuming the caller context will always be there. If your greeting says "Thanks for calling {{business_name}}", the agent needs a fallback for when business_name arrives empty. On a multi-tenant setup where one agent serves several businesses, this is not optional. One tenant with a missing field will take down calls for that tenant only, which makes it look intermittent and random.

Read dynamic variables if you want the concept in isolation.

Step 3: Grep the instructions for unsubstituted tokens

Related failure, different mechanism. If your prompt still contains literal {{placeholder}} tokens that never got substituted, the prompt silently breaks. Sometimes you get dead air. Sometimes you get an agent that reads the token out loud, which is arguably worse in front of a customer.

This happens constantly when you build agents from a template. You clone a working agent for a new client, swap the fields you remember, and miss one buried three paragraphs into the instructions. Nothing validates it. The platform will happily accept a prompt full of tokens it has no values for.

I now do a literal text search for {{ in the deployed instructions of every agent before it goes live, and compare that list against the variables actually being passed. Anything in the prompt that is not in the payload is a live bug waiting for the right caller. It takes ten seconds and it has caught real problems more than once.

Step 4: Check for a fallback model

If the primary model has an outage or a slow region, and no fallback model is configured, you get dead air. The agent tries to generate the first turn, the request fails or hangs, and there is no second option to fall back to. Nobody gets an error, because as far as telephony is concerned the call is fine.

This one has a distinctive signature: it hits every agent on the account at once, it starts and stops sharply, and it correlates with the provider's status page. If three unrelated clients report silent calls in the same fifteen minute window, do not go looking at any one client's config.

Configure a fallback model on every production agent, on day one, even if you never expect to need it. It costs nothing when it isn't used. Model quality differences between your primary and your backup matter far less than the difference between a slightly worse answer and no answer at all.

Step 5: Look at the first tool call

If the greeting plays and then the agent goes quiet, suspect a tool. An agent that calls out to a webhook, CRM lookup, or knowledge base query at the start of the conversation will sit silent while it waits. If that endpoint is slow, or returns a shape the agent can't parse, or 500s, the turn can stall out entirely.

Two things fix most of this:

1. Timeouts on every tool call. Two to three seconds is a reasonable ceiling for anything on the critical path of a live conversation. A human waiting on a phone line perceives four seconds of silence as a dropped call.
2. Filler speech before the call. Tell the agent to say "let me pull that up" before invoking the tool. This converts a silent stall into a normal-sounding pause, and it buys you real seconds.

Check the tool call results in your transcript view, not just the transcript text. The text will show a clean handoff. The tool results will show the 500.

Step 6: Only now, look at telephony

If the config is clean, the fallback is set, and no tool is hanging, then look at the phone layer. What I check, in order:

• Is the number pointed at the agent, or at an old test agent you forgot about? Cloned setups love to point at the wrong target.
• Is there a carrier-side feature in the path, like an auto-attendant or a hunt group, that is answering the call before your platform sees it? This is common with business phone systems. Details in phone forwarding for AI agents.
• One-way audio. If the agent's transcript shows it heard nothing from the caller either, you may have a genuine media path problem. Two-way silence points at RTP. One-way silence (agent hears you, you hear nothing) points at the agent.

That ordering matters. Telephony problems are real but rare, and they take an hour to investigate. Config problems are common and take a minute. Do the cheap checks first.

Build a detector, not just a fix

Dead air does not page anyone. Nobody gets an alert. You find out when the client calls you, and by then you have lost a week of leads.

So build the detector. The signal is simple: a call that connected, lasted more than a few seconds, and produced zero agent turns in the transcript. Query that daily across every agent you run. If the number is not zero, something is broken right now.

I also test-call every production agent from my own cell on a schedule. Not the simulator, not a SIP client, an actual phone on an actual carrier. It is the only test that exercises the whole path the way a customer does.

FAQ

Why does my agent work in the simulator but go silent on real calls?

Almost always because the simulator populates context the live call does not. Simulators typically can't inject system variables like caller ID, and they hand the agent a fully-formed variable payload. Your live inbound path may hand it an empty one, which is the number one cause of total silence on answer. Test with real calls before every rollout.

Is dead air ever actually a carrier problem?

Occasionally, yes, but it is far down the list. In my experience the config causes (empty dynamic variables, unsubstituted prompt tokens, no fallback model, a hanging tool call) account for the large majority. Work through those before you open a ticket with a carrier, because a carrier investigation will cost you a day and usually come back clean.

How long can an AI voice agent be silent before it matters?

About two seconds. Past three, callers start saying "hello?". Past five, a meaningful share hang up. Design for a sub-second first turn and use filler speech to cover anything that will take longer than about two seconds.

What should the agent do if a tool call fails?

Say something. An explicit "I'm having trouble pulling that up, let me take a message" is vastly better than silence, and it is a one-line addition to the instructions. Also give the agent an escape hatch to a human, which is covered in call transfer flows.

Does adding a fallback model hurt answer quality?

Rarely enough to matter. The fallback only fires when the primary is unavailable, so the real comparison is not "best model versus second-best model", it is "second-best model versus dead air". Set it and forget it.