Voice AI Load Testing: Proving the Ceiling Before Peak

Most enterprise voice AI programmes arrive at go-live with a capacity number. It came out of a demand forecast, a concurrency calculation and a vendor conversation, and it sits in the deployment plan looking authoritative. Almost none have proved it. The number describes what the team believes the system can carry, not what it has been observed to carry, and that difference only becomes visible on the day volume arrives.

That day is rarely convenient. It is the January renewals surge for an insurer, the results-day spike for a university, the Monday after a billing run for a utility. The agent that handled forty pilot calls a day meets four hundred an hour, and the failure does not look like a slow agent. It looks like calls rejected at the carrier and CRM lookups returning errors.

Load testing turns the capacity number into a measurement. It is also the step most teams skip, because the pilot passed and the pilot felt like a test. It was not. A pilot proves the conversation works. A load test proves the system underneath it survives being used at volume, and it is the only exercise that finds the ceiling before a customer does.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments. Or see DATS, our five-stage AI consulting system.

What is voice AI load testing?

Voice AI load testing is the practice of driving synthetic call traffic at a deployed voice agent and its dependencies until measured behaviour degrades, so the true capacity ceiling is observed rather than assumed. Dilr Voice treats it as a distinct gate from conversation quality testing: the question is not whether the agent answers correctly, but whether the telephony layer, the inference providers and the downstream systems hold their response times as concurrency climbs.

The distinction matters because the two tests fail in different places. Conversation quality work, of the kind covered in our voice agent QA and testing framework, examines a single call and asks whether the agent understood, complied and resolved. Load testing runs hundreds of calls that individually do not matter and watches what the aggregate does to shared resources: connection pools, rate limiters, token buckets, database locks.

This post assumes you already have a capacity target. If not, our voice AI capacity planning framework covers turning a demand forecast into a concurrency number and where the structural ceilings sit. What follows is the test that proves the number, which that framework deliberately leaves to a separate exercise.

Why does a voice agent that passed its pilot still fail at peak?

Because a pilot exercises the agent and a peak exercises the platform. Pilots run at low concurrency against warm systems with generous headroom, so shared limits never bind. At peak, the same code path meets carrier rate limits, CRM daily quotas and inference provider throttles simultaneously. Dilr Voice sees the same pattern repeatedly: the agent logic is fine, and the deployment fails at a boundary nobody load tested because nobody owned it.

The macro picture explains why this keeps happening. McKinsey's State of AI research, published in November 2025, found that 88% of enterprises now use AI somewhere, but only 33% have put it into production and just 14% report material EBIT impact. The gap between adoption and production is largely a gap in engineering discipline applied to the boring layers, and capacity is one of the most reliably neglected.

There is also an ownership problem. The voice AI vendor owns the agent, the telephony provider owns the trunk, the CRM team owns the API quota. Each party tests its own component in isolation and each test passes. Nobody tests the composed path at volume, which is precisely where the interaction effects live. Fixing that ownership gap before a deployment commitment is part of our AI operating model consulting work.

How do you generate synthetic call traffic that behaves like real callers?

Synthetic call traffic has to exercise the full path, which means real audio over real telephony rather than API calls that skip the media layer. The practical method is a pool of test numbers placing scripted calls with pre-recorded or synthesised speech, arrival times drawn from a distribution rather than a fixed interval, and a deliberate mix of call shapes. Dilr Voice runs short, long and abandoned calls together, because each holds resources differently.

Three properties separate a useful generator from a meaningless one. First, arrival distribution: real callers do not arrive evenly, they cluster, so a test that places one call per second flat will never reproduce the burst that breaks a token bucket. Second, call duration spread: a long call holds a concurrency slot and a media session for minutes, and a population of long calls saturates concurrency at a much lower arrival rate than the average suggests.

Third, and most often missed, the synthetic caller must actually talk. A call that connects and stays silent exercises telephony but not inference, not the speech pipeline and not the tool calls the agent makes mid-conversation. Those tool calls are the traffic that reaches your CRM, and they are why load testing a voice agent is not load testing a web service. Barge-in and interruption behaviour should be represented too, since these change turn counts and therefore inference volume per call.

