The question I get most from CTOs isn't about which LLM to use or which STT provider has the best benchmark. It's some version of "We tried a no-code voice builder, the demo looked great, and now we can't ship it." The root cause is almost always that the team doesn't own the code.

When you build on a visual, no-code interface, you're constrained to whatever the builder anticipated you'd need. If you want your agent to handle a specific dialect, integrate with a proprietary internal API, or execute a branching workflow that's three layers deep, you're either blocked or you're waiting on a vendor roadmap. In code, those things are trivial. There's a long tail of millions of small tasks that an enterprise voice agent needs to handle, and no visual interface can anticipate them all. That's why Derek and I landed on a code-first architecture what we think of as AWS Lambda for voice agents. Serverless, event-driven, arbitrary code execution. Speech comes in, your code runs, speech goes out. It's your code, not ours.

The data problem is equally serious and less discussed. Say you're a platform company with third parties building voice agents on top of your APIs. Every reservation, every support call, every transaction is data you've always owned. You know every click on your web interface. You know every recommendation you served. But the moment a third-party voice agent handles that interaction, you're blind. You don't know what happened, what the agent said, what logic it executed, or why the call ended the way it did. That's a strategic problem. And the only real fix is owning the code that runs the agent.

For regulated industries such as banking, insurance, and financial services, this becomes more acute. If a bank wants to deploy a voice agent, it needs to be able to tell its security team exactly where the data lives and what code is running on it. You can't do that with a black-box third-party solution.

The rollout strategy I recommend for any enterprise, especially in financial services, is incremental by complexity. Start by ripping out the IVR menu. You don't need to integrate into core banking software to do that. You just need natural language routing that understands intent and transfers appropriately. That's high-value, low-risk, and you can ship it fast. Then go case by case, in increasing order of complexity (credit card fraud reporting, account inquiries, loan status). Each one gets you deeper into the core systems, but you're building on a known foundation and generating real production data to inform the next step. The teams that try to boil the ocean in one deployment are the ones that stall.

The other thing I tell CTOs is to think about extensibility now. You don't know what your AI stack is going to look like in two years. Maybe you're building a custom credit scoring model that your voice agent will eventually need to call. Maybe you're integrating a new CRM. If your voice agent is built on a no-code platform, adding that integration is someone else's problem on someone else's timeline. If it's built-in code you own, it's an API call. That's the compounding advantage of a code-first approach, not just what you can do today, but what you can do as your systems evolve without having to rebuild from scratch.

Two Deepgram and AWS engineers walk through the architecture for replacing nurse-staffed outbound calling in healthcare with voice AI agents, using clinical trial recruitment as the live example. CROs screening thousands of patients for medication changes, lifestyle status, and eligibility criteria can't do it fast enough with humans, and IVR trees can't handle the clinical nuance. The session shows two working reference architectures (SageMaker + Bedrock, and Amazon Connect + Lex), both running Nova-3 Medical for STT and Aura-2 for TTS, each under 250ms. Details →

EmTech AI is MIT Technology Review's flagship technical conference, designed specifically for decision-makers and senior engineers evaluating emerging AI systems for enterprise deployment. The 2026 agenda covers AI infrastructure, agentic systems, and real-world deployment challenges, with a deliberate focus on technology through the lens of business and operations. Details →

Ai4 is one of the largest applied AI conferences in the US, with 12,000+ attendees, 1,000+ speakers, and dedicated industry tracks across healthcare, financial services, retail, and aerospace. The format prioritizes real deployment case studies, with sector-specific sessions focused on how teams are operationalizing AI within existing enterprise constraints, integration complexity, compliance, workflow redesign, and performance under load. Details →

Based on Speechmatics' own production data combined with deployment case studies across healthcare and financial services, this report highlights that real-time agent usage grew 4x year-on-year in 2025 and demand shifted from batch analytics to in-the-moment response. On latency, teams are pushing toward ~250ms for transcript finalization, with new architectures decoupling turn detection from silence buffering to eliminate the 700–1000ms waiting tax imposed by traditional engines. Domain-tuned models (medical, legal, financial) show up to 70% fewer keyword errors versus general-purpose systems, and that gap is now driving regulated-industry procurement decisions. Y Combinator's most recent batch has nearly one in four companies building voice-first products, up 70% up from early 2024. Read →

Carter Huffman, CTO of Modulate, makes the case for ensemble architectures over monolithic STT pipelines in production voice systems. The episode covers how Modulate's Ensemble Listening Model routes audio dynamically across specialized models rather than running everything through a single general-purpose stack and why that tradeoff matters for latency, accuracy under noisy conditions, and silent failure detection. Useful for any team hitting quality ceilings with a single-provider ASR setup and unsure where the degradation is actually coming from.