How to Test a Voice AI Agent

A voice AI agent should be tested as a live conversation, not as a transcript alone. Build scenarios around the job the caller needs completed, then check the full path: speech recognition, turn-taking, reasoning, tool calls, permissions, handoffs, and the final outcome. Run the same suite against every meaningful agent change, retain the evidence behind each result, and continue sampling real calls after launch.

This guide gives you a practical test loop, a seven-scenario starter suite, a failure-triage method, and a set of questions to answer before you call a voice agent ready.

A voice agent can pass a transcript check and still fail the call

Treat transcript-only testing as incomplete. Galtea's voice-agent evaluation page makes the same distinction in its headline, “Test the call, not just the transcript,” and describes simulated callers, end-to-end conversations, and monitoring live calls. A caller may be interrupted while speaking, misheard because of background noise, forced to repeat information, or left waiting while a tool call runs. The transcript can look reasonable after the fact even when the experience was broken.

Evaluate at three levels:

1. Conversation quality: Did the agent understand the caller, respond clearly, take turns naturally, and recover when the conversation went off script?
2. Workflow behavior: Did it call the right tools with the right arguments, follow required checks, preserve state, and hand off when it should?
3. Outcome and risk: Did the caller achieve the intended result without an unsafe action, privacy breach, policy violation, or misleading promise?

Do not collapse these into one score too early. A good final outcome does not prove that the agent used an authorized tool or followed the required verification path. Conversely, a small latency increase may be acceptable in one workflow and unacceptable in a time-sensitive emergency flow. Set severity and thresholds according to the consequence of each failure.

Define the call contract before you define the metrics

Start with a written contract for the agent. Describe what it can do, what it must verify, what it must refuse, and when it must involve a person.

For a customer-support voice agent that can look up an order and start a return, the contract might say:

• The agent identifies the caller's order from information the caller provides.
• It verifies the caller's authority before exposing order details.
• It starts a return only when the policy and eligibility checks pass.
• It does not approve an exception that requires human review.
• It explains the next step when a tool fails or the request is outside scope.

Turn each requirement into a testable record:

This is more useful than a general target such as “sound natural.” A testable requirement says, “When the caller asks to change a delivery address, the agent must verify identity before it retrieves or changes the order.” The scenario, expected behavior, and evidence are clear enough for someone else to reproduce.

Build a test set that sounds like your callers

Your test set should contain more than ideal requests read from a script. Use product requirements, support conversations, known incidents, domain-expert examples, and privacy-safe production patterns. Include variation in:

• Caller intent, including common requests, ambiguous requests, and out-of-scope requests.
• Speaking rate, accent, pronunciation, vocabulary, and language where relevant.
• Background conditions such as a quiet room, office noise, traffic, or an unstable connection.
• Turn-taking, including interruptions, pauses, corrections, overlapping speech, and silence.
• Caller emotion, urgency, frustration, and reluctance to provide information.
• Tool outcomes, including valid results, empty results, timeouts, permission errors, and conflicting data.
• Risk level, especially requests involving personal data, payments, regulated advice, or irreversible actions.

A scenario should state the caller's goal and behavior, not dictate every line. If every test case contains the exact wording the agent expects, the suite measures script matching rather than robustness.

For multi-turn testing, define a stopping condition. Examples include “the caller confirms the return and receives a case number” or “the agent escalates without disclosing account details.” A clear stopping condition makes task completion measurable and prevents a simulator from continuing after the meaningful outcome.

Test the full audio-to-action path

Speech recognition is part of the product behavior

Check whether the agent heard the words that matter: names, addresses, account identifiers, dates, amounts, product terms, and negations such as “do not.” Test both transcription quality and downstream behavior. A perfect transcript is not enough if the agent still chooses the wrong action. A noisy transcript may be acceptable if the agent notices uncertainty and asks for confirmation before acting.

