SoundHound used its Q3 2026 earnings call to brag about Alex, an AI agent now answering residents' calls in Spanish across 76 city districts and handling up to 1,000 calls simultaneously. A day earlier, Convoso moved its no-code Voice AI Agent into general availability with a pitch to help contact centers expand qualification capacity as lead volumes change, without adding human headcount at the same rate. Every voice-AI pitch at this stage of the market is a concurrency pitch.
Most QA for those same agents is single-threaded. One prompt change, one staging call, one listen, ship. The agent that passes a one-at-a-time regression at 3pm on a Tuesday is the same agent that stalls, re-asks, and gets handed back to a human at 10am Wednesday when the marketing email drops and the queue depth jumps from two to two hundred. The gap between "it works" and "it works at peak" is where most new voice agents quietly lose their first month of usage.
Single-call QA is a different test than load
A single-call test proves the happy path exists. It is necessary and not sufficient. What it cannot prove is that the system still behaves correctly when someone else is using it at the same time. Voice agents are built on a stack of fan-in dependencies: a telephony carrier, a realtime model provider, an STT/TTS pipeline, a knowledge base, a half-dozen tool endpoints. Each of those dependencies has its own concurrency ceiling, its own queueing behavior, and its own idea of what graceful degradation looks like.
When load climbs, those dependencies do not fail uniformly. They fail in a sequence that is specific to your stack. Finding that sequence before a customer does is the whole job.
The ceilings you hit first live in telephony
Carrier limits are the floor nobody checks. Twilio's Elastic SIP Trunking defaults to 1 call per second per trunk per region, with self-service capped at 5 CPS for trunks before a conversation with the account team. Accounts upgraded on or after February 3, 2026 need an approved Business Primary Customer Profile to get unlimited concurrency at all; newly upgraded accounts with an approved Individual profile are limited to 3 concurrent calls. Telnyx defaults new accounts to 2 outbound channels globally, bumping to 10 after Level 2 verification, with anything above that requiring written justification. Plivo defaults sit around 50.
None of this breaks anything in a one-call demo. It all breaks at launch, when the dialer actually runs or the campaign actually lands. The relevant quantity is not what the plan says. It is what happens the first time a 429, a SIP 503, or a SIP 403 lands in the middle of an active conversation. For most stacks, the answer is: nothing good.
The ceilings you hit second live in the model stack
Underneath the carrier sit the model providers. OpenAI's Realtime API is rate-limited per usage tier and enforces per-tier TPM caps on gpt-realtime-2.1, with 200,000 tokens per minute on the entry Build tier and larger ceilings only on Launch and Grow. Teams running near the edge of their tier regularly report latency scaling with concurrency even before any 429s fire: five concurrent requests at one latency, fifty roughly double, a hundred roughly quadruple. The provider is not broken. The capacity planning is.
Cascade pipelines fail in a different place: STT first, then LLM, then TTS. Each has its own concurrency profile and its own retry behavior, and any of them can become the bottleneck in a given minute. Speech-to-speech pipelines collapse those failure modes into one session ceiling with much harder cliff behavior, since once a session is lost there is no half-degraded path.
And beneath both sit your tools. The CRM write. The scheduling API. The insurance eligibility check. These are not usually tested at voice-agent concurrency because, in a single-call test, they return in 300 ms. At real peak, with the agent fanning out several background calls per conversation across hundreds of live sessions, they do not. A tool that quietly runs at 2 seconds instead of 300 ms turns into dead air on the caller's end, which turns into caller repetition, which trips barge-in, which breaks the turn.
Quality is a load-dependent metric, not a fixed one
The second pillar of this problem is that voice-AI quality is itself load-dependent, even inside the model. First-token latency, endpointing accuracy, interruption handling, and TTS fluency all shift as system load changes. A 200 ms p95 first-audio latency at idle can turn into 900 ms p95 at peak, and that shift is enough to change how an agent handles a slow caller. Higher latency makes the agent appear hesitant. The caller fills the silence. Now the agent is being interrupted mid-generation. Now the whole conversation's turn-taking is off.
Per-call quality metrics are not static. They degrade in correlated ways under load, and the only way to catch that is to measure them under load. Measuring them under single-call QA tells you the floor. It does not tell you the behavior you will ship.
The four tests you actually need before launch
A launch-ready voice agent should have passed four load shapes, not just a smoke suite.
- Ramp. Call rate increases linearly from one to peak over, say, 15 minutes. Where does latency start to climb? Where does a provider start queueing? Where does your downstream CRM API start returning 5xx? The ramp tells you which ceiling you hit first.
- Soak. Hold at a sustained, realistic volume for 30 to 60 minutes. What leaks? Websocket sessions that never get cleaned up, in-memory counters that drift, auth tokens that near expiry on a quiet account but hammer the refresh endpoint on a busy one. Soak is also where you find the quieter class of problems: session memory growing, context windows filling, a slow leak in the connection pool.
- Burst. Hit the system with 2x to 3x projected peak for 60 to 120 seconds, then drop back. This is the marketing-email moment, or the inbound surge that follows a TV spot. The question is not "does it stay up". The question is "what does the caller on call number 183 hear?"
- Chaos. Simulate a dependency outage mid-load: your STT provider returns 503s for 30 seconds, your CRM API latency spikes to 5s, your telephony trunk rejects new calls. Does the agent degrade gracefully, hand the caller off, apologize, retry, or does it silently sit there until the max-duration kicks in?
A team that cannot name which of these four it has run has not load-tested its voice agent. A team that has run only the first two has an agent that will survive a normal Tuesday and not a bad one.
What to score under load
Standard per-call metrics still matter under load, but the useful views are distributions, not averages.
- First-audio latency p95 and p99. Average hides the long tail. The long tail is what the caller remembers.
- Dead-air duration p95 on live calls. A single sub-second pause is normal. A 2.5 second pause is a quality event, and the frequency of those events under load is the signal.
- Caller-interruption rate and agent-overtalk rate. These shift when latency shifts, in opposite directions, and both shifts hurt.
- Turn-completion rate. The share of turns where the agent finished a coherent response before being interrupted or cut off. This number can quietly halve under load while the aggregate call success rate still looks fine.
- Error-class rate by dependency. 429s per minute on the model, 5xxs per minute on each tool API, SIP 503/403 per minute on telephony. A single dashboard of these next to call-quality metrics usually makes the story obvious inside ten minutes.
The deeper point: these are not operational metrics watched passively from a dashboard after launch. They are acceptance criteria for a pre-launch load test. "The agent maintains p95 first-audio latency under 900 ms at 1.5x projected peak with zero carrier rejections" is the kind of thing a launch gate should look like.
Simulating the peak, not the single call
Single-call simulations under-test voice agents for all the reasons above. To get useful load testing, the simulation has to look like real traffic: real phone calls, real codecs, real telephony, running concurrently against the same agent configuration the customer will dial into. Text loopback and transcript replay do not stress the parts of the stack that actually fall over at peak.
This is the piece most teams build badly or not at all. A handful of parallel dial scripts work for a while, then the test rig itself becomes the bottleneck, and the test becomes a measurement of the rig rather than the agent.
Where Roark fits
Roark is a simulation-testing, observability, and reporting platform built for voice agents, and the simulation layer is the piece that solves this problem specifically. Roark dials your agent over real phone calls, PSTN and WebRTC, using personas that define voice, language, accent, pace, emotional register, and background-noise environment. Run plans and schedules let you define sustained, scheduled load against a given agent configuration, not just a one-off happy-path call. Every call is scored against Roark's audio-native metrics, which look at the sound of the call and not only the transcript: pronunciation, pace and pauses, interruptions, vocal stress. A ramp or a soak is a regular simulation run, scored exactly the way a single call is scored, so "quality under load" stops being a separate instrument.
When a real production call breaks something at peak, Roark's production call replay turns that captured call into a repeatable regression test, so the exact traffic shape that broke you on Wednesday is in the launch suite forever after. The one-click integrations for Vapi, Retell, LiveKit, Pipecat, Bland, and ElevenLabs mean the tests attach to whatever stack you built the agent on, not a new one you have to port to.
A launch-gate checklist
Before any new voice agent (or any meaningful prompt, model, or tool change) gets the phone number, these should be green:
- Carrier CPS and concurrency ceilings confirmed in writing by the provider, at 1.5x projected peak.
- Model-provider rate limits confirmed in writing, with alerting below the 80% threshold.
- Ramp test passed: linear ramp to projected peak, no degradation in p95 first-audio latency, no increase in dead-air p95.
- Soak test passed: 30 to 60 minutes at projected peak, no memory or session leak, metrics flat.
- Burst test passed: 2x to 3x projected peak for 60 to 120 seconds, with graceful queueing and no per-call quality cliff.
- Chaos test passed: at least one dependency 503'd mid-load, with a defined, tested fallback behavior.
- Production replay suite extended with the last three post-launch incidents, re-run green on the candidate build.
The pitch that sold your voice agent was concurrency. The QA that defends it should be too.
