A translated support call looks simple from the outside. A customer speaks in Spanish. The agent responds in Spanish. Somewhere in the middle, software converts one language into another.

Useful enough as a surface description. Misleading as a product architecture.

Inside a real contact center, translation is only one part of the job. The system must hear the customer, detect the end of a turn, transcribe speech, translate meaning, preserve context, reason over policy, call tools, speak back naturally, and record the interaction in a way the business can use. Miss any step and multilingual support becomes a language feature bolted onto a broken workflow.

Real-time voice translation in contact centers should therefore be understood as a runtime system. Speech, translation, reasoning, and action all operate inside the same live customer-support loop.

For Giga, this matters because multilingual support is not merely a coverage claim. It is a resolution claim. Customers should be able to speak in the language they actually use while the agent still completes work inside the support operation. See how Giga frames the broader voice surface in Voice Experience and the broader automation layer in Contact Center Automation.

The old model: translation as a sidecar

Most multilingual contact center architectures grew from staffing and routing assumptions. A customer selects a language. The call enters a language-specific queue. A bilingual agent or interpreter becomes available. The customer repeats the issue. A translated summary or note may be captured afterward.

For many organizations, this model still works in high-volume languages and predictable support scenarios. It breaks when language coverage gets wider, support issues get more operational, and customers expect fast resolution instead of routing ceremony.

Translation tools can help, but they often sit outside the core support workflow. A representative may use a translator, but the support system itself still thinks in separate pieces: call recording here, translated transcript there, agent notes somewhere else, ticket summary edited after the fact.

Fragmentation creates three practical problems. Latency increases because every handoff adds delay. Context gets thinner because translated notes rarely preserve full intent. Measurement becomes weaker because the support record no longer reflects one clean operational path.

Language access improves. Resolution discipline does not.

The new model: translation inside the support runtime

A real-time translation voice agent changes the unit of work. Rather than routing the customer out to a separate language path, the system keeps the customer inside one live support loop.

Customer speech
→ speech recognition
→ translation
→ agent reasoning
→ tool or browser action
→ translated spoken response
→ canonical ticket
→ measurable outcome

Each stage must be fast enough and stable enough for a live conversation. Speech recognition produces a transcript. Translation carries customer intent into the agent’s working context. The agent reasons over policy, knowledge, and available tools. A response is translated back into the customer’s language and spoken aloud. Actions and evidence are captured into one support record.

Google’s Gemini Live API documentation describes the broader market shift toward low-latency, real-time voice and video interactions for agents, while Microsoft’s Speech Translation documentation describes real-time speech-to-speech and speech-to-text translation over audio streams. Those platform references are useful because they show the underlying primitives becoming broadly available. The product question now moves one layer up: how does the support system use those primitives to resolve work?

Giga’s opportunity is to make the answer support-specific. Translation should not float above the operation. It should become part of the same system that handles policies, tools, tickets, agent behavior, and measurement.

A contact center translation system has more than one latency budget

Voice makes latency visible. A slow chatbot feels annoying. A slow voice agent feels broken.

Real-time translation introduces several latency budgets at once: end-of-turn detection, transcription, translation, retrieval, reasoning, tool use, text-to-speech, and audio playout. A buyer may ask for “low latency,” but that phrase hides a stack of tradeoffs.

Turn detection is one of the easiest places to underestimate complexity. LiveKit’s documentation describes turn detection as the process of determining when a user begins or ends their turn so an agent knows when to listen and when to respond. Its recent writing also points out that VAD-only systems can interrupt incorrectly because silence does not always mean the user is done speaking.

Translation compounds this problem. A pause may mean the customer is finished. It may mean the customer is searching for a word. It may mean the customer is switching languages. It may mean background noise caused an incomplete transcript. A multilingual voice runtime needs more than speed. It needs judgment about when to move and when to wait.

Latency is not only a performance metric. It is the size of the agent’s thinking window.

The customer hears language. The system sees a workflow.

A customer should not need to understand any of this. From their side, the call should feel simple: speak naturally, confirm details, get the issue handled.

Underneath, the agent may be doing several jobs at once. It may be translating the customer’s speech, checking account context, opening a browser workflow, reading policy, preparing a next action, and deciding whether the current issue is safe to resolve automatically. Giga’s Browser Agent matters in this context because voice can create a conversational surface while backend work happens underneath.

This is one of the hidden advantages of voice. Spoken interaction gives the system a small amount of useful time. A well-designed agent can use that time to retrieve records, validate policy, and prepare the next step without making the customer feel like nothing is happening.

The customer hears a conversation. The system runs a workflow.

One conversation should become one ticket

Real-time translation creates a record-keeping problem. A customer speaks in one language. The agent may reason in another. The spoken answer may be translated back. A human reviewer may need to see both the original wording and the operational summary.

A weak implementation creates fragmented records. Original transcript in one place. Translated text in another. Agent summary in a third. Action history somewhere else. Managers can read the ticket, but they cannot reconstruct the support event with confidence.

A stronger implementation creates one canonical ticket. The ticket should preserve original utterances, translated meaning, agent actions, policy context, handoff reason if any, and resolution outcome. This matters for QA, analytics, compliance, and future improvement work.

Translation should not create two support histories. It should create one operational truth.

What buyers should evaluate

A buyer evaluating real-time voice translation should look past the language count. “Supports 99 languages” is useful only if resolution quality holds across the languages that matter to the business.

Strong evaluation should include:

·End-to-end latency by language pair

·Turn-taking quality and interruption handling

·Translation fidelity for domain-specific terms

·Tool success during translated calls

·Fallback and escalation behavior when confidence is low

·Canonical ticket quality

·Resolution rate by language

·Repeat contact by language

·Human handoff rate by language

Language coverage is the visible promise. Operational consistency is the real product requirement.

Where real-time translation works best

Real-time voice translation is strongest when the support task has clear policies, known tools, and measurable outcomes. Delivery updates, appointment scheduling, account verification, plan questions, order changes, and routine exception workflows are all natural candidates.

More ambiguous cases still need care. Legal disputes, severe customer distress, complex medical nuance, fraud concerns, and high-value exceptions may require human judgment. The point of a mature multilingual agent is not to automate every call. It is to resolve the right calls and escalate the rest with better context.

This is also where Agent Canvas becomes relevant. Multilingual behavior needs policies, scenarios, tools, handoff logic, and testable workflow design. Translation is the surface. Agent configuration is the control layer.

Bottom line

Real-time voice translation in contact centers is not a novelty layer. It is a new way to design multilingual support around resolution instead of routing.

A customer should be able to speak naturally. The agent should be able to reason and act. The support record should remain whole. The business should be able to measure whether the issue was resolved.

Anything less is translation without operations.