Answering email in the language it arrived in

A support team that answers in two languages and receives mail in nine has a coverage problem that costs real money: the Finnish customer waits three days for someone who speaks Finnish, or gets an English reply and works it out. An agent removes that gap almost for free, which makes multilingual support one of the strongest arguments for putting one on the inbox at all.

5 min read

A message arriving in one language and being answered in the same one
Answer in the language they wrote in. The exceptions are what this post is about.

It is also where an agent can produce a confidently wrong sentence in a language nobody on your team can check.

The default rule

Reply in the language the customer wrote in. Not the language of your company, not the language of the last message in the thread if the customer switched, and not English because it is easier to review.

Two refinements that matter more than they sound.

Match the variant. Brazilian and European Portuguese are different enough that getting it wrong reads as carelessness. So does answering a British customer in American spelling on a formal complaint.

Match the register. Many languages encode formality grammatically, and getting it wrong is worse than an awkward phrase. German Sie and du, French vous and tu, Japanese politeness levels: mirror what the customer used, and default to the formal register when uncertain.

What to never translate

Some strings must survive intact, and a model that helpfully localises them creates a support ticket rather than resolving one.

Never translateWhy
Order and invoice numbers, referencesThey must match your systems exactly
Product names and SKUsThe customer will search for the localised name and find nothing
Error codes and technical identifiersThey are lookup keys, not words
Legal and contractual languageOnly the authoritative version binds anyone
Names, addresses, URLsObvious, and it happens anyway

The failure to picture: an agent translating a product name into fluent Spanish, the customer searching your site for it, finding nothing, and writing back more annoyed than before. Pin these in the prompt as literal strings to carry through unchanged, and prefer a tool that returns them rather than a model that remembers them.

Where quality actually varies

Model quality by language is uneven, and it is uneven in a way you cannot see from the inside. Fluent output in a language you do not read is indistinguishable from correct output.

Practical approach: rank your inbound languages by volume, and treat the top few as covered, the middle as covered with a check, and the long tail as escalate. Getting the tiers right needs someone who speaks the language to read a sample, which is a small piece of work that most teams skip and then regret.

Two specific hazards worth knowing. Idiom and politeness collapse first, so a technically correct reply can still read as brusque. And languages with less training data produce fluent-sounding output with more factual drift, which is the dangerous combination.

Languages ranked into covered, covered-with-review, and escalate
Three tiers, decided by someone who reads the language. Fluency is not evidence.

Escalating without dumping

Escalation gets harder in a multilingual setup, because the human it goes to may not read the language either. Two things make it workable.

The agent should escalate with a summary in your team's working language, alongside the original thread untouched. A colleague can then decide what to do without translating anything themselves, and the original is right there when it matters.

And escalation should trigger on the same things as anywhere else, plus one: when the agent's own confidence in the language is low. That is not a feeling, it is a rule you can encode, and it is the multilingual version of "cannot cite a source, so escalate" from the system prompt.

The operational details people miss

Encoding. Non-Latin scripts and emoji need to survive the whole path. Bodies are markdown delivered as text plus HTML, and modern mail handles UTF-8 fine, but test with real Japanese, Arabic, and Polish content rather than assuming.

Right-to-left. Arabic and Hebrew replies need correct direction, and a quoted history that mixes directions renders badly. Keep replies short and let the thread carry the history rather than quoting inline, per how email threading works.

Time and dates. Write dates unambiguously and name the timezone. This matters everywhere and doubles in importance across languages, per the scheduling rules in appointment reminders.

Contact memory. Record the language and register a customer uses on their contact record, so the second conversation starts right without re-detecting, per giving an email agent memory.

Search. Your internal documentation is probably in one language while the question arrives in another, so retrieval has to bridge that. The usual fix is retrieving in your documentation language and answering in theirs, rather than translating your knowledge base and maintaining nine copies of it.

What it buys

Response time collapses for every language outside your team's coverage, which is usually where the worst numbers live. Nobody waits for the one colleague who speaks Italian to come back from holiday.

The second effect is quieter: you find out how much mail you were receiving in languages you do not support, because previously it went to a queue nobody worked and some of those customers simply left.

Questions

Should an AI email agent reply in the customer's language?
Yes, matching both the language and the variant they used, and mirroring formality where the language encodes it. Defaulting to the formal register when uncertain is safer than guessing informal.
What should never be translated?
Order and invoice numbers, product names and SKUs, error codes, legal language, and anything the customer will search for in your systems. Carry those through unchanged.
How do I know if quality is good enough in a language?
Have someone who reads it review a sample. Fluent output in a language you cannot read is indistinguishable from correct output, so tier your languages by evidence rather than by impression.
How should it escalate a thread in a language my team does not read?
With a summary in your working language plus the original thread untouched, so a colleague can decide without translating anything first.
Do I need to translate my knowledge base?
Usually not. Retrieve in the language your documentation is written in and answer in the customer's, rather than maintaining nine copies that drift apart.
What about right-to-left languages?
Keep replies short and let the thread carry history rather than quoting inline, since mixed-direction quoted text renders badly in many clients.

Give your agent an address it can answer from.

Create an inbox