Voice Agent Engineering — Nik Caryotakis, SuperDial

Hey everyone. I'm Nik, I'm an engineer at Superdial, and first of all, big thanks to the organizers. This event has been awesome. I've had a blast talking to you guys, connecting with you guys, and hearing all these great talks.

Somehow I'm one of the few Voice AI talks today and this weekend, so I have a lot to cover. We're going to diveright in. If you're new to Voice AI, I hope I can provide a nice little framework to think about this very fast-moving space.

And if you're building with Voice AI already, I'll be sharing some little anecdotes from our own scaling journey that I hope will help yours as well. So, Voice AI in 2025: extremely exciting. We're seeing these new smart, really fast, really affordable LLMs that are supporting a lot more complex conversational use cases.

But you still kind of need some tricks to take your chat agent and turn it into a voice agent. We have these low-latency, really realistic, super generative text-to-speech models. But sometimes we have audio hallucinations, and we have to deal with things like pronunciation and spelling.

With all the new things that people are building, there's this explosion in Voice AI infrastructure and tooling and evaluation systems. And the big question becomes: what's actually worth owning? And the big one on everyone's mind are these new speech-to-speech or voice-to-voice models.

And our take is that for a lot of production applications, they're not quite yet ready. And a big reason for that is they start to output things that aren't actually speech, aren't actually

things that you can use to build a reliable conversation. And we saw this when they first came out. They were imitating people's voices. And from the start, that's why we've kind of been favoring reliability over this sort of realism.

So today, I'm going to talk about how we at Superdial approach agents as a service, how we think about the Voice AI Engineer, and the last-mile problem. So once you have your little voice MVP, all the challenges that you're going to face trying to actually make it reliable and put it to work.

So at Superdial, we're in the business of phone calls. Specifically, one of the most annoying phone calls ever: that phone call to your insurance company. So for mid to large-sized healthcare administration businesses, we sell the Superdial platform. And with Superdial, you can build your script.

So design the sort of conversation, ask all the questions that you need to get answered over the phone. You send us your calls via CSV, API, or we also integrate with a lot of EHR software systems. And then within the next couple of hours, in the next day, we send you back your results in a structured format.

And this makes for a really interesting agentic contract that we sort of have with our customers. So from their perspective, they're paying for results. They tell us who to call, which questions to ask, and we tell them the answers.

Internally, we have a little agentic loop set up so that

we go out, we wait for these offices to be open, we wait for the call centers to open so we can actually make these calls, we will attempt to make the call with our voice bot, and then if our voice bot needs to bring in a human to complete the call or cannot complete the call after a certain number of attempts, then we send it to a fallback team.

And this is something that, of course, we're transparent with with our customers. In fact, it's a benefit to them because it's kind of inevitable with these healthcare phone calls that sometimes you need to bring in a human. So with us, they know that no matter what happens, the call will get made.

Whether or not it gets made with a human or a bot doesn't matter to them. They get their answers reliably and in a structured format.

And with all these calls, we try to do our best to learn from them. So we'll update the sort of office hours for the given phone number we're calling and learn from the sort of phone tree traversal that we just tried.

So that when we call it again, we get even better at that sort of call. And because these are sensitive healthcare phone calls, we want to make sure our system always works. So randomly, we'll take out some of these calls, audit them, make sure everything's working.

For a quick little demo, this is actually a prior authorization call. This is after the point where we've traversed the little phone tree by clicking theright buttons, and now we're talking to a human and trying to get some questions answered for a customer.

May I know your first name?

Hi.

This is Sarah.

Are you calling from a doctor's office or from a facility?

I'm calling from a provider's office.

Do you have a member ID or a case number?

The member ID is.

What is the CPT code?

The CPT codes are 81243.

Okay, hold on.

So there's a case on file that was initiated for the code 81243. It is pending. So this case number is.

And we have not received any clinicals for this case yet.

Okay. What is your name again, and what is the reference number for this call?

My first name is. You may have the pending case number as a call reference number, and the fax number on where to send the clinicals is.

Thanks so much for your help.

You're welcome. Thanks for calling. Have a great day.

So that's it. If that call was really boring to you, thanks.

If that call was really boring, that's kind of just how these things go. A boring call for us is an excellent call because it turns out a lot of work is boring. So with this system, we've been able to save over 100,000 hours of human phone calling time, and we're on track to save millions more in 2025.

And what's really incredible about Voice AI today is that we did this with a really lean team of four engineers. So building the whole full-stack web application, these EHR integrations, the bot you just saw, all while bringing on new customers, supporting new conversational use cases really quickly.