What ramp profile should an enterprise load test follow?

A load test should climb in stages with a hold at each level, not jump straight to target. Dilr Voice uses five stages: a single-call baseline that confirms instrumentation, a rated ramp to the planned concurrency, a plateau held long enough to expose leaks, a deliberate overload past the target to find the actual ceiling, then a recovery phase. Each stage carries its own pass criteria, and the test stops at the first stage that fails rather than pushing on.

The plateau earns its keep. Short ramps miss anything cumulative: connection pools that never return sockets, log volumes that fill a disk, token caches that grow without eviction. A deployment comfortable for ten minutes at target concurrency and unstable at ninety has a leak, and only a soak reveals it. An hour at target is a sensible minimum for a first test.

The overload stage is the one teams resist, because deliberately breaking a system feels reckless. It is also the only stage that produces a number you did not choose. Everything below the ceiling tells you the system is fine; only pushing past it tells you where fine ends and whether it degrades gracefully or falls over. That behaviour determines whether the incident response runbook you wrote is realistic.

Recovery is easy to overlook. Systems that fail under load do not automatically return when load drops: queues stay full, retries amplify, circuit breakers stay open. Without a recovery phase you learn nothing about how long an incident actually lasts after traffic subsides.

Which system actually breaks first under load?

Rarely the voice agent. In most enterprise deployments the first hard limit is the telephony rate limit or the downstream CRM quota, both of which are documented and both of which are usually discovered in production instead of in a test. Dilr Voice starts every load test by reading the published limits of every dependency in the path, because the ceiling is frequently written down in a vendor document that nobody on the programme has opened.

Twilio is a useful worked example because its limits are public and precise. Twilio's documentation states that by default each account can make one outgoing call per second, and that this rate applies to both outbound API-requested Programmable Voice calls and Elastic SIP Trunking calls. The important detail for a load test is that exceeding it fails differently by product: Programmable Voice queues the excess and executes it as capacity frees up, cancelling anything that sits in the queue beyond 24 hours, while an Elastic SIP Trunk returns a failed call with a SIP 503 Trunk CPS limit exceeded response. One failure mode delays your callers and the other drops them, and a test that does not distinguish between them will report the wrong risk to the business.

Concurrency is governed separately from rate, and Twilio changed those defaults recently. For accounts upgraded from trial on or after 3 February 2026, unlimited call concurrency requires an approved Business Primary Customer Profile, while an approved Individual profile is capped at three concurrent calls. A load test on an unverified account measures the verification status, not the platform.

The downstream CRM is the other reliable ceiling, and usually the harder one to raise. HubSpot publishes explicit quotas: privately distributed apps on an Enterprise subscription get 190 requests per 10 seconds and one million requests per account per day, Professional gets the same burst allowance but 625,000 per day, and Free or Starter accounts get 100 per 10 seconds and 250,000 per day. Exceed either and, in HubSpot's words, any app "exceeding its rate limits will receive a 429 error response for all subsequent API calls".

All three figures share one denominator: requests per day, per HubSpot account, for privately distributed apps. The daily allowance is shared across every app in that account rather than granted per app, and that sharing is the trap. Your voice agent is not the only thing calling the CRM, and a load test that consumes the day's remaining quota at 11am will take marketing automation down with it.

Salesforce constrains a different dimension. Enterprise Edition orgs receive 100,000 API requests per 24 hours plus 1,000 per licence, but the limit that bites during a load test is concurrency: production orgs allow only 25 concurrent requests running 20 seconds or longer, with a 10 minute ceiling on any single call. A voice agent making a slow enrichment call on every conversation can exhaust that allowance far below the telephony ceiling.

The same dependency mapping underpins our enterprise voice AI deployments, where published third-party limits are collected before a ramp plan is written rather than after an incident.

Inference providers form the third layer, and are least predictable because published limits change and effective throughput varies with model load. This is where model failover and provider redundancy stops being theoretical: run at least one stage with the primary provider deliberately throttled, to confirm the failover path carries production concurrency rather than merely existing in a diagram.

What does the FCA expect a regulated firm to test?

