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.
Hamming AI has watched this pattern play out across more than 4 million voice interactions in 49 languages, across 10,000 deployed agents. Task completion rate went down significantly introduced on non-English markets. With the same model, the same architecture. The same test suite that had just passed.
Something gets lost in translation, literally. Why? Because the LLM is the one making the decision.
The gap you can measure
Start with transcription. Hamming's benchmarks across those 49 languages put English at 5 to 8% word error rate in clean conditions. Romanian sits at 10 to 15%. Spanish, German, and Portuguese land in the same range: roughly double the English error rate before a single word reaches the model doing the reasoning. Add background noise, a phone line, or an accent the model wasn't trained on, and the gap widens further.
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.