And a big part of why that was possible was because we really all embrace this role of a Voice AI Engineer. So let's kind of uncover what's unique about a Voice AI Engineer today and what hats they may be wearing.

So starting from switches like original draft, we can kind of see that a Voice AI Engineer is going to deal with multimodal data. So MP3s, audio bytes, in addition to transcripts, you're dealing with transcription models, voice models, speech-to-speech, all that sort of thing.

The application you're building, it's in real time. Latency all of a sudden matters so much more. You're going to be dealing with async in Python a lot more than you probably want it to be doing. And the product constraint here is almost always going to be a voice conversation.

So people have really high expectations of how these sorts of conversation goes. For us, we're slotting ourselves into an existing sort of business interaction, and people expect us to be conversational and fit into that use case. So to grapple with all these challenges, we kind of have two sayings at Superdial that we've been saying over the past year and a half: say theright thing at theright time, and build this plane while we fly it.

So the trickiest part for us is customizing all these scripts and all these use cases for each customer individually. And then we really rely on this kind of horizontal Voice AI stack to help us out with all those other problems.

And this is kind of how we think about the Voice AI Engineer today, and it's unique roles. And in the larger context, we're really at this inflection point where it's so easy to build out an MVP for these sorts of applications that ultimately, what is going to make your voice bot unique isn't its voice or its interruption handling or how realistic it sounds or how it does turn-taking.

Ultimately, it's going to be in the conversational content and the design there and the vertical integrations around it that make your agents work actually valuable. And if you're like me and your favorite classes in college were the AI ethics ones, everything I just said about moving fast, building with generative AI could raise a few

alarms. So it's not hard to imagine how Voice AI apps specifically could be biased against people with certain accents, speaking certain dialects, or be really spooky when they sound so real and then say weird things. So in the US, we both enjoy and suffer from a lack of AI regulation, and that leaves the onus ultimately on the AI engineers and leaders in this room to think about these sorts of problems.

This is not going to be a talk on AI safety and ethics, but I think for Voice AI specifically, with how it's such a new modality of interaction with artificial intelligence today, I think it's really important how we go about building it.

So for AI engineers, when we go about making tooling and infrastructure choices, remember that developing AI should be really accessible and collaborative. And the work that AI does should be for everyone. And a key part in making sure that's the case is choosing tooling and infrastructure so that a really diverse set of stakeholders can be involved in that process from the start.

So with the role of the Voice AI Engineer kind of stroked out now, let's dive into some of the last-mile problems in Voice AI that we've been dealing with. So when we started out, we had a really scrapped-together pipeline of a transcription model and an LLM and then a text-to-speech model.

This was awesome to get started at, but we faced a lot of problems very quickly. And a lot of what we were learning was not new at all. So though the voice agents we see today are better than ever, Voice UI itself is not that new.

So when we were just getting started, around a year and a half ago, I had the chance to speak to Kathy Pearl, who is a close family friend and has been working on the UX of Gemini. She's been in the conversation design game for 20 years or something.

And back in the day, Voice UI was lots of phone tree design, and then it became these Alexa and Siri type things. And now we're just in this whole new world, but a lot of the principles remain the same.

And one of the biggest things that's changed with developing Voice UI is the shift from prescriptive to descriptive development. So we no longer prescribe what we want our bot to do over the course of the conversation by mapping out every possible direction that it could go.

Instead, we describe what we want to do and then kind of pray to the generative gods that it happens. And for this, there's a lot of things I'd talk about with conversation design, but it comes up really quickly when that becomes your main interface.

One thing for us is when we're asking these questions, should we be really open-ended with it or kind of constrain the user into selecting from a list of choices? And for us, because these are existing conversations, we find it's often better to just go general, hope the call center representative gives us a ton of information, and then instead of trying to prevent them from saying the wrong thing, we try to adapt to whatever they say.

So Kathy's recommendation was hire a conversation designer. If you're thinking about these sorts of problems, they're experts in this. And if you're just a Voice AI Engineer and you want to get started in this kind of thinking, a great recommendation is to do little table reads.

So have one person pretend to be the bot and the other person pretend to be a user. And the sort of transcript that you may write out by hand, immediately the sort of gaps and awkwardness of it comes out when you say these things out loud.

So knowing all these things, we were really excited to work on our conversations, but we kind of had to deal with the tech debt of the orchestration framework that we had built. So we really hit our stride when we started using PipeCat for our Voice AI orchestration.

