Why Your AI Support Agent Replies in the Wrong Language (and What to Do About It)
A practical guide for teams running Fin, or any LLM-based support agent, in Hebrew, Arabic, Thai, and other non-English languages.
If you support customers in Hebrew, Arabic, Japanese, Thai, or any non-Latin-script language, you've probably seen it: your AI agent replies in mostly the right language, but with random English words sprinkled in. Or worse — a few characters from a completely unrelated script (Chinese, Japanese, Cyrillic) appear in the middle of an otherwise normal reply.
This isn't a bug in your configuration. It's a known behaviour of LLM-based support agents, and it's particularly common in lower-resource languages. The question most teams are asking right now isn't why it happens — it's what to actually do about it, and how to catch it before customers do.
This post covers both.
What "language drift" actually is
Language drift is the term for an LLM unexpectedly switching languages, scripts, or vocabulary mid-output. It shows up in three common patterns:
English token leakage — random English words inserted into a non-English reply, even when the source content (articles, snippets) doesn't contain them.
Foreign script injection — characters from an entirely unrelated writing system (most often CJK characters) appearing inside a Hebrew, Arabic, or Cyrillic reply. This is usually a tokenizer artifact: in the model's vocabulary, certain tokens are shared across scripts, and under specific decoding conditions the wrong one wins.
Transliteration drift — the model writes a foreign word phonetically in the target script ("גוגל" instead of "Google") inconsistently across replies, breaking brand presentation.
All three are more frequent in languages with smaller training representation. Hebrew, Arabic, Thai, Vietnamese, and most African languages are particularly vulnerable. So is any language whose script overlaps tokenizer-wise with another (Hebrew/Arabic, Chinese/Japanese, Cyrillic variants).
Why guidance rules don't fully fix it
Most platforms — Intercom's Fin, Zendesk's AI agents, Salesforce Einstein — let you write natural-language guidance telling the model to "always reply in [language]." This helps. It doesn't solve.
The reason is structural. Guidance is a soft instruction layered on top of the model's decoding process. When the model is choosing the next token, guidance increases the probability of compliant outputs but doesn't prevent non-compliant ones. In a long reply with hundreds of token decisions, the probability of at least one drift event is non-trivial — especially if your source content contains English brand names, product terms, or URLs that bias the model toward English tokens nearby.
Intercom's own multilingual glossary feature, useful as it is for translation workflows, doesn't apply to AI-generated replies. This is a common point of confusion — teams add terms to the glossary expecting Fin to honour them, then keep seeing the same drift.
What actually reduces drift
Based on what we see across the conversations Isara analyses, here's what genuinely moves the needle, in rough order of impact:
1. Make sure your non-English content is native, not machine-translated
This is the biggest lever and the one most teams underestimate. If your Hebrew help articles were translated from English by a tool that left brand names, technical terms, or whole phrases in English, your AI agent learns to mix languages from your own source material. Audit your articles. Have a native speaker review the top 20 by retrieval frequency. Fix the ones that are actually translated-from-English masquerading as native content.
2. Disable real-time translation if you have native coverage
Real-time translation is helpful when you have content gaps, but it's also a major source of drift and weird character artifacts. The translation layer adds another LLM step where errors compound. If you have native articles for your top intents, turn real-time translation off and let the agent use the source material directly.
3. Set explicit language overrides on user attributes
Auto-detection works well on long messages and poorly on short ones. For users you already know speak Hebrew (or any specific language), set the language override attribute explicitly via your user data. This bypasses detection entirely and is more reliable than hoping the model gets it right from a five-word message.
4. Write guidance that names the failure modes
Generic "reply in Hebrew" guidance is weaker than guidance that explicitly forbids the bad behaviours you're seeing. Something like:
Reply only in Hebrew using Hebrew script. Do not insert English words, transliterations, or any non-Hebrew characters (including Latin, CJK, or symbols beyond standard punctuation), except for: official brand names, URLs, email addresses, and product names that appear in source content. If a Hebrew translation is unavailable for a term, use the closest Hebrew equivalent rather than the English term.
Naming the specific failure modes — "no CJK characters," "no Latin script except brand names" — tends to suppress them more than positive instructions alone.
5. Constrain pronoun and register settings where the platform supports it
Fin's pronoun formality setting, and similar features in other platforms, doesn't directly fix language drift, but it does narrow the model's output distribution. More constrained outputs drift less in general. Use these settings even when they feel like polish rather than substance.
The harder problem: knowing when it's happening
Here's the part most teams miss. Even with everything above implemented well, drift events will still occur — at a lower rate, but they will occur. The customer-facing impact of a single bad reply (a Hebrew-speaking user receiving a message with Japanese characters in it) is disproportionately high. It looks broken. It feels untrustworthy. It triggers complaints that are far more expensive to handle than the original support request.
The teams that handle this well don't try to make their AI agent perfect. They build a detection layer.
That means: every AI-generated reply gets scanned, in real time or near-real time, for indicators of drift — unexpected scripts, non-allowlisted English tokens in non-English replies, character set mismatches, transliteration inconsistencies. When something fires, the conversation gets flagged for review before the customer escalates, or routed to a human agent, or rolled back depending on severity.
This is exactly the category of problem Isara was built for. We analyse 100% of support conversations across Intercom and other platforms, and language quality is one of many signals we surface — alongside missed escalation triggers, sentiment shifts, churn indicators, and policy violations. For teams running AI agents in non-English markets, the detection layer isn't a nice-to-have. It's the thing standing between an AI mistake and a customer trust event.
Summary
Language drift in AI support agents is a current limitation of the underlying technology, and it disproportionately affects teams supporting non-English markets. Configuration fixes and good guidance will reduce frequency meaningfully but won't eliminate it. The realistic strategy for any team operating AI agents in Hebrew, Arabic, Thai, or similar languages is:
Reduce the rate of drift through native content, language overrides, specific guidance, and tighter platform settings.
Detect the drift events that still slip through, before customers do.
Route flagged conversations to human review for high-stakes intents.
Treating AI support agents as systems that need monitoring, not configurations that need perfecting, is what separates the teams getting value from AI from the teams quietly losing customer trust.
Isara provides conversation intelligence for customer support teams running AI agents at scale. We analyse every conversation across your support stack and surface the ones that need attention — including language quality issues, missed escalations, and customer trust events — before they become churn. See how it works.