The quick version: the model will answer in most languages whether or not you configured it to, which is the problem rather than the feature. Quality is uneven across languages, your grounding content is probably English only, and testing that stops at English tells you nothing about what a French customer experiences. Supported language lists exist per feature and per channel and they change, so check current documentation before promising anything.
What “supported” actually means
There are several different things a support list can be describing, and they are not the same:
- Languages the platform will accept and produce text in.
- Languages the topic and instruction configuration has been tested against.
- Languages your knowledge content exists in.
- Languages your escalation queues are staffed for.
Only the first is a product capability. The other three are yours, and they are where multilingual deployments fail. An agent answering in Portuguese by translating an English article is doing something you did not design and cannot verify.
Quality is not uniform
Models are trained on uneven amounts of text per language. English is best served by a wide margin, major European languages are good, and beyond that quality drops in ways that are hard to see, because the output stays fluent while becoming less accurate.
Register. Formal and informal address is a real decision in German, French, Japanese and many others, and the model picks one without being told. Getting it wrong is not a minor style issue for a customer-facing channel. Instruct explicitly.
Terminology. Your product names, plan names and internal terms get translated when they should not. “Premium Support” becoming a literal translation makes the answer wrong even when the sentence is correct. Give the agent a do-not-translate list.
Instruction adherence drops. This is the one that surprises people. An agent that follows its guardrails reliably in English follows them less reliably when the conversation is in a language further from the training distribution. Guardrail testing has to be repeated per language, not translated once and assumed.
Retrieval mismatch. A question asked in Spanish against an English knowledge base may retrieve nothing useful, or something loosely related presented confidently. Whether retrieval crosses languages depends on configuration and content, so test it.
Choosing an approach
Two broad options, and the right one depends on how much you can afford to verify.
Translate the content. Maintain knowledge and instructions in each language. Higher cost, much better control, and the answers are reviewable by someone who speaks the language. Appropriate wherever the answer has consequences.
Let the model translate at runtime. Cheap, fast to launch, and the output is unverified by anyone. Defensible for low-stakes informational content. Not defensible for anything a customer will act on financially or legally.
A middle path that works: translate content for your top two or three non-English volumes, and hand everything else to a human.
Testing beyond English
Translating your English test set is the wrong method. Native speakers do not phrase questions as translations of English questions. Get real utterances, from real transcripts in that language, and test against those.
Per language, run at minimum:
- The top ten real questions, taken from historic transcripts rather than invented.
- Every guardrail probe you run in English. Refusals are the first thing to weaken.
- A mixed-language conversation, because bilingual customers switch mid-sentence.
- The escalation path, confirming the conversation reaches a queue where someone can read it.
- Any confirmation message that quotes data back, checking date and number formatting.
That last one catches a class of error nobody expects. Date and decimal formatting is generated text, not a formatted value, and a model writing a date in the wrong convention produces a confirmation the customer agrees to while both parties mean different days.
The honest position for a launch plan
If the agent will receive messages in a language you have not tested, decide now what it does. Either it handles that language properly, or it escalates. What it should not do is answer fluently in a language nobody on the project can read.
Frequently asked
Can one agent cover several languages? Usually yes. Whether one agent or several is better depends on how different your content and escalation paths are per market.
Does it detect the language automatically? Generally it responds in the language it was addressed in, which is not the same as a deliberate detection step you can act on. If you need a decision based on language, make it explicit.
How do we review quality without speakers on the team? You cannot. Budget for reviewers in each language you launch, or do not launch that language.
What about right-to-left languages? Rendering is a channel question as much as a model one. Test in the real channel, not a builder preview.
