Accuracy Is Not Reliability: Why Good Demos Fail in Production

A polished demo tells you almost nothing. The agent that nails scripted test calls in a provider's controlled environment can still stumble on your actual phone line, with your callers, in your workflows — and the industry's own data explains why.

A Princeton-led study of 14 agentic models found that across 18 months of model releases, accuracy improved steadily while reliability improved only modestly. The two are independent: a highly capable system can be unreliable, and a less capable one can be highly dependable within its operating envelope. That's why a provider's accuracy claims are such a weak signal for what you actually care about — whether the agent works every time a customer calls.

The researchers argue that compressing agent behavior into a single success metric obscures critical operational flaws. Instead, they propose four reliability dimensions:

• Consistency — does the agent behave the same way across repeated, identical situations?
• Robustness — does it degrade gracefully when callers ramble, interrupt, or provide messy input?
• Predictability — does it know what it doesn't know, and escalate when uncertain?
• Safety — is failure severity bounded, so mistakes stay recoverable?

The safety dimension deserves special attention, because not all failures are equal. A component that fails rarely but catastrophically can be worse than one that fails often but harmlessly — and an accuracy score cannot tell the difference between a benign stumble and a deleted record. The study cites a July 2025 incident in which Replit's AI coding assistant deleted an entire production database despite explicit instructions forbidding such changes. For a business putting an agent in front of customers, a rare catastrophic failure — a wrong appointment confirmed, a caller told something false with confidence — damages trust far more than frequent small hiccups.

Practitioner data reinforces the point. A system with 95% test accuracy can still fail catastrophically in production due to poor consistency, unhandled edge cases, or performance drift, according to reliability practitioners. And in LangChain's State of Agent Engineering survey of 1,340 practitioners, quality — accuracy, consistency, tone and policy adherence — remained the single biggest barrier to production, cited by 32% of respondents.

This is why Agents by AIQ treats reliability questions — how failures are bounded, how uncertainty is escalated to a human, how behavior stays consistent over time — as more important than demo-day accuracy. Ask any provider the same questions before you put their agent on your phone line.

The SLA Gap: Most AI Voice Providers Publish No Guarantees at All

Imagine signing a contract for phone answering service and discovering, months later, that the "guarantee" you assumed existed was never written down anywhere. That is the default experience in the AI voice agent market today.

The evidence is blunt. On 23 September 2026, conventional SLA pages returned HTTP 404 for Vapi, Retell AI, Deepgram, and ElevenLabs — four of the most prominent names in voice AI. None of them published a contractual uptime commitment at the time. At the model layer, Anthropic's Claude API measured 99.42% uptime with no published SLA, and Claude.ai measured 99.32% — figures that come from independent uptime tracking, not from any promise the companies made.

Buyers routinely confuse two very different artifacts. A status page is, as one analysis puts it, "an honest description of what happened last month". An SLA is "a promise with money behind it" — a contractual commitment backed by service credits when the provider misses it. Confusing the two is described as the most common mistake buyers make in this evaluation.

The numbers explain why the distinction matters so much:

• 99.9% uptime permits roughly 43 minutes of downtime per month; 99.3% permits over 5 hours
• Measured uptime for leading model APIs without SLAs sits around 99.3–99.5%
• One provider's non-contractual status page showed 99.890% API uptime — about 48 minutes of downtime per month

Here is where it compounds. Most voice AI products are assembled from multiple components — telephony, speech-to-text, an LLM, text-to-speech — and experienced availability is the product of all of them. Adding a single LLM API at 99.30% availability can drag total application availability from 99.93% down to 99.25%, turning 30 minutes of monthly downtime into more than five hours.

As one infrastructure analysis frames it: put an AI voice agent in front of your phone line and you have not added a feature — you have added a dependency, and your phone line is now only as available as the AI is.

When a voice AI fails, one of four things happens: the call falls through to a human queue (the best case, but only if configured), it rings out, it hits a busy tone, or — worst — it connects and sits in silence while the caller believes they have reached you. Ask any provider which one applies to your setup, and get the answer in writing. When we at Agents by AIQ scope an AI receptionist for a client, that failover behavior is one of the first things we define, because a missed call during an outage is still a missed customer.

What to Demand: SLAs, Failover Plans, and Verifiable Metrics

Most AI voice agent providers publish no SLA at all — on a single day in September 2026, standard SLA pages returned 404 errors for Vapi, Retell AI, Deepgram, and ElevenLabs, according to one infrastructure analysis. That means the burden of defining reliability falls on you, the buyer. Here is the checklist worth bringing to the table.

Start with a contractual SLA, not a status page. A status page is "an honest description of what happened last month," while an SLA is "a promise with money behind it." Expert guidance on voice-agent SLAs recommends 99.9% minimum uptime — and crucially, uptime defined by successful call handling, not server pings. A server that responds while callers hear silence is technically "up."

Demand percentile-based latency caps. Averages hide the problems that frustrate callers most. Require P95 latency under 1.5 seconds and P99 under 2.5 seconds, and remember that a promise with no penalty is a suggestion — service credits must scale with severity and duration. Watch for carve-outs around maintenance and third-party outages, which can quietly swallow the guarantee.

Your negotiation checklist should include:

