Agentforce Multilingual Support: Anatomy of a Global Agent
From English-Only to Polyglot: Inside Agentforce’s Multilingual Evolution.
I still remember the moment it hit me: a customer at an international Salesforce event asked, “When will Agentforce speak my language?” As a Product Lead for both Agentforce Authoring and Multilingual Support (Salesforce’s AI agent platform), I knew the demand was massive. Salesforce has more than 150k Enterprise Customers with at least half of these companies serving users in non-English countries, and in every world tour, multi-language support for Agentforce was the #1 request coming my way. Top customers representing three digit ~$XXXM in business were practically lining up for it. Needless to say that in today’s interconnected world, “lack of language flexibility severely limits global deployments”, that seems obvious. And as one internal guide bluntly stated: Multilingual capability wasn’t just a nice-to-have checkbox — it was a strategic imperative to unlock global opportunities.
But making an AI agent truly multilingual? That’s a grind. It meant rethinking everything: how the agent understands intent, calls actions, retrieves knowledge, and responds — all in the user’s own tongue. Spoiler alert: we couldn’t just slap “Google Translate or ChatGPT” on the output and call it a day. This is the story of how we built and tested Agentforce’s multilingual superpower, told from the trenches in the first person. Grab a cup of coffee (or café, or 咖啡, or قهوة — we support those too now) and let’s dive in.
Why We Couldn’t Just “Google Translate ” or “ChatGPT” It
Early on, someone jokingly suggested: “Can’t we run the agent’s answer through a translator? Done!” If only it were that simple. Just translating prompt outputs is not enough — in fact, it’s a recipe for bizarre and broken behavior. We learned this the hard way in prototypes. Imagine a user asks a Spanish question about a Salesforce report, but all the relevant knowledge is in English. A naive approach might translate the user’s question to English, fetch an answer, then translate the answer back to Spanish. What could go wrong? Plenty:
- Lost Context & Nuance: Critical domain terms often don’t translate cleanly. We saw cases where “account record” in French came back as compte rendu (literally “account report”) — not really correct words, and clearly wrong meaning.
- Broken Retrieval: Our agents use retrieval-augmented generation — they search knowledge bases and files for relevant info. If the search query is translated to a different language than the knowledge articles, results could be empty or irrelevant. Conversely, if we only search in the user’s language, we might miss English articles containing the answer. Simply auto-translating queries or articles on the fly, without “deeper logic”, led to no answer at all in many tests.
- Reasoning Mismatch: The AI’s reasoning process (its internal “chain of thought”) works best when it’s operating consistently in one language (right now, english). Forcing it to think in one language but respond in another could reduce coherence. In explorations, we may see that letting the model plan and reason in the user’s language would produce more fluent and contextually correct answers than translating at the last step. In short, language isn’t a superficial layer — it shapes understanding from the ground up.
The conclusion? We had to bake multilingual support throughout the entire stack. From the moment a user message comes in, through intent recognition, action invocation, slot-filling, knowledge retrieval, and final response, the agent needed to be aware of and fluent in the right language. No shortcuts, no half measures.
Language In, Language Out: Context is King
Making Agentforce multilingual starts at “Hello.” When a user opens a conversation, the system needs to know what language they speak — and it needs to carry that knowledge through every step. We introduced the concept of an End User Language context variable, defined by the client application (e.g. chat widget or app) at session start. In a web chat scenario, the user’s browser locale or a pre-chat dropdown can set this variable; in an internal employee agent, the user’s profile language is used. This context variable travels with the user’s session like a bilingual passport.
Critically, our Reasoning engine (the orchestration brain) takes that EndUserLanguage and uses it to decide the agent’s working language. There’s some clever logic here: the “effective” language is resolved based on a few factors. First, the user’s language preference (the context variable) usually wins — if the user prefers Japanese, the agent should too. But we also consider the agent’s configured languages: each Agentforce agent has a primary (default) language and optional secondary languages it supports. If the user comes in speaking a language the agent wasn’t set up for, the system will gracefully fall back to the agent’s default language. (For example, if an agent only supports English and French and someone messages in Swedish, the agent will default to English rather than attempt Swedish). The Reasoner (or Planner) also notes what action is being used and what data source is targeted, since those can affect language behavior. All these inputs combine to set a localization context — essentially, “we’re speaking French now” — that propagates through the pipeline.
And it’s not a one-and-done deal. Users can pull a linguistic switcheroo mid-conversation — and Agentforce has to keep up. Suppose a customer starts chatting in Catalan, then types “¿Puedes ayudar con otra cosa?” (Spanish for “Can you help with something else?”). Our system detects the language switch on the fly (via a language detection step in Planner) and updates the localization context for subsequent turns. The agent will seamlessly respond in Spanish from that point on. This dynamic switching was crucial — we discovered early that many bilingual users would code-switch, or an agent might transfer between users of different locales. Now, those changes are tracked and picked up by the agent in real time. (Fun fact: during testing I once got an English response to a French question — turns out I had forgotten to propagate the updated context after a manual language override. It was a quick bug fix and a humble reminder!).
Under the Hood: Actions and Slots in Multiple Languages
Knowing the user’s language is step one; using it everywhere is step two. Agentforce agents are powered by actions — some predefined “system” actions (like creating a record, querying a database, or answering a question with knowledge) and some custom ones. We had to ensure every action was localization-aware.
Thankfully, many actions just work with the Reasoner’s (or Planner’s) localization context automatically. For example, our Prompt Template actions (which format a prompt for the large language model) are automatically appended with an instruction like “Respond in the user’s language” behind the scenes. That means if the user is Italian, the prompt the LLM sees will include something like “(The user’s language is Italian, answer in Italian.)” — so the model naturally responds in Italian. Standard outputs like our system messages (e.g. the agent’s greeting or progress updates like “Searching for records…”) are also generated or translated based on that context. We taught the agent to say “Looking up that information…” in German as “Ich suche diese Information…”, etc., for all supported languages.
However, for some actions we had to get our hands dirty. If an action bypasses the Planner’s normal prompt flow — say it calls an internal API or external service — then the action owner (its developer) must (make sure to) manually pass along the language context. A good example was our Query Records action (letting the agent run a database query): it originally didn’t consider language at all, since database content is language-agnostic. But the output — like field names or success messages — needed localization. We updated such actions to explicitly grab the localization context and use it when composing results. Similarly, any action reaching out to an external service (maybe a third-party API or a custom system) had to forward the “locale” so that service returns text/content in the right language. We created checklists for action developers: Does your action call the LLM directly? Use an external service? Produce any user-facing text? If yes to any, make sure the localization context is threaded through every function call. This was a painstaking review process, but necessary — one missed context handoff could result in an English sentence popping up in an otherwise Spanish conversation. No bueno :)
Even slot-filling — the way the agent gathers parameters for actions — needed language love. For instance, an action might ask, “What account are you interested in?” which in French should be “Quel compte vous intéresse ?” We leveraged Salesforce’s translation mechanism for such prompts. Each action’s inputs and outputs have a title and description metadata (labels that appear in the UI or help form the prompt). We moved those to use Salesforce’s standard localization framework: action developers replace hardcoded English text with label references. At runtime, those labels are rendered in the user’s language automatically. We also separated the technical description (used in LLM prompt construction) from the user-facing description. The technical part stays in a neutral language for the AI’s benefit, while the user-facing label can be fully translated. This way, when the agent says (in German) “Ich habe 3 Kontakte gefunden” (“I found 3 contacts”), the word “contacts” is coming from a translated label in German, not from the English schema. Little touches like this maintain fluency and professionalism — no ugly mix of languages or inconsistent terminology.
One more nuance: what if the agent’s default language is different from the user’s? For example, an Agentforce Employee agent might be set up with English as default but has French as a supported language. If the user is French, the conversation will switch to French — but what about system components that still have only English templates? During our beta, we had a few “oops” moments where an otherwise French conversation would drop an English phrase from a progress indicator or an unmigrated action. We resolved these as we found them, essentially chasing down any remaining monolingual bits and giving them the multi-language treatment. It was a bit like finding needles in a haystack; each agent has dozens of actions and message templates. But by GA, we reached a point where core agents automatically translate all their system messages and action outputs into the active language. It’s an ongoing effort (some rarely used messages might still be English until explicitly localized), but our goal is clear: no user should ever see a language they don’t speak.
When Knowledge Speaks a Different Language
One of the gnarliest challenges (and coolest innovations) in Agentforce’s multilingual journey has been knowledge retrieval. Agentforce often uses a knowledge base — documents, articles, or even uploaded files — to answer user questions. But what happens when the user speaks one language and the knowledge content is in another? This is where we had to get creative.
Originally, Agentforce’s knowledge search followed a Language Filter Mode: it would only retrieve articles that match the user’s language context. In practice, that means if your agent is conversing in Spanish, it will look for Spanish knowledge articles and ignore others. This mode makes perfect sense for many customers — for example, a company like Fujitsu might have a Japanese knowledge base separate from their English one, and they want the agent to only pull Japanese content for Japanese users. The system works nicely for that: we pass the localization context to our search index, and the retriever component filters results by that locale. If no Japanese article answers the question, the agent might politely say “I couldn’t find an answer” rather than give an English answer. In our internal testing, we saw this scenario play out: a Chinese employee-agent had no Chinese knowledge articles, so when asked in Chinese it returned nothing — it filtered out all the English articles because the languages didn’t match. The upside is consistency (no mixed-language answers); the downside is an unanswered question even though an answer did exist in another language.
Enter the new Translation Mode for our knowledge action (AQWK, “Answer Questions with Knowledge”). This was a direct response to customers like Pfizer who maintain one central English knowledge base but have agents serving users in French, German, etc.. In Translation Mode, the agent can bridge languages: effectively translate the user’s query into the knowledge base language, find the answer, and then translate the answer back into the user’s language. It sounds straightforward, but implementing it was a feat. We had to decide when to use translation vs. direct retrieval, how to do the translations reliably, and how to avoid any mistranslation leading the AI off track.
In practice, we built two flavors of Translation Mode and experimented with both. In one approach, the Planner takes the user’s question (say, in German) and asks the LLM to translate it to the base language (say, English) behind the scenes. The knowledge search runs in English, finds (for example) an English article snippet as the answer, and then we prompt the LLM again to present that answer in German to the user. The user sees a fluent German answer that came from an English source. The agent might even cite the source if configured, showing the English article title — and yes, we had debates on whether to translate titles too! (For now, article titles/descriptions can be localized via Salesforce labels if provided, otherwise they may appear in their original language — a minor trade-off).
The other approach we tested was translating the knowledge content itself rather than the query. This would mean if a French user asks something but we only have an English article, we feed the English text to the LLM and instruct it to summarize or answer in French. This method relies heavily on the LLM’s translation ability and has some risk of introducing errors in facts, so we’ve been more cautious with it. It’s an area we’re continuing to refine — likely a hybrid of both will yield the best results. The exciting part is, we’re giving customers flexibility: those with strictly separate libraries per language can stick to Language Filter Mode (for strict locale fidelity), while those with single-language libraries can opt into Translation Mode to maximize answer coverage.
Behind the scenes, making this work also required updates to our retrieval infrastructure. We worked closely with the Hybrid Search team to ensure our search indexes and vector embeddings support all these languages. Fortunately, modern embedding models are multilingual, and we incorporated an open-source multilingual embedding to cover everything from Arabic to Vietnamese. We set up evaluations for search relevance in new languages, checking metrics like recall and MRR (Mean Reciprocal Rank) to confirm that a German query finds the German content, a Japanese query finds the Japanese content, etc. In one meeting, I half-jokingly referred to myself as a “search sommelier,” swirling through relevance scores for each language and sniffing out anomalies. It paid off — by GA, the retrieval component was just as robust in FIGS (French, Italian, German, Spanish) and beyond as it was in English.
And what about uploaded files? Agentforce can ingest files (PDFs, docs) as a knowledge source too. We had to apply similar logic there. If a user asks a question in Korean but the only relevant PDF is in English, the agent either needs to translate that English content or decide it’s not usable, depending on mode. We’ve largely unified the behavior so that the Translation mode will allow cross-language file use (with translation), whereas the default mode will only return an answer if the file’s content language matches the user’s. This was a big one in testing — we’d often upload a mix of documents in multiple languages and see if the agent smartly picked the right ones. When it didn’t, it was back to debugging. One particularly thorny bug: the agent kept telling users “Sorry, I can’t read that file” when it actually could — we discovered the file’s language detection was failing and defaulting to “unknown”, causing the agent to skip it. We patched it and corrected it.
Conversational Fluency and Reasoning
Multilingual support isn’t just about understanding the user or retrieving facts — it’s also about sounding polished and natural when the agent speaks. Dialog generation and reasoning in the user’s language required careful prompt design and lots of testing with native speakers.
We instruct the LLM to think and answer in the target language as much as possible. We notice that if the system prompt is in English, the model sometimes may slide in an English phrase or potentially have an unatural tone in another language. Our solution here will be to localize even parts of the prompt that set the style or context. For instance, the Agentforce system prompt might include a line like: “You are a helpful customer service agent.” In German mode, we would send: “Du bist ein hilfsbereiter Kundenservice-Agent.” The nuance here is subtle — the model likely “knows” how to speak German, but giving it the entire context in German reduces any doubt. It’s like method acting for AI: immerse it in the language environment so it thinks in that language.
We also believe in adjusting the tone and formality per language. In English, a casual tone works well, but in Japanese, users expect a more polite form. Our prompts will incorporate those cultural norms — e.g., using “〜ます/〜です” forms in Japanese or formal “vous” in French when appropriate. One hard-won lesson is that direct translations can betray you here. We had an agent say in Italian, “Sto eseguendo Query Records…” — literally “I am executing Query Records,” where “Query Records” was a feature name we hadn’t translated. Our Italian evaluator gave it a 2/5 score, saying it sounded like “Italglish.” Now, we translate or explain feature names and avoid mixing languages mid-sentence.
On the reasoning side, ensuring the agent can handle complex queries in any language meant extending our training and testing. We gathered sample questions in each language — from simple FAQs to tricky multi-part requests — to see how the LLM parsed them. Surprisingly, the underlying reasoning chain often transfers well between languages (thanks to the model’s multilingual training). If it can solve a step-by-step math problem in English, it can likely do it in Spanish too. The difference is all about expression. We did find that some languages with fewer training data (say, Estonian or Thai) needed extra love —in these cases we’d give the model more examples and even adjusted temperature settings to keep it factually on track. Empirically, we saw the model occasionally hallucinate a bit more in languages it was less confident in. Our mitigation: shorter, more structured prompts in those languages, and sometimes a back-translation check (have it translate its answer to English internally to double-check meaning, then discard the translation). Tricks? Yes, and they do underline how simply translating output would never achieve true multilingual reasoning fidelity.
Testing, Tuning, and LEHF: The Human Feedback Loop
Building it was only half the battle — we had to test Agentforce’s multilingual abilities mercilessly. This is where empathy and scale came into play. We set up a dedicated QA process using what we dubbed LEHF (Language Evaluation Human Feedback) — in plain terms, getting native speakers to rate the agent’s responses in their language and feed that back into improvements. I cannot emphasize enough how invaluable this human-in-the-loop phase was.
First, we recruited fluent speakers (often Salesforce employees or partners) for each target language. We gave them a crash course in setting up an Agentforce test environment (some became de facto QA engineers for a week!). Each tester created a small knowledge base in their language (e.g. 100 FAQs in Polish) and loaded a ~20 sample files, so the agent had relevant content. They then generated 120 questions in their language to thoroughly exercise the agent. This included “in-domain” questions the knowledge articles could answer, and “out-of-domain” questions designed to provoke the agent and test its fallback behavior. For instance, a French tester might ask something answerable like “Comment réinitialiser mon mot de passe Salesforce ?” (answered by a knowledge article) and something unanswerable like “Quelle est la météo sur Mars aujourd’hui ?” (to see if the agent hallucinates or handles it gracefully).
For every single answer the agent gave, the tester scored it on a 0–5 quality scale. Our rubric was tough. A “5” meant the answer was excellent — correct, complete, and well-written in the target language. A “4” meant good, just missing a minor detail. “3” was borderline acceptable — maybe the agent got the gist but missed something important. Anything below that was basically a failure: “2” for wrong or irrelevant answer, “1” for responding in the wrong language or with serious errors, and “0” for not giving any useful answer. Notably, if the agent slipped out of the user’s language and replied in English (a cardinal sin for a multilingual agent), that was an immediate 1/5. We set a high bar: to pass Open Beta, 95% of answers needed to score 4 or 5. In other words, almost all answers had to be near-perfect in clarity and accuracy before we’d let real customers at large use a new language. Less than 5% could be “just okay.” This threshold was not easy to meet — but we did, often after multiple fix-and-test cycles.
The testing process, frankly, was intense. Each language evaluation produced a detailed spreadsheet of questions, answers, scores, and notes. Our localization team and data scientists poured over the results. We looked for patterns: Was the agent consistently misunderstanding a certain phrase? Did all the low scores come from one particular action or knowledge source? For example, in one wave of testing, Spanish and Italian both had issues answering questions with dates — we discovered the date format in the knowledge articles (“2023–07–15”) wasn’t being verbalized correctly by the agent in those languages. The fix involved tweaking the prompt to instruct the model on date rendering (e.g. “say dates in format DD/MM/YYYY for Italian”). In another case, our German tester kept seeing the agent say “Kein Problem!” (“No problem!”) at the end of answers, which felt too informal. That feedback led us to adjust the German tone to be a notch more professional. Each round of LEHF made Agentforce a little better in each language. We essentially co-created quality with native speakers, which was both humbling and awesome.
The result of all this QA grind? When we finally saw scores come back above the 95% threshold, it was champagne time (literally, we had a virtual toast on Meet 🎉). Only then would we label a language Open Beta — meaning customers could turn that language on, but we’d still advise caution and invite more feedback. After further hardening, including additional evals and even some hybrid automated tests (like using an LLM to judge quality as a secondary opinion), we’d promote the language to GA (General Availability). GA is Salesforce’s promise of quality, so we take this very seriously: for our core agent types, the Agentforce Authoring teams personally certified each supported language’s performance before GA. For other specialized agents built by various teams, we provided the playbook and support, but those teams had to localize and test their agents themselves to reach GA. This decentralized effort was key to scaling — every agent owner became a stakeholder in multilingual quality. It fostered a culture of empathy for the end-user; developers were suddenly reading their agent’s outputs in Dutch or Korean and seeing it from the customer’s eyes.
One more layer of quality control worth noting: Salesforce Localization teams. These are professional linguists and translators who usually localize our UIs. We roped them in to do an expert evaluation of agent responses too, especially for nuances that a non-expert might miss. They gave qualitative feedback (like “the tone is off for a service agent in Japanese” or “this term should be phrased differently in context”). These insights were gold. It reminded us that speaking a language is not the same as communicating effectively in it. Cultural and contextual tweaks make a difference, and having native experts review the AI’s output ensured we didn’t launch any language with “hearing loss”.
Rolling Out Globally: Waves and Hard-Won Lessons
With a solid foundation and proven quality, we began rolling out languages in waves. We prioritized languages by a mix of customer demand and linguistic diversity. The first wave (affectionately called “Wave 1”) tackled FIGS+JP: French, Italian, German, Spanish, Portuguese, and Japanese — major languages with high demand. We got those into an open beta quickly and then to GA for our primary agent types. Seeing Agentforce greet a user with “Hola, ¿en qué puedo ayudarte?” for the first time was a fist-pump moment for the team.
Wave 2 added more European and Asian languages like Dutch, Swedish, Korean, Simplified and Traditional Chinese, etc.. By this point, our process was smoother — we knew how to onboard a new language in about a month from preparation to beta, thanks to the framework and testing regimen built in Wave 1. Wave 3 (ongoing as I write this) is bringing in languages from all over: Arabic (with right-to-left UI considerations), Hindi, Thai, Turkish, Polish, and more. It’s incredible to watch the list of supported languages grow into the dozens. Each wave taught us new lessons. For example, adding Arabic forced us to implement RTL (Right-to-Left) support in the UI — a purely visual challenge, but essential for a good experience. Adding Chinese taught us that our segmentation algorithm (how we break text into chunks for the model) needed to handle character-based scripts better. We’ve truly had to embrace continuous improvement.
We also learned to be transparent with customers about language support. In the Agentforce Builder interface, languages initially came with a “Beta” tag — a gentle warning that quality might vary and that customers should do their own testing too. Once we and our community vetted a language thoroughly, we removed the Beta label for GA. We explain that Beta means “you can try it, but quality assurance is on you,” whereas GA means Salesforce has verified the quality across Agentforce and the underlying AI model. Setting the right expectations was another lesson: some customers assumed an AI that “speaks Japanese” would also magically know all about Japanese local business regulations (it doesn’t — it knows what it’s been given or trained on). We make sure to clarify that multilingual capability means the agent can converse fluently in those languages, but it’s up to the customer to provide any region-specific content or to ensure the knowledge base in, say, Dutch, has the answers to Dutch users’ questions.
Finally, a couple of hard-won lessons from this journey:
- Multilingual is a Mindset, Not a Feature. We started by thinking of it as a feature (“add new language = flip a switch”). We discovered it’s truly a behavior that touches every component. It required cross-functional buy-in — from engineers adding locale support in code, to data scientists wrestling with models, to UX designers adapting interfaces. It’s an ongoing mindset of “how will this work in other languages?” that we now apply to every new feature. Global readiness is not a one-time project; it’s a way of building software.
- Never Assume, Always Test (In Every Language). You might assume that if the agent can handle a certain query in English, it will do so in Italian. We learned to test even the “obvious” things. Tiny differences — a longer word here, a missing polite particle there — can break things. One amusing bug: the Italian word for “edit” is “modifica”, which the agent kept interpreting as “modify car”. The fix involved adjusting our NLP parsing for that word, which we’d never have caught without on-the-ground testing. This taught us humility: always test with native input, and involve native speakers whenever possible. Automation and metrics helped flag issues, but human intuition and cultural context solved them.
Through all of this, our driving motivation was empathy — putting ourselves in the user’s shoes in Paris, Tokyo, Rio, or Mumbai and ensuring their experience is first-class. It’s been a long road, but hearing feedback like “It’s like the agent really speaks our language!” makes it all worth it.
Explore Agentforce in Your Language
Agentforce’s multilingual support is not just a technical milestone; it’s a promise that technology can be inclusive and globally accessible. We’re continuing to expand language support (if your language isn’t live yet, trust me, it’s on the roadmap!). In the meantime, you can see Salesforce’s commitment to localization firsthand. Check out our Salesforce sites in many languages below!
These localized sites show product info, announcements, and resources in many languages — a great way to experience the ecosystem in the language you’re most comfortable with.
Building agents that fluently converse and reason across dozens of languages has been such a most challenging and rewarding project. It reinforced that multilingual readiness is not a switch to flip, but a journey of design, testing, and iteration. From intent classification to action execution, retrieval to generation, every layer was deliberately crafted to respect the user’s language. The grind was real, the scale was global, and the empathy was essential. The next time you chat with an AI agent in your native language and it truly understands you, remember: a whole lot of work went into that magical moment. And we’re just getting started — Agentforce is learning to say hello to the whole world, one language at a time.
Merci, Gracias, 谢谢, धन्यवाद, شكرا — Thanks for reading!
