In the space of thirteen months, Google took real-time speech translation from an English-and-Spanish demo at I/O 2025 to Gemini 3.5 Live Translate, a 70-language streaming model announced in June 2026 and now expanding into Google Meet through private preview, on top of the five-language version already generally available there. That speed says something: real-time translation is fast becoming a baseline expectation, not a differentiator.
That shift won’t stop at video conferencing. Contact centers, telehealth, education platforms, field service tools, and customer support will all face the same expectation soon. Once translation becomes a standard feature, buyers will stop asking whether a product can translate a sentence. They’ll start asking whether it holds up inside a real workflow, under real network and compliance conditions.
What does meeting that expectation actually require? We built a real-time translation agent on SignalWire, a telecom platform we partner with. Here’s what it took, and where a real deployment would need to go further.
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.
Case Study: A SignalWire AI Agent for Real-Time Translation
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:
