How to test an AI voice agent: check the call, not the transcript

Test an AI voice agent by comparing four records of every call: what the agent said, what its tools did, what the caller heard and what happened on the line.

Most of the defects we've fixed on live calls read perfectly well in the transcript. They only show up where two of those records disagree, which is why a test plan built on transcripts and an LLM judge waves them through.

Below are six failures from Callaro's own production calls, the record that exposed each one, and the test that now catches it. After that: how we test for failures that happen on one call in ten, and a pre-launch plan you can copy.

The transcript is the agent's intention, not the call

A transcript records the text the model produced. Between that text and the caller's ear sit speech synthesis, an outbound audio queue, a carrier that may acknowledge each audio segment, an echo gate, and a hangup that can arrive early. Any of them can lose what the transcript says happened.

So we test against four records, side by side:

• Words. The transcript of both sides, turn by turn.
• Actions. Every tool call with its arguments, its result and its status: started, completed or failed.
• Audio. The recording, ideally with agent and caller on separate tracks.
• Line. Timing: first audio, silences, interruptions, when the hangup came and which side sent it.

In Callaro, a call's detail page puts these next to each other: transcript, recording, per-turn latency, a tool-calls tab that counts successes and failures, interruptions, and the delivery log for every webhook. If your platform gives you only a transcript and a summary, most of what follows can't be tested.

Six failures that read fine on paper

1. The goodbye the caller never heard

Records that disagreed: words and audio.

When the agent decided a call was over, the line hung up a fraction of a second after the goodbye was synthesised, before it had played. The transcript showed the full closing line. The recording ended mid-sentence, with a second or more of the goodbye missing.

It happened on every telephony path we run except one. Months earlier, a change had replaced a fixed wait with one that read only that path's audio buffer. The fix now waits until the carrier's buffered audio has drained and the expected playback time has passed, with a cap so a stuck figure can't hold the line open.

The test: end at least five calls normally on every carrier you run, and listen to the last two seconds of each recording. A fix for one telephony path is a change to all of them.

2. The reply stuck in a queue

Records that disagreed: words and line.

One carrier acknowledges each audio segment it plays. Our sender paused whenever too much unacknowledged audio was outstanding, and that pause had no timeout. A single lost acknowledgement, on a filler clip just over a second long, froze every segment after it. The transcript showed the agent answering. The caller heard silence until they gave up and hung up.

The sender now tracks when everything it has sent should have finished playing. Once that moment is a couple of seconds overdue, it releases the queue and logs a warning naming the unacknowledged segment. Each of those warnings is a stall that didn't happen.

The test: in a carrier simulator, drop one acknowledgement mid-reply. On live calls, alert on any turn where the agent generated a reply and no audio left within a few seconds.

3. The tool call read aloud

Records that disagreed: words and actions.

On one call, the model wrote its booking and lead-saving calls as text inside its reply instead of as structured tool calls. Text-to-speech read the markup to the caller, and neither tool ran. Earlier in the same call, the same tools had run normally.

Callaro's runtime now strips that markup before it reaches speech. An unclosed fragment is held until it closes, and dropped if it never does. The markup is also kept out of the conversation history, so the model can't copy its own leak on later turns, and out of stored transcripts and webhooks.

We also added an opt-in, stricter function-calling mode, and probed every model in our registry with it (tool results, a 14-tool schema, cached context) before allowing it.

Stripping the markup fixes what the caller hears, not the missing action. A booking only exists once the model makes a real tool call, which is why the test checks actions rather than words.

The test: flag any reply containing tool-like syntax, and any turn where the agent claims an action ("I've booked that", "I've changed the time") with no matching tool call. The calendar side of this, phantom and duplicate bookings, is covered in our appointment scheduling playbook.

4. The goodbye on repeat

Records that disagreed: words and line.

After the caller said "Thank you", the model streamed the same short farewell over and over for 24 seconds, until the process was stopped. There was no turn-complete event and no hangup. Nothing in the runtime limited how long a single reply could be.

We never proved why it looped. A direct reproduction with an approximate prompt, five trials per setting, didn't loop once. So we bounded it instead. A guard now cuts a streamed reply when its tail is the same phrase repeated back to back, or when it passes a length cap. It ends the cut on a whole sentence and keeps a single copy in the history.

The test: feed the guard pathological streams in unit tests, and alert on every cut in production. When you can't find the cause of a failure, ship the bound and keep looking.

5. The call that wouldn't end

Records that disagreed: the line, against everyone's words.

On one call, both sides said goodbye and the line stayed open for another minute, until the caller hung up. On another, the caller's "No, thank you" reached the agent as "Now thank." The model answered with a Hindi-English goodbye as plain text and never called its end-call tool.

The only backstop on that call was an idle wrap-up that checked for a goodbye against a phrase list, and the list recognised neither line. On a third call, a caller's "thank you" written in Devanagari wasn't on the list either, so the gate blocked the model's own decision to hang up.

The rule now: the model decides whether the call is over (on a full-duplex model, its own closing detector does). Code decides only when the hangup may happen, using timing and call state: the call is old enough, the agent has spoken, the caller isn't talking, and the caller has heard a reply. No gate reads anyone's words.

The test: measure seconds from the last farewell to hangup, and which side hung up. Feed your closing logic speech-to-text-mangled goodbyes in every language you serve, plus "No, I'm good" and "That's all I needed".

6. The first word of an interruption

Records that disagreed: audio and words.

When callers interrupted, their first words went missing. The echo gate believed the agent was still playing, because the playback estimate said so, although no audio had gone out for a moment. It silenced the caller's opening syllables as echo. The transcript read like a caller who had started mid-sentence.

The gate now checks whether agent audio actually went out. While the caller is known to be speaking, it softens suspect audio instead of silencing it, and new agent speech is held while a confirmed interruption is handled.

No echo gate is perfect: an aggressive echo canceller upstream can still swallow a first word, so this is one to keep testing. The signal processing behind this is in how voice AI survives noisy phone audio.

The test: interrupt the agent ten times with real phrases in each language you serve. The first word should survive in the final transcript at least eight times out of ten, and false caller turns caused by echo shouldn't rise.

Replay real calls, ten times each

A failure that happens on one call in ten won't show up in a single test run, and one clean run proves nothing. For those we replay. We rebuild the conversation from a real call's trace (every turn's text, every tool call with its real arguments and result), stub the tools so nothing executes, then run the risky turn ten times and count.

Two examples of what that catches:

• A vendor default. Google recommends keeping Gemini 3 models at temperature 1.0 and warns that lower values may cause looping. We moved our Gemini 3 defaults to 1.0, and a call at the new setting soon went silent after background tools. Replayed at both settings, silent endings came up in about 30% of runs at 1.0 against 8% at 0.1. We reverted the same day.
• A fix that worked. For the duplicate-booking defect in the scheduling playbook linked above, the replayed "thank you" turn re-ran the booking 10 times out of 10 before the fix, and 0 out of 10 after it.

Both temperature risks are real. The replay told us which one our pipeline actually hits, and the repetition guard from failure 4 bounds the other.

Watch for two traps. First, make sure the replay uses the exact production prompt. Our first loop replays ran with a system prompt about 6,000 characters shorter than production, because platform-level defaults hadn't loaded, and we threw those runs away. Compare length and a hash before you trust a result. Second, ten runs compare two variants; they don't give you a production rate.

The pre-launch test plan

Run this before an agent takes real traffic, and again after any model or prompt change. Model swaps count: our notes on the Gemini Live retirement show how a one-line swap can change defaults underneath you. If this is your first agent, start with the basic scenario matrix in our setup guide; the steps below go on top of it.

1. Call through the real phone path. Browser calls skip the carrier, the codec and the echo path. From a Callaro agent's page you can place a test call through your own telephony. Share links, which let a colleague try the agent from a browser a limited number of times, are fine for reviewing the script but not for this.
2. Write each scenario as expected actions. Which tool, which arguments, which result, and what the agent may say only after the result arrives. Score the tool log first and the wording second.
3. Listen to the first and last five seconds of every test recording. Greetings and goodbyes are where timing bugs live.
4. Interrupt ten times per language, as in failure 6.
5. End calls badly. Mumbled goodbyes, "No, I'm good", silence after a goodbye, a caller who keeps talking while the agent wraps up.
6. Inject failures. A tool that times out, a tool that errors, a dropped carrier acknowledgement, a caller who says nothing, and a voicemail greeting.
7. Replay the riskiest turns ten times from pilot calls, with tools stubbed.

After launch, watch five signals:

• seconds from the last farewell to hangup, and which side hung up;
• turns where a reply was generated but no audio reached the caller;
• replies containing tool-like text, and action claims with no tool call;
• every cut made by a repetition or length guard;
• time to first audio, per call and per turn.

Treat a warning that fires on every call as a bug. During one review, a log line saying a call had taken the slow start-up path turned out to appear on every call of one engine, not now and then.

A handoff step was parsing the agent's configuration and returning before storing it, so every call fetched it again with the caller already on the line. Everyone had read the line as background noise.

Turn every incident into a test

Each fix above shipped with tests that drive the real audio and conversation loops with fakes: 40 for the repetition guard, 19 for the interruption fix, 17 for the playback drain. The riskier ones also ship with a setting that switches them off. Over time, the suite becomes a record of every way a call has gone wrong.

Be sceptical of your first diagnosis, too. When we took one bad call apart, 51 suspected defects went in. A second reviewer, whose job was to refute each one, confirmed 34, left 12 as plausible and refuted 5 outright. Fixing a refuted defect adds risk and solves nothing.

When this is more than you need

Four-record testing earns its cost on agents that act: booking, collecting payments, transferring calls, updating a CRM. For a small inbound FAQ agent with no tools, reading transcripts and listening to a sample of calls catches most problems.

Replays have limits too. They need full traces, with turn text plus tool arguments and results, and they stub the tools, so integration failures still need tests against a staging system. Simulated callers are good for volume and script coverage, but they rarely reproduce a lost carrier acknowledgement or a real echo path. Keep part of your testing on real phone lines.

If you're still choosing a platform, ask each vendor which of the four records you'll see for every call. Our 12-point checklist covers the rest. And if you'd like to see all four side by side on a test call of your own, talk to us.