Where privacy and consent requirements allow, retain the input audio, the transcript, timestamps, confidence or uncertainty signals available in your stack, and the agent's interpretation. For sensitive calls, use redacted or synthetic recordings in repeatable tests and define retention rules before collecting real audio.

Turn-taking needs its own checks

Test barge-in and interruption explicitly. Ask:

• Does the agent stop speaking when the caller starts talking?
• Does it keep the caller's new information instead of finishing an obsolete response?
• Can the caller correct a misunderstood detail without restarting the call?
• Does the agent recover after a pause or a delayed response?
• Does it avoid talking over a caller who is still giving an account number or address?

Measure the behavior that matters to the experience, such as interruption handling, time to first response, time spent waiting, repeated prompts, and unnecessary turns. Do not choose a universal pass number in the guide or in the test suite. Calibrate thresholds against reviewed examples from the actual product and its risk level.

The last turn is not the whole workflow

A voice agent may produce a polite closing while failing to complete the requested task. For every scenario, verify the final outcome and the path taken to reach it:

• Did the agent identify the right intent and preserve the caller's constraints?
• Did it call the correct tool?
• Were the arguments complete, valid, and scoped to the caller's authority?
• Did it interpret the tool result correctly?
• Did it avoid claiming success when the tool failed?
• Did it create the expected record, booking, payment, case, or handoff?
• Did it give the caller a useful next step?

Keep the tool and workflow checks separate from conversational style checks. A warm voice cannot compensate for an unauthorized account change.

Start with these seven scenarios

The following suite is small enough to run immediately and broad enough to expose the main voice-agent failure surfaces. Adapt the entities and outcomes to your workflow.

1. The ordinary request reaches the correct outcome

Give the agent a common request with all required information. Confirm that it understands the goal, asks only for missing details, calls the intended tools, and completes the task.

Pass when: the caller gets the intended result, the recorded side effects are correct, and the agent does not invent a completion message.

Retain: audio or a privacy-safe recording, transcript, turn timings, tool trace, final outcome, and any confirmation shown to the caller.

2. The caller is hard to hear

Use background noise, a non-ideal connection, a strong accent, unusual pronunciation, or a domain term that is easy to misrecognize. Include a critical identifier or negation so you can see whether the agent confirms uncertainty before acting.

Pass when: the agent either understands the request correctly or asks a focused clarification. It must not silently substitute a different name, amount, address, or instruction.

Retain: input conditions, transcription, uncertainty signals if available, clarification turns, and the downstream action.

3. The caller interrupts and corrects the agent

Let the agent begin a response, then interrupt with a correction or new constraint. Repeat the test with a pause, an overlap, and a caller who changes their mind before the action is taken.

Pass when: the agent yields the turn, incorporates the correction, and does not continue from stale state.

Retain: audio timing, turn boundaries, the partial response if available, the updated state, and the final tool arguments.

4. The request is ambiguous or out of scope

Give the agent a request with two plausible interpretations, incomplete information, or a goal outside its supported workflow.

Pass when: it asks the smallest useful clarification, states the boundary plainly, or routes the caller to the right channel. It should not guess simply to keep the conversation moving.

Retain: the ambiguity, the clarification question, the caller's answer, the policy or capability that determined the route, and the final disposition.

5. A tool returns an error or an unsafe result

Simulate a timeout, empty result, malformed response, permission error, duplicate record, and conflicting data. Include a case where the caller asks the agent to continue despite the failure.

Pass when: the agent handles the error honestly, retries only when safe, does not fabricate a result, and escalates when the workflow requires a person.

Retain: tool name and arguments, response or error, retry decisions, authorization context, user-facing explanation, and any side effect.

6. The call needs a handoff

Test a request that requires a specialist, an exception, a regulated decision, or a human approval. Include a handoff after several turns so the receiving person or system must get the relevant context.

Pass when: the handoff happens at the defined boundary, the destination is correct, the caller is told what happens next, and important context is preserved without exposing information the recipient does not need.

Retain: handoff reason, destination, context payload, consent or authorization state, transfer result, and what the caller heard before and after the transfer.