This is an open-source framework maintained by the guys at Daly. It's really easy to extend and hack upon, which is important for our use case when we need to do transfers and stuff. And we make really long phone calls.

These can be like an hour and a half long. So a big decision for us in choosing PipeCat was that we can self-host it and deploy it and scale it how we want. So with some of our voice orchestration headaches dealt with, we really wanted to get back to focusing on our conversations.

And everything in this slide for us is really not unique to Voice UI and AI. So I'm going to kind of speed over it. Two interesting decisions we've made here because we just have an LLM in the backbone.

We chose to own our own OpenAI endpoint. We find this leads to a better interface with a lot of these new Voice AI tools. So behind our OpenAI endpoint, we can kind of route to different models that are maybe more latency sensitive.

For all of our generative responses, we route them through this tool called TensorZero. TensorZero is relatively new. They have this nice framing of LLMs. If that quote interests you, I recommend you look them up and talk to them.

They're awesome. This is a little open-source tool, so you can do whatever you want with it. They give us kind of structured and typed LLM endpoints that we can then experiment with in production. So that's our gateway to our LLM.

And then all of our logging and observability, we self-host LangFuse. And we self-host these things also because these are healthcare calls. We have to be HIPAA compliant. That's often an easier way to deal with the rapid growth of this space.

So there we do anomaly detection, evals, and data sets. So with a good plan in place for our LLM sort of work, another big challenge is our text-to-speech system. So when you make these sorts of phone calls, your password is basically your name, your date of birth, and then your member ID or something, which is like a 12-digit long string of characters that you have to be able to communicate over the phone.

And something we quickly realized was that what our LLM is outputting is not necessarily what we want to shove through our text-to-speech engine. And neither of those things may actually match what's in the recording. So a little example of this, and this is like a personal last mile, is that if you're building me a personal Voice UI application, it should say my last name correctly.

So my last name is pronounced Caryotaikis. Most people and most models will say Caryotaikis. But with a lot of new tools out there, this is the syntax this company called Rime uses. You can spell out the exact sort of pronunciations you want.

And then for things like spelling, where you may have kind of an intuition for the sort of pauses and breaks you might want to use to say a really long word, you can use something like this little spell function.

And then with all this stuff, because this is outputting audio bytes, we usually review recordings to make sure that this all sounds OK, in addition to checking the transcripts. And to start wrapping things up, I have a couple little mini last-mile problems that we've had to deal with.

Oh, and yeah, with voice-to-voice models, all this sort of rule-based stuff gets a little more complicated. So some little mini ones. We used to be called SuperBill, and we called our bot Billy because we thought that was a fun name.

Turns out that's an awful name over the phone because we would constantly have these conversations where people were like, "Hey, nice to meet you, Billy." And we would say, "It's Billy, not Billy."

So yeah, think about your persona a lot. Dial that in early. If you're just starting, don't build from scratch. What's going to make your bot unique is the conversation. And there are so many new tools out there like PipeCat that you can use to get a quick jump start.

Track latency everywhere. Time to first byte for each of your little processors is the new most important metric and is something you always kind of have to keep an eye on. Upgrade paths. This is a big one for us when we need to make sure we have really high transcription accuracy.

So we use DeepGram for our speech-to-text engine. And we know that whenever we kind of want to improve that part of our system, we can work with them to fine-tune a better model. Have fallbacks ready. It really sucks when OpenAI goes down for a little bit and all of a sudden all the concurrent conversations you have are just down the drain.

So have fallbacks ready for each part of your stack. It's really easy to set that up with something like TensorZero. There are lots of other tools that will help you figure that out. And then end-to-end testing. This is pretty unique for Voice UI or Voice AI.

It seems like people are kind of settling on telephony as a boundary layer to test your bot with an external service. We do a couple different things. The easiest test for us is to create a kind of fake phone number that just plays an MP3.

If your bot can't talk to an MP3, then you probably have bigger problems. Next, we can kind of create a simulated voice tree with different phone tree building tools and have our bot pseudo-navigate it. And then there's lots of generative services like COVAL and Vocer where you can have your bot talk to another bot.

So some takeaways for a quote-unquote "vertical" Voice AI engineer. Choose your stack wisely. The better decision you make here, it will allow you to focus on the things that are really, truly unique to your conversational experience. Laser focus on the last mile because this is where ultimately you can provide a lot of value and put your agents to work.

And then ride the wave. There's so much new stuff happening in this space. And whenever new models come out, you want to be able to use them quickly. And you also want to be able to use them safely.

So thank you very much. I'm excited to talk to you all and hear about what's so special about your conversations.