Quick answerWhen a customer switches languages mid-conversation, commonly by mixing two languages in one message or alternating messages, the agent should detect the switch at the message level, not assume the conversation's initial language holds for its entire length, and respond in whichever language the customer just used rather than forcing them back to the language the conversation started in. Preserve context across the switch so the customer never has to repeat themselves in the new language, and only ask for an explicit language preference if the mixing itself creates real ambiguity about what was asked.
A different problem than per-language quality QA
Ongoing translation-quality QA, covered elsewhere in this series, is about whether the agent's output in a given fixed language is accurate and natural over time. Code-switching is a real-time detection and continuity problem: a customer, often bilingual, drops into a second language for a phrase, a sentence, or an entire message, then may switch back, sometimes within the same message. The quality of the agent's Spanish or its French is not the issue here; the issue is whether the agent notices the switch happened at all and keeps the conversation coherent across it.
Why per-message detection beats a conversation-level language lock
A common and brittle implementation detects the conversation's language once, from the first message, and holds that setting for the rest of the session. That works until a customer who started in English drops into their native language to express frustration, or a customer fluent in two languages simply mixes them naturally, which is normal bilingual speech, not an error condition. Detecting language at the message level, and treating a mid-message mix as a valid input rather than noise to normalize away, avoids the failure mode where the agent replies in the wrong language immediately after the customer switched, which reads as not having been listened to.
Respond in the language just used, not the conversation's starting language
The default response behavior should mirror the customer's most recent message, not their first one. A customer who spent four messages in English and then asked a question entirely in Portuguese is signaling something, often that the Portuguese phrasing captures what they mean more precisely, and replying in English anyway forces them to either switch back or repeat themselves. This is a small design choice with an outsized effect on whether the interaction feels like it is keeping up with the customer.
Preserving context across the switch
The harder engineering problem is making sure the agent's understanding of what has already been discussed survives the switch intact. If the agent's retrieval or reasoning pipeline treats each language as a separate context, a customer switching languages mid-conversation can trigger the agent to lose track of what was already established, forcing them to restate information they already gave in the other language. Test this scenario specifically, not just each language independently, since per-language accuracy testing will not surface a continuity failure that only shows up at the switch point itself.
When to ask for a preference instead of guessing
Code-switching usually does not need to be resolved into a single language at all, but genuine ambiguity, a single word that has different meanings across the two languages in play, or a phrase where the intended language materially changes the answer, is worth a brief clarifying question rather than a guess. The bar for asking should be real ambiguity, not the mere fact that mixing occurred, since asking every time a customer naturally code-switches signals that normal bilingual speech is being treated as a problem.
FAQ
Should the agent ever ask a customer to pick one language for the whole conversation?
Generally no, unless the mixing is causing repeated misunderstandings. Forcing a single-language mode contradicts how many bilingual customers naturally communicate and adds friction without a clear benefit.
Does this require a different underlying model than single-language support?
Not necessarily a different model, but it does require testing multilingual and code-mixed inputs specifically, since a model that scores well on each language in isolation is not automatically good at recognizing a switch mid-message.
How is this different from supporting multiple languages in general?
Supporting multiple languages is about the agent being usable in each language on its own. Code-switching support is specifically about handling a single conversation that moves between languages, which is a narrower and often overlooked case even in agents that otherwise support many languages well.