Running an Agentforce agent in more than one language: the allowlist, Translation Workbench, and the grounding gap that answers in English anyway

Someone types a question in Spanish, and your agent answers in fluent Spanish on the first try. It’s impressive: right up until the next customer asks about their refund policy, the agent reaches for the knowledge article that would answer it, finds nothing, and falls back to a vague apology. The language wasn’t the problem. The grounding was. And that gap is the whole story of multilingual Agentforce, because the part everyone worries about, can the model speak the language, is the part that already works, and the part nobody plans for is the part that breaks.

The reason teams underestimate this is that the underlying LLM is inherently multilingual. It will happily reason and respond across dozens of languages with no configuration at all. So “let’s support French” gets filed as a toggle. It isn’t one. “Support French” is three separate problems wearing one coat: a language allowlist (which languages the agent is allowed to speak), a language signal (how the platform knows which language this conversation is in), and grounding (whether the knowledge, actions, and deterministic strings the agent depends on exist in that language). Two of those the platform gives you controls for. The third is where production agents fail. This post pulls the three apart.

Problem one: the allowlist

Start with the control that exists. An Agentforce agent has a Default Language and a set of Secondary Languages, configured in the Agentforce Builder under Language Settings. Together, those form the allowlist of languages the agent is set up to speak, and it’s worth being precise about what that list does and doesn’t do. It’s less a hard wall than a declaration: it governs which languages Salesforce treats as supported and quality-verified, it drives the localization of system messages and prebuilt responses, and it tells the reasoning engine which languages you’ve prepared for. What it is not is an absolute block on the model, because the underlying LLM auto-detects the user’s language and can respond in one you never listed. That gap between “the model will happily answer in Polish” and “you have set the agent up to support Polish” is the entire reason the allowlist matters: it’s how you separate the languages you’ve tested, translated for, and staffed an escalation path in from the ones the model will merely improvise in.

Adding a secondary language isn’t only a checkbox in Builder. You also enable Translation Workbench (Setup → Translation Workbench → Translation Settings) and add the language as a translated language. Translation Workbench is the same org-wide localization machinery Salesforce has always used to translate custom labels, picklist values, and metadata, and for an agent, it’s where the strings the agent depends on get their translations. That matters more than it sounds, and it’s the bridge to the third problem below.

The mental model to hold: the allowlist decides what the agent may speak; it does not decide whether the agent has anything useful to say in that language. Those are different questions, and conflating them is the first mistake.

Problem two: the language signal

Once the agent can speak French, something has to tell it this conversation is in French. That something is the EndUserLanguage context variable ($Context.EndUserLanguage). It’s set by the client application at session start (the chat widget, the mobile app, the channel) not guessed by the agent from the first message. It’s also one of the few context variables that is editable mid-session (during a sendMessage call), which is what lets a customer switch languages partway through and have the agent follow.

Where that value comes from depends on the channel:

Messaging for Web / Enhanced Chat. Connect the agent to your Enhanced Chat channel and turn on “Identify preferred language of messaging users.” With that enabled, the channel can detect the visitor’s browser language and populate the language context at session start, so a French-locale browser lands in a French conversation without the customer choosing anything. This is the same Messaging for Web plumbing that carries pre-chat data, the language is just one more field the snippet sets.
API and custom apps. If you’re driving the agent through the Agent API, your application sets the language when it starts the session. Whatever your app knows about the user’s locale (account preference, Accept-Language header, an explicit picker) is what should populate it.
Testing. In the Builder’s Preview, you can set the End User Language Variable directly to rehearse a conversation in each language before you ship. Do this for every secondary language; it’s the cheapest way to catch a missing translation.

Because the model detects the input language on its own, the belt-and-suspenders move is to pin the working language with an explicit instruction, something as plain as Always respond in {!$Context.EndUserLanguage}. in the agent’s instructions. That way the language the agent commits to is the one your channel set deliberately, not whatever the model inferred from a stray English word in an otherwise-French message.

The failure mode here is subtle: if nothing sets EndUserLanguage, the agent falls back to the default language, and you get an agent that can speak Spanish but never does because no signal ever told it to. Multilingual that “doesn’t work” is very often a language-signal problem, not a model problem, the same way an agent that keeps re-asking for information it already has is almost always a variables problem rather than a memory one.

Problem three: grounding, where it breaks

Here’s the part the demos skip. An agent is only as multilingual as the things it grounds on, and grounding is language-aware in a way that will surprise you.

