Top 5 Patterns for Multilingual AI Agents

Your support agent answers a French customer's billing question flawlessly, then quotes a refund policy that only exists in the English documentation. The German user gets a confident answer assembled from a machine-translated snippet that drifted two product versions ago. This is the quiet failure mode of multilingual AI agents: retrieval that treats translations as loose copies rather than governed, versioned variants of the same fact, so the agent grounds itself in whichever language fragment happens to score highest.

Sanity Context (previously Agent Context) is the AI Content Operating System for the AI era, an intelligent backend that keeps multilingual retrieval anchored to one structured source of truth instead of scattered language silos. When every locale is a field on the same document rather than a separate index, the agent can reason about what is translated, what is stale, and what is missing per language.

This article ranks five architectural patterns for multilingual agents, from the duct-tape approaches that break at scale to the structured-content model that holds up. Each pattern gets its honest pitch, where it fits, and where it quietly fails, so you can pick the one that matches the languages, governance, and freshness your users actually need.

5. Translate-on-the-fly at query time

The simplest pattern keeps one canonical language, usually English, and translates the user's query in and the agent's answer out using a machine translation model. Nothing in your content store changes. You retrieve against the English corpus, generate an English answer, then translate the response into the user's language at the last moment.

What it does well: it ships fast and covers the long tail of languages cheaply. If you support forty locales but ninety percent of your real traffic is in three of them, on-the-fly translation means you never maintain forty content variants. For low-stakes informational queries, the round trip is good enough and the cost is a few extra tokens per turn.

Where it fits poorly: anything where the exact wording carries legal or financial weight. A refund window, a dosage, a contractual term, or a regulated disclosure cannot survive a translation hop that nobody reviewed. The agent retrieves against English, so a concept that only exists in the German market (a local payment method, a regional warranty) is invisible because there is no English document describing it. Translation quality also varies wildly by language pair, and you have no editorial control over the output.

Concrete example: a fintech help agent answers a Spanish query about transfer limits by translating the English policy, which describes US limits that do not apply in Spain. The Spanish-language policy exists in the content team's files but was never indexed because the architecture only knows English. The fix is to make locale a first-class dimension of retrieval, not a postprocessing step, which is exactly where the next patterns start to matter.

4. Separate index per language

Here you build one vector index or search collection per language: an English index, a French index, a Japanese index, and so on. The user's locale routes the query to the matching index. Each index holds only content authored or translated for that language, so retrieval never crosses language boundaries by accident.

What it does well: isolation. A query in Japanese only ever sees Japanese content, so you avoid the embarrassing failure where a model retrieves a high-similarity English chunk and answers in the wrong language. Relevance scoring stays clean because every document in the index shares a language, and you can tune ranking per locale. It is a defensible pattern when your languages have genuinely independent content, like region-specific catalogs.

Where it fits poorly: synchronization and drift. You now have N indexes to keep fresh, and each one has its own ingestion pipeline, its own embedding refresh, and its own chance to fall behind. When the English source document changes, nothing automatically tells the French or Korean index that their translated copies are now stale. You also lose the ability to answer cross-lingual questions, where a user asks in Portuguese about a feature only documented in English. Worst of all, the relationship between an original and its translations lives nowhere in the system; the indexes do not know they describe the same fact.

Concrete example: a documentation agent serves five language indexes. A security advisory ships in English and gets translated within a day, but the embedding refresh for the German index runs weekly, so for six days the German agent confidently serves the pre-advisory guidance. Nobody notices until a customer escalates.

3. Single multilingual embedding model

This pattern leans on a multilingual embedding model that maps text from many languages into one shared vector space. You store every document, in whatever language, in a single index, and a query in any language can retrieve semantically similar content regardless of the language it was written in. Cross-lingual retrieval becomes possible: a Thai query can surface an English passage that answers it.

What it does well: it collapses N indexes back into one and unlocks genuine cross-lingual recall, which is powerful when your content is unevenly translated. If your deep technical reference only exists in English but your users ask in a dozen languages, a shared embedding space lets them reach that content. It is also operationally simpler than maintaining per-language pipelines.

Where it fits poorly: governance and answer-language control. The model will happily retrieve an English chunk for a French query, and now your generation step has to decide whether to answer in French from English source, reintroducing the translation-quality problem you were trying to escape. Multilingual embedding quality is also lumpy; high-resource languages retrieve well, low-resource ones degrade, and you cannot see which is which from a single similarity score. You still have no record of which documents are translations of which, so freshness and review remain blind spots.

Concrete example: a retail agent uses one multilingual index. An Italian shopper asks about a return policy; the top hit is a near-identical English passage scoring fractionally higher than the correct Italian one, so the agent answers from the English source and quotes a US-only restocking fee. Pure vector similarity has no concept of "prefer the locale-matched document when one exists," which is precisely the kind of intent that belongs in the query, not in a postprocessing heuristic.

2. Hybrid retrieval with locale filtering

Now retrieval gets serious. You combine semantic similarity with keyword matching and add a structured locale filter so the query can express intent like "prefer the French document, fall back to English, and weight exact term matches for product names." Instead of trusting one embedding score, you blend signals and constrain by metadata.

What it does well: precision and control. Hybrid retrieval catches the cases pure vectors miss, where a user searches for an exact SKU, error code, or product name that semantic similarity smears across near-neighbors, while still handling fuzzy conceptual queries. Adding locale as a filter or boost means the agent can prefer the user's language when a localized document exists and gracefully fall back when it does not, without losing the cross-lingual recall of a shared space.

Where it fits poorly: assembly cost. Most stacks build this by gluing a vector database to a separate keyword engine and a metadata store, then writing reconciliation logic to merge and rescore results. That glue is brittle, and every locale rule you add lives in application code far from the content it governs.

This is where the model matters. In Sanity's Content Lake, hybrid retrieval is native: a single GROQ query can blend `text::semanticSimilarity()` with a BM25 `match()` and combine them using `score()` and `boost()`, with locale expressed as an ordinary filter on the same document. Because dataset embeddings are tied to the content itself, when an editor updates the French variant the embedding propagates within minutes, with no separate vector pipeline to resynchronize. You get the precision of hybrid search and locale-aware fallback in one query against one source of truth, rather than a pile of services you maintain by hand.

1. Structured multilingual content as the agent's source of truth

The top pattern stops treating translation as a retrieval trick and makes it a property of the content model. Each fact is one document with locale-specific fields or linked locale variants, so the system knows that the German, Portuguese, and English versions are the same fact in different languages. Retrieval, freshness, and governance all operate on that structure rather than guessing from similarity scores.

What it does well: everything the lower patterns leak. Because translations are modeled relationships, the agent can answer in the user's language, fall back deterministically when a locale is missing, and flag content that is translated but stale. Editors govern agent instructions and locale rules in Studio, and stage changes with Content Releases the same way they stage the website, so a new language launch or a policy change is reviewed before an agent ever serves it. Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents on the same retrieval path, and the Sanity Context MCP endpoint is what production agents connect to.

Where it fits poorly: it asks you to model your content rather than dump it into an index. If you genuinely have no structure and no intention of building any, this is more upfront thinking than a quick vector store. But that structure is the whole differentiator: legacy CMSes stop at publishing while Sanity Context operates content end to end, and rigid systems force you to scale people while structure lets you scale output across languages.

Concrete example: a support agent serves twelve locales from one Content Lake. When legal updates the master refund policy, Content Releases holds the change until each locale variant is translated and reviewed; until then, the agent transparently falls back to the reviewed prior version per language rather than serving an unreviewed machine translation.