A team builds a voice agent in English. They test a hundred scenarios, hit a 95%+ pass rate, and ship it. It works! Then they roll it out to other markets, and accuracy drops.
An English demo can't warn you this is coming, because it never touches the layer where non-English accuracy actually breaks.
The gap you can measure
Start with transcription. OpenAI's own model card for Whisper large-v3 reports an average 10% word error rate across 102 languages on FLEURS (a multilingual speech dataset and benchmark created by Google), already worse than English alone gets. And that number is the optimistic case: FLEURS is an academic benchmark built from short sentences, read carefully, in clean, quiet conditions. When Deepgram benchmarked the same model on real-world audio instead, ordinary recordings in Spanish, German, Hindi, and Turkish, curated by native speakers rather than read in a studio, they found performance fell well short of what the published FLEURS numbers implied.
That's the layer most teams already know to check.
And where you don't check
The second problem is what the model does with the words once it has them. Models trained mostly on English data tend to fall back to reasoning in English for less common languages: translating the question in, reasoning, translating the answer back out. A 2025 study on reasoning models named this failure mode directly: lost in translation. The round trip introduces errors a model reasoning natively in the question's language wouldn't make.
A separate 2025 study on enterprise LLM applications, published at EMNLP's industry track, measured how much this costs: accuracy drops of up to 29% in non-English languages, even in systems built with retrieval-augmented generation - grounding AI’s answers in real documents. The researchers traced the gap back to the same English-centric reasoning bias. Adding retrieval doesn't close it, because the problem isn't what the model knows. It's the language it's quietly deciding in.
You can build it a different way
The fix isn't a better, multilingual model. It's not letting the decision happen inside the translation round trip at all.
Zowie's Flows split the job into two components. The Decision Engine executes structured workflows as deterministic logic: JavaScript conditionals checked against real data, whether an order status equals "processing," whether a refund window is still open, whether a transaction sits under the account's limit. It never touches language. The Reasoning Engine is the LLM-powered half: it understands intent, retrieves the relevant knowledge, and generates the reply. A customer writing in German and another writing in Ukrainian hit the exact same workflow logic, because the Decision Engine is reading data and your business logic, not words.
The path a message takes: it arrives in whatever language the customer used. Language detection runs automatically from the message content. Intent recognition maps it to a workflow. The Decision Engine branches on that workflow deterministically, with no language involved at any point. The Reasoning Engine then generates the reply, with the prompt explicitly enforcing the response language, so the customer gets an answer in the language they used, not one translated after the fact.
There's no separate translation service sitting underneath it. The Reasoning Engine handles multilingual understanding natively, which means knowledge written in one language can inform an answer delivered in another: a policy document written in Polish can shape a response given in Spanish, without anyone maintaining parallel translated knowledge bases.
None of this works if the LLM still gets the final word on the cases that matter.
Language is not region
One distinction worth making explicit: what language a customer speaks and which market's policies apply to them are two different questions. A German-market customer who happens to write in Ukrainian should still get German-market policies, not Ukrainian ones, because region is a property of the account and the market, not of the words someone typed. That's why at Zowie region routing runs off account and session data, kept separate from language detection, so a business can localize its language without accidentally localizing its policy.
Regional customization is real and often necessary. A bank operating in four markets will have four different transaction limits, four different escalation rules, four different regulatory constraints. That's a business decision, made and owned by the business. It's a separate question from whether the agent can talk to a customer in their own language, and the two shouldn't quietly merge into one.
What that means for the decision in front of you
If a vendor's demo runs in English and your customers don't, ask what happens to the decision layer when the language changes. Not the phrasing, the decision itself: does a refund get approved the same way in Romanian as it does in English? If the honest answer depends on how well the model reasons in a language it wasn't trained on as heavily, that's not a language problem. It's an architecture problem.
Policies will still differ by market. That's normal, and required. What shouldn't differ is who sets them: the business, not a language model guessing its way through a translation nobody asked it to make.