Take knowledge. When an agent retrieves a Knowledge article to answer a question, the retriever filters candidates by the conversation’s language context against each article’s Knowledge Article Language field. Articles whose language doesn’t match the session language get filtered out before the model ever sees them. That’s the right behavior, you don’t want an English article cited verbatim into a French answer, but it has a brutal consequence: if your knowledge base only exists in English and the session is in French, retrieval returns nothing. The model, starved of grounding, does what a model does with no facts. It apologizes, or worse, it improvises. Your beautifully multilingual agent becomes a monolingual one the moment a customer needs a grounded answer.

This is why “the model speaks French” is a red herring. The search index vectorizes your content, and modern embedding models are multilingual, so semantic search across languages is technically possible. But the language filter on grounded knowledge is a metadata match, not a semantic guess, and it’s there on purpose, because a regulated answer has to come from an approved article in the customer’s language, not a machine translation of one. The upshot: multilingual grounding is a content project, not a model setting. Every knowledge article, every Data Library document, every grounded source you expect the agent to use in French has to exist in French, tagged with the right language.

There are two honest ways to close that gap, and they cost differently. The straightforward one is to author and tag your knowledge in each supported language, so language-filtered retrieval finds a real French article for a French session. The lighter-weight one, which Salesforce itself documents, is a translate-in, translate-out pattern: translate the user’s question into the language your knowledge base is written in, retrieve against that single corpus, and translate the answer back. That spares you maintaining a full copy of every article per language, at the cost of a translation hop in the middle, and the fidelity questions that come with machine-translating a regulated answer. Which one is right depends on how regulated your content is and how many languages you’re serving. But notice what both have in common: they’re decisions about content and pipeline, not a checkbox in Builder.

The same logic extends past knowledge:

Actions, topics, and their labels. There’s a split worth getting right. The customer-facing titles and labels, what the agent shows the user, get localized through Translation Workbench. But the reasoning-engine-facing description, the one the planner reads to pick the right topic and action, is generally kept in a single neutral language, because that’s the text the model classifies against and you want it stable regardless of which language the conversation is in. The rule of thumb: translate the labels the customer sees; leave the description the planner reads alone. The description is still the code that matters most. It just isn’t the thing you translate per language.
Deterministic strings. Menu options, quick-reply buttons, validation messages, the fixed prompts your flow emits, anything the agent presents verbatim rather than generating, is a string that has to be translated, not left to the model. These are exactly what Translation Workbench exists to carry.
Prompt templates. If your agent calls a Prompt Builder template, the localization context flows through so the template can render in the user’s language; you can retrieve it in a flow via the GetAgentContext action and pass it into the template.

The dividing line is clean once you see it: the model handles free-form generation in any allowed language; you own every fixed string and every grounded source. The model translates its own sentences. It cannot translate a knowledge article you never wrote.

What the platform supports today, and what “beta” means

Be precise about the supported-language list, because it moves and because “supported” has two meanings. English is fully supported (GA). Beyond that, Agentforce has expanded quickly: a core set (French, German, Italian, Spanish, Portuguese, and Japanese among them) became supported across select locales, and an April 2026 update added more than two dozen further languages in beta. Because that list is a moving target, check the current Agentforce (Default) Supported Languages documentation for your release rather than trusting a blog’s snapshot, including this one.

The distinction that affects your rollout is GA versus beta. For a GA language, Salesforce has verified response quality. For a beta language, you can select it in Builder, but you own quality assurance. Salesforce hasn’t certified that responses meet the bar. That’s not a reason to avoid beta languages; it’s a reason to budget for the QA. Shipping a beta-language agent without a native-speaker review pass is how you end up with a technically-multilingual agent that’s subtly wrong in ways your English-speaking team can’t see. Treat a beta language the way you’d treat any untested production path: rehearse it, review real transcripts, and don’t assume passing in English means passing in Portuguese.

Testing and QA in a language your team may not read

Multilingual multiplies your test surface, and the mitigations are unglamorous:

