"Bhai, kal ka appointment confirm karna tha, but I'm not sure what time works — evening mein free ho?"
That's a completely ordinary sentence for a huge number of Indian callers, and it's also the sentence that breaks a lot of voice AI. It's not Hindi. It's not English. It's both, switching mid-thought, sometimes mid-word, without the speaker noticing they did it at all. If you've spent time on the phone with Indian customers, you already know this. If you've tried to build a voice model that handles it, you know it's genuinely hard.
It's also not unique to Hindi and English. A caller in Chennai might ask "andha slot available-a?" — Tamil grammar carrying an English noun without missing a beat. A caller in Kolkata might open in English and drop into Bengali the moment the question gets specific. A caller in Bangalore might ask "next week yavaga free?" mixing Kannada and English the same way. The pattern is the same everywhere in India: two languages, one sentence, no signal that a switch is coming, and no expectation from the speaker that anyone should find it unusual.
Why code-switching breaks most systems
Most language models are trained to expect one language at a time — the same single-language assumption that trips up plenty of text-based multilingual systems too, a problem W3C's internationalization work has documented well beyond just voice AI. Feed a Hindi-only model a Hinglish sentence and it either mishears the English fragments as garbled Hindi, or it gets the words right and responds in stiff, overly formal Hindi that doesn't match the register the caller used. Feed an English-only model the same sentence and it stumbles on "kal ka" and "evening mein" the same way.
The translation-layer approach — common in "multilingual" AI that's really an English model with a wrapper — fails even harder here. Translation systems are built to translate between languages, not to handle a sentence that's already doing both at once. Ask one to translate "evening mein free ho?" into clean English or clean Hindi and it has to guess which language the sentence is "really" in, throwing away the code-switch instead of understanding it. That guess is where the meaning goes wrong, because the sentence was never meant to resolve into one language in the first place — the mixing itself is part of what the speaker meant.
The speech-recognition layer makes this harder still
Code-switching isn't only a language-understanding problem — it starts one step earlier, at the level of recognizing what was even said. A speech recognizer tuned for one language has expectations baked in about which sounds are likely to follow which, and a sentence that jumps languages mid-stream breaks those expectations right at the seam. Get the transcription wrong at that boundary and everything downstream — understanding the request, generating a reply — inherits the error. Handling code-switching well means getting this right from the first step, not patching it in afterward at the response-generation stage.
What we did differently
We didn't try to detect the language and switch models mid-sentence — that's a losing game when the switch happens inside a single clause. Instead, we trained on conversational data that already contains the code-switching: real Hindi-English calls, Tamil-English calls, Bengali-English calls, all with the mixing intact, not cleaned up into "proper" single-language sentences before training. The model learns code-switching the way a bilingual speaker does — as the normal shape of a sentence, not an exception to handle.
This isn't Hindi-English only. Every regional language AIVA supports has its own code-switching pattern with English — Tamil speakers mixing in English nouns mid-sentence, Bengali speakers doing the same, Kannada callers dropping into English for numbers and brand names. We trained for all of it, not just the most talked-about version.
Matching register, not just words
Getting the words right is half the problem. The other half is replying in the same register the caller used. A caller who opens with "bhai" and drops articles the way casual speech does is signaling something about how formal this conversation is. Reply with a stiff, textbook-formal sentence and the mismatch is obvious even if every word is correct — it reads like talking to a customer service script instead of a person. AIVA's model matches the register it hears: casual in, casual out; formal in, formal out.
This matters most in exactly the moments a business cares most about getting right. A patient describing symptoms in a rushed, worried mix of Hindi and English needs a reply that matches that urgency, not a serene, fully-formal response that feels like it wasn't listening. A customer casually confirming a salon booking with "Saturday ko slot hai kya" doesn't want a reply that sounds like a legal notice. Register mismatch doesn't just sound odd — it actively signals to the caller that they're talking to something that processed their words without understanding their tone.
What this looks like on a real call
The caller above — asking about tomorrow's appointment, unsure about timing, wanting an evening slot — gets a direct answer in the same mixed register, not a stilted "Aapka appointment kal hai. Kripya samay bataen." A clinic call that opens "doctor available hai kya abhi?" gets answered directly, in the same mix, instead of routed through a menu that assumes one clean language. A salon caller who asks "colour ke liye kitna time lagega, aur price kya hai?" gets both answers in one reply, in the same register, instead of a system that quietly drops the half of the sentence it didn't recognize. AIVA responds in around 198ms on average and resolves about 96% of voice calls without needing a human on the line, and code-switched calls aren't treated as a fallback case — they're most of the calls.
Why this required rethinking the whole pipeline, not patching one layer
It would have been faster to bolt a code-switching detector onto an existing single-language pipeline — flag the mixed sentences, route them somewhere special, ship it. We didn't do that, because a bolted-on detector is exactly the kind of shortcut that works in a demo and falls apart on the actual range of real calls. Building it into the core training data, for every language AIVA supports, was slower. It's also the only version where a code-switched sentence isn't handled as a special case at all — it's just handled, the same way any other sentence is.
Why this matters beyond the demo
A voice product that can't handle code-switching doesn't fail loudly. It fails quietly, by sounding slightly off in a way that makes callers switch to typing, or hang up and call a competitor instead. Handling it properly is one of those pieces of engineering that customers never mention by name and would notice immediately if it broke. It's also a direct extension of why regional-language AI is a harder engineering problem than translation in the first place — a translated system can't handle code-switching well for the same underlying reason it can't preserve tone: it's built to resolve everything into one language, and a code-switched sentence refuses to be resolved that way.
See AIVA's full language coverage — twelve languages, and the code-switching between every one of them and English, handled the same way. It works identically across voice, web chat, and SMS, and if you want to hear it on a real call rather than take our word for it, start free with ₹500 in credit and try it on your own number.