Our Fast to Deploy series made one argument across five pieces: the shape of a deployment, not the model underneath it, decides whether a voice agent reaches production. This series picks up where that one ends. You have a live agent, launched in weeks, measured from the first call. Now it has to hold a real conversation with a customer in Jakarta, Manila, Bangkok, or Ho Chi Minh City — and that is where a different gap opens up.

The gap is between language coverage and local fluency. Coverage is what a vendor puts on a slide: a list of supported languages, a neural voice for each, an ASR model that transcribes clean read speech. Local fluency is what the customer experiences on the line: an agent that recognises their accent, follows them when they switch languages mid-sentence, matches the level of politeness the situation calls for, and understands what "waive the late fee" means in the local phrasing they actually used. The first is a procurement checkbox. The second is the thing that determines whether the call ends in a resolution or an escalation.

What is the difference between supporting a language and being locally fluent?

Supporting a language means the system can, under good conditions, transcribe and speak it. Being locally fluent means it works under the conditions customers actually create: a noisy 8kHz phone line, a regional accent, a sentence that starts in one language and finishes in another, an idiom that never appears in a textbook, and a cultural expectation about how a service interaction should sound.

Southeast Asia makes the distinction unavoidable. More than 1,200 languages are spoken across the region's eleven countries; Indonesia alone has over 700. Most enterprise customer operations run in a working set of national and business languages, but each of those carries its own accents, honorifics, and habits of mixing in English. A voice agent that treats "Indonesian" or "Filipino" as a single uniform input has technically ticked the box and functionally missed the market. This is the same point our earlier piece on localized AI agents made from the buyer's side: in this region, language, culture, and business process are inseparable, so localization is a performance requirement rather than a branding line.

Why does mainstream speech AI struggle with local accents and dialects?

Because of what it was trained on. The most-cited evidence is Koenecke et al. in PNAS (2020), which tested five major commercial speech recognition systems and found they misidentified about 35% of words from one speaker group versus about 19% from another speaking the same words — the disparity tracking how far the speaker's English sat from the variety that dominated the training data. The models were not broken; they were built on a narrow slice of how the language is actually spoken.

The same imbalance shows up one level higher, in the language models that now sit behind voice agents. AI Singapore's SEA-LION project exists precisely because mainstream LLM development is English-centric and Southeast Asian languages are under-represented in training data, which leaves global models mishandling regional nuance — formal Khmer, for instance, or the cultural context around a recommendation. A voice agent inherits whatever blind spots its ASR and its language model were trained with. If neither was built with regional speech in mind, no amount of prompt tuning fully closes the gap.

What does code-switching actually break in a voice agent?

Code-switching — moving between languages within a single conversation, often within a single sentence — is the default register for a large share of customers in Singapore, Malaysia, the Philippines, and Indonesia. "Pwede ba i-waive yung late fee?" or "Boleh tolong check my bill?" is not an edge case; it is how the call comes in.

A pipeline built for one language at a time breaks in three specific places. First, language identification: if the system decides at the top of the call that this is an "English call," it will mistranscribe the local-language portion as garbled English. Second, mid-utterance handling: the switch often lands on the most information-dense word — the product name, the action verb, the amount — so a wrong guess there loses the intent, not just a word. Third, the response: an agent that detects Taglish but can only answer in formal English has still broken the conversation, because it has forced the customer to code-switch back to accommodate the machine. The next piece in this series is a full breakdown of code-switching — where the pipeline breaks and what it costs on inbound and outbound — and the piece after that does the same for register. We also go deeper on the mechanics in language identification inside a live voice agent and on specific pairs in Taglish customer journeys and Mandarin-English switching in Singapore service calls.

Isn't this just a translation problem?

No, and treating it as one is how agents end up sounding fluent and landing wrong. Translation moves meaning between languages. Local fluency also carries register — the level of formality and deference a situation demands — and context, the local knowledge that makes a reply correct rather than merely grammatical.

Thai politeness particles, Bahasa Indonesia's formal and informal "you," Vietnamese honorifics that change with the customer's apparent age, the Filipino expectation of warmth before business: these are not decoration. Use the wrong register on a collections call and a polite reminder reads as an accusation; use it on a premium-service line and the brand sounds careless. Thai customer conversations and Bahasa Indonesia customer conversations walk through what an agent has to get right beyond the literal words. Context matters just as much: local phrasing around payments, identity checks, delivery, renewals, and disputes rarely maps one-to-one onto a translated script.

Where does local fluency show up in the numbers?

On the customer side, language is a buying condition. RWS's 2023 consumer study found more than four in five consumers won't buy from a brand that doesn't offer support in their language, and roughly 89% want the option of dealing with a company in their preferred language. The older CSA Research "Can't Read, Won't Buy" work has pointed the same direction for years.

On the operations side, the cost of coverage-without-fluency is measurable in the metrics a contact centre already tracks: containment and self-service completion rates fall when the agent can't parse mixed-language input; average handle time rises because customers repeat themselves; unnecessary escalations climb; and CSAT drops on exactly the calls where the customer felt they had to slow down for the machine. For outbound programmes run on Talkbot, a stilted or wrongly-pitched opening line costs answer and consent rates in the first ten seconds. Fluency isn't a soft attribute — it moves the same numbers a deployment is judged on.

How does WIZ.AI build for local fluency rather than coverage?

The mechanism is Language Engine, which is designed around the conditions above rather than a language list. It handles mid-call language switching — recognising customers as they move between local languages, dialects, and short replies without breaking the live conversation — and it is tuned for the call itself: streaming recognition in roughly 100ms, first audio near 300ms, noise filtering and barge-in handling on 8kHz telephony. On top of that sits scenario customisation: recognition and pronunciation adapted for product names, addresses, customer intents, compliance phrases, and brand voice, so the agent gets the load-bearing words right in each account's context.

That engine runs under both deployment shapes from the Fast to Deploy series. Wizlynn applies it to inbound service, where a customer arrives mid-problem in whatever language mix is natural to them; Talkbot applies it to outbound campaigns, where the opening has to sound local from the first second. Both draw on WIZ.AI's regional speech data and industry corpus rather than a generic multilingual base — the same flywheel described in the industry corpus flywheel for local voice AI — which is what lets accent and code-switch handling keep improving on real traffic instead of staying frozen at launch quality. It is also why our multilingual agents don't sound robotic: prosody and register are part of the model, not a wrapper on top of it.

What should you ask a vendor to tell coverage from fluency?

Ask three things the demo won't show. First, on accent: run the evaluation on your own call recordings — real customers, real phone lines, real background noise — not the vendor's curated set, and look at word error rate on the regional accents that dominate your traffic. Second, on code-switching: play a sentence that switches language on the key noun or verb and check whether the agent keeps the intent and answers in the same mix, or falls back to one language and asks the customer to repeat. Third, on ownership: after go-live, who tunes pronunciation for your product names, local place names, and compliance phrases, and how long does that change take — your team on the platform, or a change request back to the vendor? That last question is the same one the Fast to Deploy capstone asked about scaling: fluency you can't maintain yourself decays the moment the market moves.

See how mid-call switching and scenario tuning work on the Language Engine, Wizlynn, and Talkbot pages, or book a demo and bring your own call recordings — accent, code-switching, and all — to test against.