Rehearse every language in Preview. Set the End User Language Variable to each secondary language and run your top intents. You’re checking two things: does the agent respond in the right language, and, more importantly, does it still ground? An intent that returns a confident, grounded answer in English and a hedge in Spanish is a missing-translation flag, not a model failure.
Get native reviewers on the transcripts. Conversation transcripts are your ground truth, and they’re only useful if someone who reads the language reviews them. Budget for it. A machine back-translation of a transcript hides exactly the fluency and tone problems you’re trying to catch.
Watch for language drift within a conversation. A user who switches languages mid-chat, or a bilingual user who mixes them, can pull the agent between languages. Because EndUserLanguage is editable mid-session, decide deliberately whether your channel updates it on a detected switch or holds the session language, either is defensible, but leaving it undefined produces a mixed-language mess.
Mind the mechanics of non-Latin and right-to-left scripts. Rendering, input handling, and any string truncation in your channel UI behave differently in Arabic, Japanese, or Hebrew than in French. That’s a channel and front-end concern as much as an agent one, and it’s worth an explicit test rather than an assumption.

The honest cost of going multilingual

There’s no separate “multilingual meter”. You don’t pay a language surcharge on Flex Credits per se. But the real cost is content operations, and it’s not trivial. Every language you add is another full copy of your grounded knowledge to author, translate, keep in sync, and re-review every time the underlying policy changes. A knowledge base that drifts out of date in English is a problem; one that drifts out of date in six languages, unevenly, is a much bigger one, and the language most likely to rot is the one nobody on your team reads.

So the discipline is to scope languages the way you’d scope any feature: to real demand and real ability to maintain them. Two languages you keep current and QA properly beat six you translated once and never touched again. The allowlist is easy to extend; the content and QA behind each entry are the actual commitment.

The takeaway

Multilingual Agentforce is three problems, and only the easy two have toggles. The allowlist (Default plus Secondary Languages in Builder, backed by Translation Workbench) decides what the agent may speak. The language signal (EndUserLanguage, set by the channel, detected from the browser in Enhanced Chat or passed by your app through the Agent API) decides which language this conversation runs in. And grounding (knowledge tagged by language, localized action and topic descriptions, translated deterministic strings) decides whether the agent has anything useful to say once it’s speaking that language. The model was never the hard part. Get the allowlist and the signal right, then treat every secondary language as a content and QA project rather than a setting, and the agent that impressed you in the demo will still be right in production. Skip the third problem and you’ll ship an agent that speaks six languages and can only help in one.

Understanding the basics

Does Agentforce support multiple languages out of the box?

Partly. The underlying model is inherently multilingual, and English is fully supported (GA). To use another language you add it as a Secondary Language in the Agentforce Builder’s Language Settings and enable it through Translation Workbench. Together, your Default Language and Secondary Languages form the allowlist of languages the agent is allowed to speak. A core set is supported across select locales, and an April 2026 update added more than two dozen further languages in beta. Check the current Agentforce (Default) Supported Languages documentation for your release, and note that beta languages require you to own quality assurance yourself.

Why does my Agentforce agent answer in English even after I enabled another language?

Two usual causes. First, the language signal: if nothing sets the EndUserLanguage context variable at session start, the agent falls back to its default language regardless of what the customer types. Check that your channel (for example, “Identify preferred language of messaging users” in Enhanced Chat) or your app is populating it. Second, grounding: when the agent retrieves knowledge, the retriever filters articles by the session’s language against each article’s Knowledge Article Language field, so if your knowledge only exists in English, a non-English session returns no grounded content and the agent hedges or drops to English. The fix for the first is configuration; the fix for the second is translating your content.

What needs translating for a multilingual Agentforce agent?

Everything the agent presents or classifies on that is fixed rather than generated: knowledge articles (tagged with the correct language), Data Library documents, action and topic titles and descriptions (localized through Translation Workbench so classification stays reliable), deterministic strings like menu options and validation messages, and prompt templates (via the localization context). The model handles free-form generation in any allowed language on its own. It translates its own sentences. It cannot translate a grounded source that doesn’t exist in the target language, which is why multilingual grounding is a content project, not a model setting.

Does adding languages to Agentforce cost more?

There’s no separate per-language billing meter, so a conversation in Spanish isn’t inherently priced differently from one in English on the action or conversation meters. The real cost is content operations: each language is another full copy of your grounded knowledge to author, translate, keep synchronized, and re-review by a native speaker whenever policy changes. Scope languages to genuine demand and your ability to maintain them. Two languages kept current beat six translated once and left to rot.

Rolling an agent out across languages and finding it speaks all of them but can only help in one? Talk to us. Getting the grounding, the language signal, and the QA right, so the agent is as useful in the customer’s language as in yours, is exactly the work that separates a demo from a deployment.