• Written failover plans for LLM outages — ask which models power the system and whether the provider can pivot to another LLM without service interruption, as legal due-diligence guidance recommends. Two independent providers at 99.3% uptime each yield roughly 99.995% combined availability.
• Drift monitoring with change notification — model drift can significantly degrade performance over time, so require written notice and a test window before any model or prompt change.
• Observability and tracing access — 94% of organizations running agents in production have observability tooling, per a 1,340-respondent industry survey, making it a baseline expectation rather than a premium feature.
• Independent verification — because the party that owes credits also counts the breaches, insist on synthetic calls or blind transcript grading to confirm claims.

Test the failure mode yourself before launch. Point call forwarding at a dead number during a quiet period and call in to hear what actually happens — the worst outcome is a connection that sits in silence, because the caller believes they have reached you. Keep one direct human bypass number as insurance.

At Agents by AIQ, we treat these commitments as the starting point of any agent deployment, not an afterthought. A number you cannot check is not a guarantee — it is a hope. Ask for the contract, the failover plan, and the tracing access, and verify all three before your first caller does.

Test Before You Trust: A Practical Reliability Verification Plan

Here's the uncomfortable truth: most businesses never hear what their AI phone agent sounds like when it fails. They test the happy path — a clean call, a standard question — and go live. The failure behavior stays a mystery until a real customer hits it at 7pm on a Friday.

The fix takes fifteen minutes. During a quiet period, point your call forwarding at a dead number, then call in yourself and listen to what actually happens. According to infrastructure analysis of AI voice agents, almost nobody does this — yet it's the only way to hear your real failure mode. When a voice AI goes down, one of four things happens: the call falls through to a human queue (the best outcome, but only if someone configured it), it rings out, it returns a busy tone, or it connects and sits in silence — the worst case, because the caller believes they've reached you and waits for an answer that never comes.

Beyond that test, a few safeguards belong in every launch plan:

• Keep one direct human bypass number that never routes through the AI, so you always have a way in and your customers always have a way to reach a person.
• Never consolidate your phone system and deploy an AI agent at the same time. Changing two things at once makes it impossible to know which change caused a problem.
• Stress-test in a sandbox with realistic, messy inputs — mumbled speech, background noise, interruptions — not developer-style clean queries. IBM's AI experts note agents "must be rigorously stress-tested in sandbox environments to avoid cascading failures."
• Get failover behavior in writing for your specific connection method, not a generic description.

Scope matters as much as testing. IBM research scientists caution that not everything should be agentized, and a Princeton-led study of 14 agentic models found that a less capable system can be highly reliable within its operating envelope — while a highly capable one can be unreliable. Match the agent's scope to what it can handle dependably rather than handing it everything. An AI receptionist that reliably answers calls, books appointments, and escalates the rest beats a broad agent that occasionally goes off-script.

This is how we approach verification at Agents by AIQ: test the failure path before launch, keep the human bypass intact, and scope each agent to what it can do reliably — because a number you cannot check is not a guarantee. It is a hope, as SLA evaluation guidance puts it. If you want an agent built and verified this way for your business, book a call and we'll scope it together.

Choosing a Partner Who Owns Reliability With You

There's an uncomfortable tension in everything we've covered: reliability is a shared responsibility, but you didn't sign up to be a reliability engineer. IBM's Chris Hay puts it bluntly — most organizations aren't agent-ready, and success depends heavily on how prepared the buyer is. For a solo plumber or a five-person law office, that framing is a problem. You can't build an observability stack, and you shouldn't have to.

The industry data backs this up. Among organizations with agents in production, 94% have observability tooling and 71.5% have detailed tracing of individual agent steps, according to LangChain's survey of 1,340 practitioners — a clear signal that running agents well is real operational work, not a set-and-forget install. The question is who does that work.

The honest answer is that a done-for-you provider should take the engineering burden off your plate entirely. That means the provider owns the unglamorous work that determines whether your agent holds up when a customer calls at 7pm with a strange question. Look for a partner who handles, in writing:

• Sandbox stress-testing before launch — IBM's experts recommend agents be rigorously stress-tested in sandbox environments to avoid cascading failures, with rollback paths and audit logs in place for high-stakes use.
• Ongoing monitoring and drift alerts — vendors must have a plan to monitor post-deployment performance and alert customers when model drift affects results, since drift can quietly degrade an agent over time.
• Human escalation within seconds — when the agent hits an edge case, the caller should reach a person fast, with context transferred, not a dead end. Expert guidance recommends handoff within roughly 10 seconds of a trigger.
• Independent verification — "the party that owes credits also counts the breaches," so ask how performance is checked via real call testing and transcript review rather than self-reported dashboards.

Ownership matters as much as operations. A provider confident in their reliability work shouldn't need to lock you into a long contract — month-to-month terms, with you owning your agent, its data, and its configuration, are the natural fit for a relationship built on demonstrated performance rather than paperwork. If the provider is doing the monitoring, testing, and escalation work properly, they shouldn't need a multi-year commitment to keep you.

That's the standard we hold ourselves to at Agents by AIQ. We design, build, and operate done-for-you agents — receptionists, follow-up, support, and workflow automation — so the reliability engineering lives with the team running the system, not on your shoulders. If you want to see what that division of labor actually looks like for your business, book a scoping call and we'll walk through exactly how your agent would be built, tested, monitored, and escalated — before you commit to anything.