In the space of thirteen months, Google took real-time speech translation from an English-and-Spanish demo at I/O 2025 to a 70-language streaming model with enterprise distribution in June 2026. The pace matters more than any single launch: real-time translation is moving from a differentiator to a baseline expectation, and it’s moving there fast.
The same expectation will spread past video conferencing into contact centers, telehealth, education platforms, field service tools, and customer support. Once a capability becomes standard in the products people use every day, buyers stop asking whether AI can translate a sentence. They start asking whether that AI agent delivers the translation reliably, inside a real workflow, under real network and compliance conditions.
What Real-Time Speech Translation Actually Requires
A language model can translate text. A real-time translation agent has to do far more than that. It has to capture audio, run speech recognition, translate, generate speech, manage telecom signaling and call state, and recover gracefully when any part of that chain fails.
In conferencing and contact center environments, latency and turn-taking decide whether the experience feels natural or broken. A production system has to handle pauses, interruptions, partial utterances, accents, background noise, and domain-specific vocabulary. And it needs observability across the media layer, the AI layer, and the application layer, not just a green checkmark on an API response.
This is the gap between an impressive demo and a system a business can depend on. Closing it is systems engineering work, not prompt engineering work.
A Case Study: A SignalWire AI Agent for Real-Time Translation
To explore this space directly, we built a real-time translation agent on top of SignalWire, a telecom platform we partner with. The project is a Python FastAPI service that exposes SignalWire-compatible endpoints. On the live PSTN path, SignalWire’s LaML layer gathers a caller’s spoken phrase, sends it to the application, translates it, speaks the translated response back in Spanish, and loops for the next phrase.
The application uses OpenAI’s Responses API for unscripted translation when configured, with a deterministic fallback path for local demos and safer testing. The repository also keeps an SDK/SWML path available for richer agent-oriented orchestration and tool routing through SignalWire’s AI Gateway (SWAIG).
We’re treating this as an architecture exploration and an MVP, not a production-ready product. The code and README are public on GitHub.
What the demo gets right:
- A clean SignalWire-facing contract, with routing decisions kept separate from turn translation
- Health and readiness endpoints and structured logs, both essential in a real-time system
- A deterministic fallback path so local demos and smoke tests can run without depending on a paid translation provider
- A turn-by-turn flow that is realistic for early telecom validation, even though it isn’t full-duplex
The Production Gap: Full-Duplex, State, and Compliance
Full-duplex interpreting needs a bidirectional media bridge, not a gather-and-respond loop. Production translation needs streaming speech-to-text, streaming translation, and streaming text-to-speech running in both directions simultaneously.
Because this demo runs on SignalWire, a production build can lean on SignalWire for a lot of the telecom and media layer: call handling, interruption handling, reconnection behavior, media lifecycle, and detailed call logs. But the application still has to own its own session state: language direction, participant context, translation state, user permissions, routing decisions, and the business rules that govern each conversation.
Telecom call logs are useful, but they are not a system of record. A production deployment needs its own strategy for audit trails, consent records, transcripts, quality metrics, and evaluation datasets, and it should consider a standardized format like vCon for representing calls and conferences. It also needs authentication, tenant isolation, role-based access control, data retention policies, and a compliance review. And scaling WebRTC itself, particularly for multiparty conferencing or high call volumes, is a separate engineering problem on top of all of this.
A Reference Architecture: Separation of Concerns
The pattern we’d point teams toward for a real-time translation architecture looks like this:
- SignalWire (or an equivalent telecom platform): PSTN, SIP, and WebRTC entry points, call control, and the LaML/SWML signaling layer
- Application service (FastAPI in our demo): business logic, routing, the translation contract, and observability hooks
- Translation provider: swappable behind a clean interface, OpenAI Responses in our demo
- Agent tools: functions for route initialization and turn translation, callable through the telecom platform’s tool-routing layer
- Persistence layer: sessions, transcripts, audit logs, metrics, tenant configuration, and evaluation data
- Media bridge: for full-duplex production use, low-latency bidirectional audio between participants and AI services
The caller connects through the telecom platform, into an orchestration service, through a speech-to-text, translation, and text-to-speech pipeline, and back out to the other participant. Observability, persistence, and human escalation sit alongside that pipeline as sidecar components, not afterthoughts.
Build or Integrate: Two Paths for Engineering Teams
Built-in platform translation, like Google Meet’s, will cover a large share of generic meetings well. Enterprises with specialized workflows, specific language pairs, domain vocabulary, compliance obligations, routing logic, or CRM and contact center integration will often need more control than a platform default provides.
Vendor APIs accelerate time to market. Teams should still design the architecture so switching vendors later doesn’t mean rebuilding the system. Open-source components offer control and transparency, at the cost of hosting, scaling, and ongoing maintenance the team now owns.
For most teams, the practical answer is hybrid: use strong vendors for commodity capabilities like transcription or base translation, and own the orchestration, session state, compliance, and integration logic yourself.
What This Means for Engineering Leaders
Real-time translation can expand a company’s addressable market, improve support access for non-native speakers, and make distributed teams more effective. It also resets user expectations. People will judge every product’s translation experience, including contact center translation, against the best built-in options from major platforms.
Differentiation will come from workflow fit, reliability, domain accuracy, data governance, and the quality of operational support behind the product. Translation belongs in the core communications stack now, not treated as a novelty add-on to evaluate later.
Why We’re Focused on This Space
WebRTC.ventures has spent years building telecom, conferencing, and real-time media systems. The current wave of real-time speech AI is a direct extension of that work. Media paths, latency budgets, call orchestration, recording, monitoring, and user experience still matter as much as they did before AI entered the picture.
Teams evaluating real-time speech translation often start by testing a model’s translation quality and end up running into the same voice AI production challenges everyone does: getting audio in and out reliably, managing session state, and building the observability to know when something breaks. That’s the layer we help teams build.
Our work spans:
- WebRTC architecture and media paths
- Voice AI architecture and orchestration
- Telecom integrations
- Vendor selection and integration strategy
- Testing, monitoring, and observability
- Production support and long-term maintenance
How WebRTC.ventures Can Help
If your team is evaluating real-time translation, conversational AI, or AI-enhanced conferencing and contact center workflows, WebRTC.ventures can help you move from a working prototype to a production architecture. Our work as a voice AI implementation partner spans architecture review, prototype development, production hardening, WebRTC implementation, SignalWire integration, orchestration frameworks like Pipecat, vendor evaluation, monitoring, testing, and long-term support.
Reach out to talk through your architecture.
References:
