LayBuild tells the model to reply in the language the customer writes in, and most models will. That is the easy half. The hard half is retrieval: the default embedding model is English-only and the full-text search runs with Postgres's English configuration, so a question in Spanish or Hindi against English documentation often retrieves poorly or not at all. When retrieval fails, LayBuild does not guess; it sends a fixed reply, and that reply is in English. We do not claim a list of supported languages, because the honest answer depends on your documents, your embedding model and your testing.

This post explains where language matters in the pipeline, what to change, and how to check the result before customers do.

Where language enters the pipeline

A customer message goes through several steps, and each one has its own relationship with language.

text
customer message (any language)
   -> preflight guardrails (English regex patterns)
   -> follow-up rewrite ("keep the user's language")
   -> hybrid retrieval
        Qdrant vector search      (default: BAAI/bge-small-en-v1.5, English-only)
        Postgres full-text search (english configuration)
        full-text over Q&A pairs  (english configuration)
        knowledge-graph leg
   -> Reciprocal Rank Fusion, minimum relevance 0.4
   -> generate ("reply in the language the customer writes in")
   -> grounding check (25% stemmed-word overlap with sources)
   -> reply, or the fixed English no-answer message

The generation step is the only one that is designed to be language-neutral. Here is what happens at the others.

Vector search with an English-only model

The default embedding model, BAAI/bge-small-en-v1.5, was trained on English. A Spanish question and the English paragraph that answers it will usually not land near each other in its vector space, so the vector leg returns weak matches. The fallback models LayBuild tries when the default fails (Gemini, OpenAI, Qwen and a Cloudflare-hosted copy of the same bge-small model) are only used on errors, not chosen per language.

Full-text search with English stemming

The full-text legs use Postgres to_tsvector('english', ...). That configuration applies English stemming and English stopwords. It is not configurable per organization today. A Spanish question will only match English documents on words that are spelled the same in both, such as product names, error codes and numbers. It will match Spanish documents somewhat better, because identical word forms still match even when English stemming mangles them, but it does not understand Spanish morphology.

The relevance floor and the grounding check

Results are merged and anything below a relevance score of 0.4 is dropped. If nothing survives, the model is not called and the customer gets the fixed reply.

If something does survive and the model writes an answer, LayBuild checks that at least 25% of the answer's content words also appear in the retrieved sources. The tokenizer handles non-Latin scripts such as Devanagari, but stemming only applies to plain a to z words and the stopword list is English. The consequence: a Spanish answer written from an English source shares few words with it (again, mostly names and numbers), so a correct translation can fail the check and be replaced by the fixed reply. We checked this against the agent package with a stubbed model: given an English source saying annual plans can be refunded within 14 days, a correct Spanish answer saying the same thing was replaced by the English no-answer message. When the documents are in the same language as the answer, the check behaves much better.

Two fixed messages are English

The no-answer reply ("I do not have specific information about that in the knowledge base. Please contact [your company] for further assistance, or ask about another topic.") and the guardrail refusal are fixed English strings. A customer who writes in Hindi and hits either one gets English back. The preflight patterns that refuse off-topic requests also refuse explicit translation requests such as "translate this into French", which matters if customers ask the agent to translate your policy for them.

What actually works

Put the content in the customer's language

The most reliable fix is also the least clever: if you support customers in Spanish, give the agent Spanish content. Upload the translated help articles as their own documents, or add Q&A pairs in Spanish for the questions you see most. Then a Spanish question can match Spanish text on both the vector and full-text legs, and a Spanish answer overlaps with Spanish sources, so it passes the grounding check.

This has a cost. Translated copies count toward your document limit (10, 25 or 50 documents on Starter, Pro and Premium), and someone has to keep them in sync with the English originals. Start with the articles behind your most common questions, not the whole help centre.

For short, critical content such as refund rules, shipping zones or cancellation terms, consider pinned documents. Pinned documents skip retrieval and are always placed in the prompt, capped at 4,000 characters each and 12,000 in total. A pinned policy in each language you support is available to every conversation regardless of how well retrieval does.

Switch to a multilingual embedding model

The embedding model is configurable. On a self-hosted install the platform model comes from environment variables (HF_EMBED_MODEL when you use the Hugging Face provider, EMBEDDING_MODEL for OpenAI-compatible endpoints). In the dashboard, admins can also register an embedding model on the Models page and attach it to an agent or set it as the organization default.

Things to know before you switch:

  • Pick a model whose model card says it was trained on the languages you need, and note its output dimension.
  • All vectors in a Qdrant collection must have the same dimension. If the new model's dimension differs from the one your collection was created with, point QDRANT_COLLECTION_NAME at a new collection and re-embed everything. On a self-hosted install, bun run rag:sync in apps/api re-embeds all knowledge documents with the configured model.
  • Even with the same dimension, vectors from two different models are not comparable. Changing the model always means re-embedding.
  • On the hosted service, talk to us at contact before changing the embedding model, so we can confirm it fits your workspace's vector storage.

A multilingual model helps the vector leg match a Spanish question to an English passage. It does not change the English full-text legs, and it does not fix the grounding check for translated answers. Cross-language retrieval with a good model is better than with the default; same-language content is better still.

Keep handoff open for the rest

Whatever you do, some questions in some languages will end in the fixed reply. Make sure a person can take over: turn on human handoff in your organization settings, and on WhatsApp, add handoff keywords in the languages your customers use, since the default list is English (agent, human, support, help, representative).

How to test it

Do not trust a demo in one language. Build a small test set and measure.

  • Take 20 to 30 real questions from your English conversations, the ones your content definitely answers.
  • Translate each into every language you plan to support. Have a native speaker write them the way a customer would, not a textbook translation.
  • For each question, note which document should answer it.
  • Ask every question through the widget and record three outcomes: answered correctly, fixed no-answer reply, or wrong answer.

Split the failures by type. Many fixed replies in one language with few in English means retrieval is not finding that language's content, or the grounding check is rejecting translated answers. Adding a same-language Q&A pair for one failing question and asking it again tells you whether same-language content is the fix. Wrong answers are the more serious signal, because they passed both checks, and usually point at a translated document that disagrees with the original.

Repeat the test whenever you change the embedding model or add translated content, and keep the question set in your repository so the comparison stays fair.

Next steps

For the retrieval pipeline in more detail, read hybrid search with Qdrant and sparse and dense embeddings. For writing content the agent can retrieve well in any language, see knowledge base optimization for AI, and for turning a test set into a regression suite, unit testing AI support prompts.