The annual ClueCon conference founded by the creators of FreeSWITCH has always been where the real-time communications community gathers to share what’s working, what’s breaking, and what’s next. This year’s edition, August 10-14 at The Midland Hotel in Chicago, made one thing unmistakably clear: AI is no longer a side experiment in the telecom world. It’s embedded in production systems, and the conversation has shifted from ‘look what AI can do’ to ‘how do we stop it from failing at scale?’.
That question got an answer before the first talk even started.
What We Learned: AI Engineering, Observability, and Trust
Anthony Minessale (FreeSWITCH creator and SignalWire CEO, “Real-Time Infrastructure Meets AI Intelligence”) set the tone in his keynote. His message was about building on the shoulders of giants rather than reinventing infrastructure from scratch. The analogy: building an OS from scratch might be fun. But if something like Linux already exists, you should focus your energy on your product rather than building a whole OS before you can build what you actually want to ship.
Applied to voice AI: the telephony layer, the media handling, the protocol negotiation: that infrastructure already exists and has been battle-tested for more than twenty years. Build your AI on top of it rather than trying to assemble it from raw components. It was a natural opening for a conference where every subsequent talk dealt with how to make AI reliable inside existing real-time communications systems.
The conference ran its signature single-track format: three days of technical talks, the Coder Games hackathon on day one, AI workshops, Dangerous Demos, and the networking events that make ClueCon feel more like a reunion than a conference. Speakers included engineers from Meta, Barclays, SignalWire, and the open-source projects (FreeSWITCH, Kamailio, Homer) that underpin much of the world’s voice infrastructure.
The range extended beyond pure engineering, too. Laura Blersch’s session on neurodiversity and team dynamics was a welcome reminder that building great systems requires building great teams first.
The model matters less than what you build around it
If there was a single thread running through ClueCon 2026, it was this: the LLM is the least interesting part of a production voice AI system. Adam Kalsey, EVP of Product at SignalWire, put it most bluntly in his talk “Everyone’s Building Voice AI Wrong and You Already Know the Fix.” Voice AI didn’t invent a new class of engineering problem, it resurfaced an old one about where you draw the boundaries between system components. Except now, the cost of getting that boundary wrong is a dead phone call instead of a slow webpage. What matters is the engineering that wraps it: the guardrails, the tool sandboxes, the deterministic control logic, and the latency budgets.
Multiple sessions, including SignalWire’s Head of Developer Experience and a FreeSWITCH founder, Brian West’s talk on Wednesday, “Shut Up and Ship: What Carrier-Grade Voice AI Actually Looks Like” converged on the same conclusion. ‘Prompt and pray’ doesn’t survive contact with real callers. You can’t stuff business logic into a system prompt and hope the model follows it consistently under load. The systems that work in production let code drive the conversation, using the LLM for what it’s good at (natural language understanding and generation) while keeping everything else deterministic.
The strategies that kept surfacing across talks:
- Deterministic gates for critical actions (Kishor Patil, Senior Engineering Manager at Best Buy, “Securing Agentic Workflows at Enterprise Scale”): Never let the LLM decide whether to authorize a payment, escalate a call, or access sensitive data. Hard logic gates must sit between the model and any consequential tool or action.
- Multi-agent architectures (Devang Sharma, Senior Engineer at Meta, “The Agentic Shift: Designing Multi-Agent Systems That Actually Work in Production”): Instead of one monolithic agent trying to handle everything, decompose into specialized agents with scoped responsibilities. Each agent gets a thin prompt, limited tools, and clear boundaries. When one fails, the blast radius is contained. This concept is well-demonstrated in a recent WebRTC.ventures project that combined six purpose-built Gemini-powered agents.
- Deterministic logic for script adherence (Justin Massey, founder of Relay Hawk, “Building an AI Voice Agent That Answers Real Customer Calls While Staying Provably On-Script”): If your agent must follow a specific conversation flow such as compliance, intake, or verification, encode that flow in code. The LLM fills in the natural language, but the state machine decides what happens next.
- Thin prompts + scoped tools (Brian West’s “Shut up and Ship” referenced above): Minimize what the model needs to decide. Maximize what code enforces. The less you ask the LLM to remember and manage, the more predictable it behaves. West’s talk introduced a concept called “System Directed AI,” which separates code-driven business logic from AI-driven conversation, plus a technique called zero-argument tool calls, where the agent reads from validated stored state instead of re-supplying data on every turn.
Privacy, security, and vCons: the trust layer for voice AI
Multiple sessions addressed the security surface of voice AI in production. Not just model-level concerns (jailbreaking, prompt injection) but the infrastructure-level questions: where does audio go, who has access to transcripts, how do you audit what an AI agent actually said to a customer?
One compelling answer emerging from the community is Virtualized Conversations (acronym vCon), an emerging, standardized format for packaging and exchanging conversation data. Jeff Pulver, founder and chair of the vCon Foundation, made the case for this at ClueCon in his talk, “What Voice AI Needs from Telecom in Order to Live to Its Potential and How vCons Fit In”.
As voice AI scales into regulated industries, organizations need a portable record of what happened during an interaction: what was said, who participated, which systems processed it, and what analyses or actions followed. vCon is designed to bring those artifacts together in a structured container, while supporting mechanisms for protecting privacy and proving the integrity and, optionally, authenticity of the data.
The IETF vCon Working Group currently has four active Internet-Drafts. This provides a foundation for representing human participants and AI agents within the same conversation record, while preserving their distinct roles. That direction aligns with the architecture discussed in the WebRTC.ventures blog post, Voice AI Conversation Records: Why vCons Belong in Your Production Architecture.
The open-source SIP/VoIP stack is maturing too
Production voice AI doesn’t exist in isolation. It runs on top of infrastructure that needs to be observable, secure, and fast. Two projects showcased significant evolution at ClueCon:
- Homer 11 (Rita Lopes, “When Your Network Calls You Back: AI-Driven Voice Alerting with Homer11” and Jachen Duschletta, Homer Lunch N’ Learn session, both from QXIP/Homer) is a complete rewrite of the open-source SIP capture and monitoring platform. It is now a Go monolith powered by DuckDB and Apache Arrow/Parquet in a DuckLake architecture. An all-in-one system (writer, reader, coordinator, compactor, API) with support for MCP-based LLM/agent integration, VQRTCP QoS collection, SIPREC signaling, and AI-driven voice alerting. For anyone running SIP infrastructure alongside voice AI, the observability story just got dramatically better.
- Kamailio (Daniel-Constantin Mierla, “Safe and Secure Communications with Kamailio” and Fred Posner, “What’s New with APIBAN and Kamailio”), focused on security hardening, addressing the reality that SIP infrastructure remains a prime target. On the release side, version 6.1 brings multi-threaded TLS processing, continued UDP multi-threading improvements from 6.0, ARM support, and a CMake-based build system for easier cross-platform compilation.
These tools matter because when your voice AI agent drops a call, you need to know whether it was the model, the network, or the SIP layer. Observable infrastructure is a prerequisite for reliable AI.
Our Talks
WebRTC.ventures was there as a sponsor and with two presentations:
Alberto Gonzalez: Deterministic Telephony Meets Real-Time Voice AI
WebRTC.ventures CTO Alberto Gonzalez presented an open-source, production architecture for running Voice AI inside a deterministic telephony system. The core idea: the AI handles the conversation, but it never controls the call.
FreeSWITCH enforces routing rules, timeouts, fallback paths, and session state. Live audio streams through STT, inference, and TTS, but the telephony layer owns the call lifecycle.
A full write up of that presentation is here: The Control Plane Between What a Voice Agent Hears and What It Does.
Hector Zelaya: eBPF Makes Python a Good Language for a TURN Server
My talk addressed a different layer of the production stack: media transport performance.
TURN servers are essential for WebRTC: they relay media when direct peer-to-peer connections can’t be established due to NAT or firewall constraints. That makes them critical infrastructure for any WebRTC-based voice AI system. The problem: they’re also a bottleneck. Every relayed packet crosses from the kernel’s network stack into user space and back again, adding latency at each hop.
eBPF allows us to change that equation. It lets developers attach custom programs directly to the Linux kernel’s networking hooks, processing packets before they ever reach user space. The result: you can keep your TURN server’s control logic in a high-level language (yes, even Python) while offloading the hot path — raw packet relay — to eBPF programs running at kernel speed.
I’ll be posting a full writeup of my talk soon.
What We’re Taking Home
ClueCon 2026 made it clear: AI in real-time communications is no longer optional or experimental. The builders at this conference aren’t asking whether to use AI. They’re asking how to make it reliable, observable, and fast enough for production telephony.
This requires better engineering: deterministic control planes that don’t depend on model behavior, observable infrastructure that tells you exactly where a failure occurred, performance-optimized media paths that don’t add latency to an already tight budget, and standardized trust layers that let you audit what happened in every conversation.
At WebRTC.ventures, we’re applying all of this daily: deterministic voice AI architectures, optimized transport, and the latest open-source SIP and observability tooling. If you’re building voice AI for production and hitting the wall where demos stop working with real users, we’ve been on the other side of that wall. Let’s talk about what production-ready looks like for your use case.