7. The caller requests a risky or prohibited action

Test personal-data requests, attempts to bypass verification, prompt injection through speech, requests for regulated advice outside the agent's authority, and irreversible actions without the required approval.

Pass when: the agent follows the policy, refuses or redirects when required, avoids leaking protected information, and records the reason for the decision.

Retain: the relevant policy version, caller input, decision trace, blocked tool call or escalation, response, and reviewer judgment for borderline cases.

These seven scenarios should become a regression backbone, not a one-time demo. When a production incident reveals a new failure mode, add a privacy-safe reproduction to the suite after the root cause is understood.

Score the agent with mixed evaluators

Use deterministic checks wherever the requirement is deterministic. Examples include:

• Required tool call was made.
• Forbidden tool call was not made.
• Required argument is present and valid.
• Identity verification happened before account access.
• A handoff includes the required context.
• A case number or booking identifier matches the created record.
• The agent did not claim a side effect that the tool did not confirm.

Use semantic evaluators for open-ended judgments such as whether the agent understood the caller, answered clearly, or completed a conversation goal. Give the evaluator a rubric that names the evidence it should inspect. A vague “was this good?” score is difficult to calibrate and difficult to triage.

Use human review when the decision requires domain expertise, nuanced policy interpretation, or a high-consequence judgment. A judge can help sort a large test set, but it should not silently approve an exception that belongs to a qualified reviewer. Calibrate automated evaluators against reviewed examples and inspect disagreements instead of hiding them in an average.

For voice specifically, keep these dimensions visible even if you later combine them into a release score:

Keep an evidence record for every run

A score without its supporting evidence is hard to trust and harder to fix. For each test run, store enough context to reproduce the result:

1. Agent identity: build, prompt or policy version, model, voice configuration, tools, and relevant telephony or audio settings.
2. Scenario identity: dataset and case ID, caller persona, goal, risk class, input conditions, and expected outcome.
3. Conversation evidence: audio or a permitted substitute, transcript, turn boundaries, timestamps, and the final caller-visible response.
4. Execution evidence: tool calls, arguments, results, errors, retries, handoffs, retrieved data, state changes, and trace relationships.
5. Evaluation evidence: metric name and revision, score, reason, threshold, human label, reviewer notes, and disagreements.
6. Decision record: pass, fail, review, or blocked; owner; failure category; fix; and whether a regression case was added.

Minimize sensitive data. Use synthetic callers and redacted traces for repeatable testing where possible. Keep the data needed to prove the behavior, not every piece of data the system happened to touch.

Galtea's public documentation describes a similar evidence pattern in its tracing guide, which covers tool calls, retrieval operations, model invocations, inputs, outputs, timing, errors, and parent-child relationships. Its dataset documentation also describes generated, uploaded, and manual datasets, including behavior datasets for multi-turn dialogue scenarios.

Triage failures by the layer that broke

When a test fails, do not patch the final response first. Trace the failure to the earliest incorrect event.

Write the triage record so another engineer can reproduce it: the scenario, the first incorrect event, the expected event, the relevant trace, the fix, and the test that prevents recurrence.

Run regression tests before every meaningful release

Freeze a known suite and compare agent versions against it. Re-run the same scenarios when you change the model, prompt, tools, policies, retrieval sources, voice settings, telephony provider, or orchestration code. A versioned test set lets you distinguish an improvement in one dimension from a regression in another.

Use release gates that reflect risk:

• Block on any critical safety, privacy, authorization, or irreversible-action failure.
• Block when a required task outcome falls below the product's calibrated threshold.
• Route borderline semantic or conversational results to human review.
• Track latency, retries, repetition, and abandonment separately from task success.
• Record the reason for every gate decision.

Galtea's version documentation describes comparing product versions against the same datasets. Its GitHub Actions guide shows how to run evaluations in CI, including a pre-deploy workflow where the agent does not need to be deployed to be evaluated. The specific gate and threshold remain product decisions.

