The state of voice AI, from someone who ships it
I've spent the last year and a half building voice systems for real businesses — plumbers who need someone to answer at 2am, HVAC companies losing jobs to hold music, property managers drowning in "is my package here" calls. Not demos. Not proof-of-concepts. Systems that answer real phones and handle real money.
So I want to talk about where voice AI actually is right now, not where the hype says it is. Short version: it's genuinely good. Better than I expected a year ago. But there are still seams if you know where to look, and if you're building on this stuff for clients, you need to know where those seams are before your client's customer finds them.
Latency: the problem that's basically solved
Eighteen months ago, voice AI had this awkward 1.5-2 second lag between when someone stopped talking and the AI started responding. It was fine for a demo. It was brutal on a real call — people would talk over the silence, assume the line dropped, hang up and call the actual business's cell number instead.
That's mostly fixed now. Streaming architectures — where the model starts generating a response before the full transcript is even finalized — have pushed response times down to something close to human conversational rhythm. Deepgram has been especially good on the transcription side, with their streaming STT models cutting down the "hearing" lag significantly. Combine a fast STT layer with a fast LLM and a low-latency TTS engine, and you get something that feels like a real pause in conversation instead of a buffering wheel.
This is the unlock that made full autonomous voice agents viable for something as latency-sensitive as an emergency plumbing call. Nobody's going to wait three seconds to hear "let me get someone out there" when their basement is flooding.
Voice quality: also basically solved
This is the one that surprised me most. Text-to-speech used to have this uncanny valley problem — close enough to human that it was almost more unsettling than clearly robotic. That's gone for the top-tier platforms.
I've been building on ElevenLabs for Radar, and the voice quality is at a point where callers genuinely don't clock it as AI unless they're specifically listening for it. Natural pacing, believable intonation, none of the flat robotic cadence that made early IVR systems feel like talking to a parking garage kiosk. Play.ht has made real strides too, and depending on the use case it's a solid option — but for phone-specific work, ElevenLabs has the edge on naturalness and the low-latency streaming API that actually matters for real-time calls, not just pre-rendered audio.
Why does this matter so much for service businesses specifically? Because trust is the entire game on an inbound call. If someone calls a plumber at 11pm with a burst pipe, they need to feel like they're talking to someone competent and human, not filling out a form. A voice that sounds slightly off breaks that trust instantly — and a broken-trust caller hangs up and calls the next name on Google.
Where it's still rough: interruptions
Here's the part nobody puts in the marketing videos. Real conversations are messy. People interrupt. They start a sentence, change their mind mid-word, say "uh actually—" and pivot to a different question. Handling that gracefully is still one of the hardest unsolved problems in voice AI.
Most platforms handle the simple case fine: caller talks, AI waits, AI responds. Where it gets ugly is barge-in — caller starts talking while the AI is mid-sentence. Does the AI stop immediately? Does it finish its thought? Does it lose track of what it was saying and repeat itself? I've seen platforms handle this by just cutting the AI off hard, which sounds abrupt, and I've seen platforms ignore the interruption entirely, which is worse — it makes the AI feel deaf.
The systems that get this right use real-time voice activity detection tied directly into the generation pipeline, so the moment interruption is detected, generation actually stops rather than just muting audio that's already been generated. It's a genuinely hard engineering problem and honestly the biggest tell right now for "is this AI." Get it right and nobody notices. Get it wrong and every caller notices.
Multilingual: better, but uneven
30+ language support with auto-detection sounds great on a spec sheet. In practice, quality varies a lot by language. English, Spanish, French — generally excellent across most platforms now. Once you get into lower-resource languages, or languages with heavy regional accent variation, quality drops off. Pronunciation gets stiff, or the model mishears entire words in ways that break the conversation flow.
For service businesses in diverse metro areas — which is most of the clients I build for — this actually matters a lot. A caller who speaks Spanish as a first language shouldn't get a worse experience than an English speaker. It's one of the reasons I lean on ElevenLabs for anything client-facing: the multilingual voice quality holds up better across the language set that actually shows up in real call volume for service businesses, versus platforms that support more languages on paper but with noticeably rougher execution outside the top few.
Voice AI in 2026 isn't a science project anymore. It's infrastructure. The question isn't "can it work," it's "did you configure it for the actual conversations your business has."
Per-minute pricing: the quiet cost trap
One thing I don't see talked about enough: a lot of voice AI platforms bill per minute of audio processed, stacked across STT, LLM, and TTS separately. That's fine for a low-volume prototype. It gets expensive fast for a business that's actually using the system the way it's meant to be used — answering every call, all day, every day.
When I'm architecting a system for a client, I have to think about this the same way I think about database queries — not just "does it work" but "does it work at the volume this business will actually generate." A plumbing company fielding 40-60 calls a day during storm season is a very different cost profile than a demo call. This is part of why I built Radar's pricing as a flat monthly rate instead of passing per-minute costs straight through to the client — nobody should have to do mental math every time their phone rings.
What I actually use, and why
For Radar, the stack is ElevenLabs for voice, tied into a custom conversation and dispatch layer that handles the business logic — what to ask, when to escalate, how to fill in a job ticket, when to fire off a Slack alert or a QuickBooks entry. The voice model is important, but it's honestly the easy 20% of the problem. The hard part is everything wrapped around it: knowing when a call is an emergency, capturing the right details without making the caller repeat themselves, and getting that data into the tools the business already uses — ServiceTitan, Jobber, Housecall Pro, Google Calendar, whatever they're running.
That's also why Radar ships in two modes, not one. Full AI mode handles the whole call end to end for businesses ready to go fully autonomous. But a lot of shops aren't there yet — they've got a receptionist they trust and don't want to replace. For them, Copilot Mode runs Radar in the background: it listens live, pulls caller info with confidence scores, surfaces answers to pricing and availability questions on screen, and queues up every integration so the receptionist just reviews and hits "Confirm & Execute" instead of typing everything into three different systems while someone's still talking. It's the difference between voice AI as a gimmick and voice AI as an actual force multiplier for the humans already doing the job.
Voice AI stopped being a novelty this year. The tech is production-grade. The remaining gap isn't "does the voice sound real" — it's whether the system around that voice actually understands the business it's answering for.
If you're a tradesperson wondering whether this stuff is actually ready for your business, or a fellow builder curious how the integrations hold together under real call volume, reach out — happy to talk shop.