For UK financial services firms, load testing is not only good engineering, it maps onto an explicit regulatory obligation. The FCA Handbook requires scenario testing against severe but plausible disruption, and peak demand on a customer-facing voice channel is exactly that. Firms deploying voice AI into an important business service should expect to evidence that tested capacity supports the impact tolerance they have set, not merely that a vendor asserted a number.

The rule is direct. SYSC 15A.5.3 states: "A firm must carry out scenario testing, to assess its ability to remain within its impact tolerance for each of its important business services in the event of a severe but plausible disruption of its operations." SYSC 15A.5.4 goes on to require an appropriate range of adverse circumstances of varying nature, severity and duration.

The provision that most affects voice AI buyers concerns third parties. Where a firm relies on a third party to deliver an important business service, the FCA expects it to work with that provider on the validity of its scenario testing, and states plainly that "The firm is ultimately responsible for the quality and accuracy of any testing carried out, whether by the firm or by a third party". A vendor load test report is evidence, not a transfer of responsibility, and procurement teams should treat it accordingly. Similar reasoning runs through our DORA and operational resilience analysis for firms in scope of the EU regime.

Note also that the Handbook explicitly contemplates testing "through the use of live-systems" alongside paper-based exercises and simulations, so a desk-based capacity model is unlikely to satisfy a supervisor on its own where a live test was feasible. Sector calibration of this kind is part of what our AI execution office brings to a regulated deployment.

What is the best way to load test a voice AI deployment in 2026?

The best approach in 2026 is a staged synthetic ramp run against the full production path in a pre-production environment that shares the same third-party limits, with per-stage pass gates and a deliberate overload stage. It beats the alternatives for one reason: it measures the composed system rather than its parts. That said, it is expensive and slow, and there are scenarios where a lighter method is the right call, which is worth being honest about.

Where the alternatives win: if you are comparing platforms before selection rather than validating a deployment, published benchmarks and vendor-run tests from PolyAI, Vapi, Retell AI, Bland AI, Synthflow or ElevenLabs are a faster way to build a shortlist, and a full ramp against six candidates wastes budget. Our latency and quality benchmark guidance covers what to demand at that stage. If your deployment is genuinely low volume, a soak at expected peak without an overload stage may be proportionate.

Where it does not win is anywhere a capacity failure carries customer or regulatory consequence, which describes most deployments in financial services, utilities, healthcare and the public sector. There the composed test is the only method producing evidence rather than inference, and it is what we run inside our DATS methodology before a production ramp is approved.

Tooling matters less than method. Established load generators handle the API and CRM layers well, but the telephony and media path usually needs a specialist voice testing provider or a purpose-built harness on your own carrier account. What matters is that it produces real audio over real trunks, records per-stage metrics, and can be stopped instantly.

How often should a voice AI load test run?

At minimum before every material change to capacity, dependencies or call routing, and on a regular cycle regardless. Dilr Voice recommends a full staged ramp before initial go-live, a repeat before any known seasonal peak, and a shorter regression soak whenever an inference provider, telephony route or CRM integration changes. Continuous low-volume synthetic traffic between full tests is also worth running, because it catches regressions a quarterly test would miss.

Can you load test safely in production?

Sometimes, with strict controls, and it is a genuine trade-off rather than a straightforward yes or no. Production is the only environment with the real third-party limits, but a test that consumes a shared CRM daily quota or triggers carrier throttling harms live customers. Dilr Voice runs production tests only in low-traffic windows, against isolated test numbers, with a hard stop condition and the ability to abort within seconds.

Want to see this in production? Try Dilr Voice live, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside enterprise systems.

The through-line is simple to state and hard to practise: an untested capacity number is a forecast wearing the costume of a measurement. Running the ramp converts it into something you can defend in front of a regulator, a board or an operations director. Teams that have done it find the exercise reshapes the deployment plan, because the ceiling is almost never where the architecture diagram implied. More sits in our strategy writing and in the production traffic ramp work that follows a successful load test, where real callers replace synthetic ones. Peak cost visibility is covered in our chargeback and cost allocation guidance, and the team behind this work is described on our about page. If a peak is already in the diary, the fastest route to a defensible plan is to talk to our team.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.