Monitor real calls after launch

Pre-release tests cannot predict every caller, provider condition, or production integration failure. Continue the loop after deployment:

1. Log production conversations with a stable conversation identifier and the relevant agent version.
2. Sample common, high-risk, failed, and newly emerging call patterns.
3. Score production traces for task outcome, policy behavior, tool correctness, audio or turn-taking signals, and escalation.
4. Route hard or high-consequence cases to a qualified reviewer.
5. Group failures by root cause rather than counting every symptom separately.
6. Turn confirmed new failure patterns into regression scenarios.
7. Compare trends by agent version, workflow, caller segment, language, and audio condition.

Galtea's production monitoring documentation describes logging real interactions, grouping turns into sessions, and evaluating production responses. For continuous scoring, it points to monitors that sample and score production sessions without a run being triggered by hand.

Readiness depends on the workflow and its risk

There is no universal pass score. A voice agent is ready for a given workflow when the team can show that:

• The test contract covers the agent's supported jobs, boundaries, and highest-risk actions.
• The suite includes realistic audio, interruptions, ambiguity, tool failures, handoffs, and prohibited requests.
• Critical checks are deterministic where they can be.
• Semantic evaluators have been calibrated against human-reviewed examples.
• The same scenarios pass against the release candidate without critical regressions.
• Every failure has evidence, an owner, and a decision.
• Production monitoring can detect the main failure modes and feed them back into the suite.
• Privacy, retention, consent, and escalation requirements are defined for the data being collected.

Readiness is a scope decision, not a claim that the agent is perfect. Define which workflows are approved, which are restricted, and which still require a human.

Questions teams ask before launching a voice AI agent

How do I test a voice AI agent?

Define the agent's expected behavior, create realistic caller scenarios, test audio and turn-taking as well as the final task outcome, inspect tool calls and handoffs, and run the same suite across agent versions. Retain the audio or an approved substitute, transcript, traces, evaluation results, and release decision for each run. After launch, monitor real conversations and convert confirmed failures into regression cases.

Is testing the transcript enough?

No. A transcript can hide interruption timing, overlap, latency, pronunciation, background noise, and whether the caller had to repeat information. Test the audio-to-action path and inspect both the conversation and the workflow evidence.

What metrics should I use for a voice agent?

Use a mix of recognition, turn-taking, conversational clarity, task completion, tool correctness, policy and safety, handoff quality, and efficiency checks. Use deterministic metrics for required events and structured values, semantic evaluation for open-ended quality, and human review for high-consequence or domain-specific judgments.

How do I test interruptions and barge-in?

Interrupt the agent during a response with a correction, a new constraint, and a request to stop. Test pauses, overlapping speech, and a delayed response. Check that the agent yields the turn, updates its state, and does not continue with obsolete content or stale tool arguments.

How do I test voice-agent tool calls?

For each tool, define when it may be called, what arguments are required, what authorization must happen first, and how success or failure is represented. Test valid results, empty results, timeouts, permission errors, malformed responses, and conflicting data. Fail the case when the agent calls the wrong tool, passes unsafe arguments, or claims an unconfirmed side effect.

Should a human review voice-agent tests?

Yes, for cases where the requirement depends on domain expertise, nuanced policy interpretation, safety, or a high-consequence outcome. Automated evaluation can handle repeatable checks and triage, but human reviewers should calibrate the rubric and decide borderline cases.

How do I monitor a voice AI agent in production?

Log production conversations with the agent version and a stable conversation ID, sample common and high-risk calls, evaluate task and policy behavior, inspect traces behind failures, and send difficult cases to review. Add confirmed failure patterns to the pre-release regression suite so production monitoring improves the next release.

Further reading

• Voice agent evaluation and monitoring at Galtea
• Datasets in Galtea Docs
• Metrics in Galtea Docs
• Tracing agent operations
• Human evaluation
• GitHub Actions evaluations
• Monitoring production responses