An AI call agent only looks like a chatbot with a voice. Underneath, it is a real-time pipeline: speech-to-text, a language model that decides what to say and do, and text-to-speech, all running live while the caller can talk over it. Each stage fails in a way a text test never sees, whether a misheard account number, a half-second of dead air, an interruption it speaks straight over, or a backend action it never triggers. The dimensions that decide whether a voice agent is production-ready (recognition accuracy, latency, interruption handling, task completion, faithfulness, tool-calling, and safety) sit almost entirely outside both traditional QA scripts and text-only LLM evaluations. This is the voice-agent layer of the broader build-versus-buy question in our guide to AI-powered QA testing outsourcing; here is what testing the agent itself actually involves.
What makes testing an AI call agent different from testing a chatbot?
The stack, the clock, and the non-determinism. A text chatbot is one model returning text. A voice agent chains speech recognition, a dialog model, and speech synthesis, in real time, so errors compound down the chain: a transcription slip becomes a reasoning error becomes a wrong spoken answer. Testing only the text layer misses most of that surface. The reasoning layer also fails in a specific, named way. NIST calls it confabulation, "the production of confidently stated but erroneous or false content (known colloquially as 'hallucinations' or 'fabrications')" (NIST AI 600-1). NIST adds that this risk is "most commonly a problem for text-based outputs," but a voice agent speaks asserted facts aloud, so the hallucination risk applies in full.
What does QA actually measure on an AI voice agent?
| Dimension | What QA checks | Why it is voice-specific |
|---|---|---|
| Recognition accuracy | Word Error Rate: does speech-to-text hear the caller correctly across accents, noise, and numbers | A misheard digit in an account or card number is a silent, upstream failure |
| Conversational latency | Time to first response under live conditions | Dead air reads as a broken call, not a slow page |
| Interruption / barge-in | Does the agent stop and listen when the caller cuts in | No text equivalent; an agent that talks over you fails on contact |
| Task completion | Did the call achieve the caller's goal, end to end | The outcome the business actually buys |
| Faithfulness | Does the answer match the source or policy instead of confabulating | A spoken hallucination is asserted as fact |
| Tool / function calls | Does the agent correctly trigger backend actions (lookup, booking, payment) | A wrong API call is an operational error, not a cosmetic one |
| Safety / guardrails | Resistance to prompt injection and unsafe instructions | OWASP's top LLM risk, and an agent that acts raises the stakes |
Word Error Rate is the standard recognition metric. NIST defines it as "the sum of deletion, insertion, and substitution errors in the ASR output compared to a human reference transcription, divided by the total number of words in the human reference transcription" (NIST OpenASR). The rest of the table is where voice testing leaves familiar QA behind.
Why is conversational latency so hard to get right?
Because people are exquisitely tuned to the gap between turns. In a cross-language study of natural conversation, response times were "unimodal with the highest number of transitions occurring between 0 and 200 ms," with a mean offset of "+208 ms" (Stivers et al., PNAS). A pause a web app would never register, half a second, is the moment a caller asks "hello, are you there?" The honest caveat: that 200 ms is the human bar, not a published bot SLA, and no neutral standard sets one. What is verifiable is that latency is a first-class test signal. Voice-testing platforms such as Cekura measure "interruption tracking, latency, sentiment" as purpose-built voice signals (Cekura). Treat any specific millisecond target as vendor-documented, and measure it under load, not in a quiet demo.
How do you test something non-deterministic?
You stop testing one path and start testing thousands. A voice agent answers the same prompt differently, reaches the same goal by different routes, and degrades under real-world audio, so single-pass assertions cannot characterize it. The method is conversation simulation at scale: generate scenarios across accents, background noise, and interruptions, run them as complete calls, and score the outcomes. Platforms built for this, among them Hamming, Coval, and Cekura, replay real calls as regression suites and run large batches of synthetic conversations before launch (these are vendor-reported capabilities, so confirm the numbers against your own run). The shift is from "does this script pass" to "what share of realistic calls reach the goal."
What about safety and compliance?
A call agent that looks up accounts or takes payments is an agent that acts, which raises the bar. Prompt injection is OWASP's number-one LLM risk: "A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways" (OWASP LLM01), and the 2025 list adds Excessive Agency (LLM06) for exactly the case of an agent that can trigger actions (OWASP LLM Top 10). Adversarial testing of the dialog layer, meaning simulated jailbreaks and injection attempts, belongs in the suite; tools such as promptfoo run "simulated adversarial inputs" mapped to the OWASP list (promptfoo). Compliance adds hard limits. If the agent handles card numbers, PCI-DSS applies, requiring "appropriate measures to protect any systems that store, process and/or transmit cardholder data" (PCI SSC), and call-recording consent rules differ by jurisdiction (one-party versus all-party), so the test plan has to know where the caller is.
What should you look for in a partner that tests AI call agents?
Two layers, not one. The voice layer needs a simulator that places real calls and scores recognition, latency, interruption handling, and task completion; Cyara, Hamming, Coval, and Cekura sit here, alongside the testers built into platforms like Vapi and Retell. The model layer needs adversarial and red-team coverage of the dialog policy, which is promptfoo's territory. A partner that runs only one layer is testing half the agent. Ask for a sample scenario set, latency measured under load, the regression method (do they replay real calls?), and an OWASP-mapped safety pass: the same proof-over-promises diligence we set out in the AI-powered QA testing outsourcing guide.
What does a realistic test scenario set look like?
A call-agent suite is only as good as the conversations it simulates, so the scenario set has to resemble real calls rather than happy-path scripts. Three axes matter. The first is acoustic: accents, background noise, cross-talk, and poor-line conditions, because recognition (the Word Error Rate problem above) degrades fastest there. The second is conversational: interruptions, topic switches, corrections like "no, the other account," silence, and callers who go off-script, which is where turn-taking and task completion break. The third is adversarial and edge-case: prompt-injection attempts, out-of-scope requests, and the inputs the agent must refuse or escalate, which is where safety and tool-calling are tested. Voice-testing platforms generate and run these at volume rather than by hand; Cekura, for one, exposes "purpose-built signals for voice" including interruption and latency tracking across generated scenarios (Cekura). The discipline is coverage: a suite that only tests clear audio with cooperative callers passes in the lab and fails on the first real call.
The verdict: test the conversation, not the transcript
An AI call agent only resembles a chatbot. What actually makes or breaks it, namely hearing the caller, answering in time, yielding when interrupted, completing the task, refusing to confabulate or be injected, and holding up under real audio, is a test surface that text QA and text LLM evals barely touch. Score it the way a caller experiences it: thousands of realistic conversations, measured on recognition, latency, completion, faithfulness, tool-calls, and safety. A passing transcript is not the same as a working call.
Sources
- NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative AI Profile (confabulation), 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- NIST, OpenASR20 evaluation (Word Error Rate definition; conversational telephone speech). https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=932302
- Stivers et al., "Universals and cultural variation in turn-taking in conversation," PNAS, 2009. https://pmc.ncbi.nlm.nih.gov/articles/PMC2705608/
- OWASP, LLM01:2025 Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- OWASP, Top 10 for LLM Applications (2025). https://genai.owasp.org/llm-top-10/
- PCI Security Standards Council, Protecting Telephone-Based Payment Card Data. https://listings.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf
- promptfoo, LLM red teaming documentation. https://www.promptfoo.dev/docs/red-team/
- Cekura, voice-agent testing signals. https://www.cekura.ai/
- Hamming AI, voice-agent testing at scale. https://hamming.ai/
- Coval, voice-agent simulation. https://www.coval.dev/
- Cyara Voice Assure, voice and contact-center assurance. https://cyara.com/products/voice-assure/
Email Us
Call Us
