Most AI voice agents cannot take a phone call in Malayalam, and the reason is not that nobody has asked. It is that a voice agent is three separate systems in a row — speech recognition, a language model, speech synthesis — and Malayalam breaks each of them for a different reason. A platform that buys all three from one vendor cannot fix any of them independently, so its language list can never be longer than that one vendor's language list.
The stage that actually stops the call is the last one. A model that can read Malayalam is common. A speech engine that will speak it, on a phone line, in a voice a caller does not immediately hang up on, is not.
Stage one: recognition, where the training data is not there
Malayalam has roughly 35 million speakers, nearly all of them in one Indian state and its diaspora. The public audio corpora that multilingual speech models are trained on are measured in hundreds of thousands of hours for English and in the low hundreds of hours for Malayalam. A model card listing 99 languages is telling you which languages the model will produce output for, not which ones it is accurate in. Word error rate is a per-language number, and vendors rarely publish the per-language table.
Two properties of the language make the gap worse than the data ratio suggests. Malayalam is agglutinative: a single written word can carry a verb, its tense, its agreement and a postposition that English would spell as four separate words. One wrong morpheme does not corrupt one word, it corrupts the clause. And real callers code-switch constantly — a Malayalam sentence with an English product name, an English date and an English verb stem sitting in the middle of it. A recogniser tuned on clean monolingual Malayalam reads that as noise.
Stage two: the model, which is usually the part that works
Large language models handle Malayalam text better than most people expect, because text is the modality with the most data. The failure at this stage is subtler, and it is a failure of output rather than comprehension: the model writes a correct Malayalam sentence and leaves the proper nouns in Latin script, because that is how they appeared in its training data and in your knowledge base. The sentence is right. It is also now two scripts, and it is about to be handed to a speech engine.
Stage three: synthesis, where the call actually dies
This is the stage that fails hardest, and the failures are blunt. A vendor's documentation lists Malayalam, you send the language code ml, and you get back HTTP 400. We hit exactly this: one generation of a speech model rejected ml outright while the language was listed as supported, and the next generation of the same model synthesised it correctly. Both facts were true on the same day, about the same vendor. Which model version serves your traffic is not a detail — it is the entire answer.
Where support does exist it is often thin in ways that only show up on a real call: one voice rather than a range, the wrong gender for your brand, no control over speaking rate, no pronunciation overrides for the twelve words your business says constantly, and a model trained on read speech rather than conversation — which sounds like a news bulletin when what you need is a receptionist.
Script mixing is a pronunciation bug, not a cosmetic one
A speech engine chooses its pronunciation frontend from the script it is given. Hand it a Malayalam sentence with the name Ravi still in Latin characters and it has to decide what to do with those four characters. Some engines apply English phonology mid-utterance, which sounds like a different person interrupted. Some spell the word out, letter by letter: R, A, V, I. We shipped that bug. On an outbound call that greets the customer by name, it is the first thing the caller hears.
The fix is a rule enforced before the text ever reaches the speech stage: one script per utterance. If the agent is speaking Malayalam, then names, places and product names are transliterated into Malayalam script rather than passed through in Latin. That constraint has to live where the text is generated, because the speech engine has no way to recover from a mixed string after the fact.
An accent setting is not language support
A voice list containing “Indian English” is a list of English voices. An accent changes which phonemes English is realised with. It does not add the Malayalam phoneme inventory, it does not add a Malayalam pronunciation frontend, and it does nothing at all to the recogniser, which is a separate model that was never asked about the accent setting. A platform offering Indian-accented English and a platform offering Malayalam are not competing on the same axis. One of them can take the call and one cannot.
Four questions separate them in about a minute:
- Ask for the speech recognition language list and the speech synthesis language list separately. If you get one list, they have one vendor, and the honest answer is probably English.
- Ask which model version serves each language. “We support Malayalam” is a claim about a documentation page. “Malayalam recognition runs on this model and synthesis on that model version” is a claim you can test.
- Ask the agent to say a Malayalam sentence containing an English name. Listen for spelling, and for the accent changing mid-sentence.
- Say something code-switched to it — a Malayalam sentence with an English date in the middle — and read the transcript, not just the reply.
What works: a different vendor for each language
Our Malayalam calls run Sarvam's Saarika model for speech recognition and Cartesia's sonic-3 for speech synthesis. Our English calls do not use that pair. Neither vendor was chosen for being best overall, because there is no such thing: a company that has done the work of collecting conversational Indic audio is not automatically the company with the lowest-latency English voice, and there is no reason it should be.
The consequence is that “which speech vendor do you use” is a question with no single answer. Any platform that can answer it in one word has just told you where its language ceiling is.
This is only possible because the pipeline is modular
Each stage of our pipeline is an adapter behind a uniform interface. The agent configuration does not name a speech vendor; it names a language. The gateway resolves that language to a recognition adapter and a synthesis adapter at call time. Adding a language means writing or configuring an adapter. Replacing the Malayalam voice means changing one row, not migrating a platform.
It also means the failures above are recoverable rather than terminal. When one model version rejected ml, the fix was to point the Malayalam route at a different model version and re-run the call. On a welded stack, that same incident is a support ticket and a wait.
The part nobody puts on a slide
Per-language work is per-language work. Each language needs its own vendor evaluation, its own latency measurement on a real phone line, its own pronunciation checks with native speakers, and its own regression pass when a vendor ships a new model. We support Malayalam, Hindi and Tamil for both recognition and synthesis on real phone calls. That list is short because it is a list of languages we have run end to end on the public telephone network, not a list of language codes an API will accept without returning an error.
If your customers call you in a language your platform treats as an accent, the agent answers in English, the caller switches to English or hangs up, and the transcript makes it look as though the language was never needed. That is the failure mode to watch for. It is silent, and it arrives disguised as data.