Sarvam Bulbul V3 Retirement: How to Move Voice Agents to V4

Sarvam is retiring Bulbul V3 from its Voice Agents platform on November 10, 2026. Agents using it need to move to Bulbul V4 before that date. The direct Text-to-Speech API is excluded: Bulbul V3 remains available there. Check which product your application uses before changing anything.

For teams running customer calls, this is a small configuration change with a real deadline. The sensible approach is to migrate the voice, test it against the conversations customers actually have, and deploy a known version. Rewriting the agent's entire prompt at the same time makes any regression harder to explain.

What the November 10 deadline covers

Sarvam's October 14 notice explicitly limits the retirement to Voice Agents. If you built an application that calls the TTS API directly with Bulbul V3, this notice does not require you to replace that integration. If you configured an agent inside Sarvam's Voice Agents platform, inspect its speaking model.

The notice does not specify a cutoff time or promise automatic migration. Finish the change before November 10, rather than building a rollout plan around an assumed grace period. An old announcement becomes operationally important when the deadline is two days away.

Change the model and choose the matching voice

Open the affected agent's Settings, find Speaking, and select Bulbul V4 as the model. Then choose the replacement voice from the catalog. Sarvam provides a V3-to-V4 voice-name mapping, so an unfamiliar label need not mean your previous voice disappeared.

For example, Ritu becomes “Ritu - Hindi Support Agent,” while Shubh becomes “Shubh - Hinglish Ad Voice.” Use the published mapping instead of choosing a similar-looking name. Preview the selection, but treat that preview as a first check rather than proof that it works in your call flow.

Also inspect per-language voice overrides. They take precedence over the default voice; a missing language mapping falls back to the default. Sarvam says the voice chosen for a call's starting language stays consistent even if the caller switches languages. Check these routes separately rather than assuming a default-voice change covers every caller.

Keep the migration separate from prompt changes

Before editing, record the deployed version, selected voice, language configuration and current test results. This creates a useful comparison point. It also prevents a common debugging mistake: comparing a new model plus a rewritten prompt against an old model with different instructions.

Sarvam's versioning workflow distinguishes draft, committed and deployed configurations. Save the change as a version, test that version, then deliberately deploy it. Editing a draft is not evidence that production has moved.

The platform supports returning to an earlier committed version, but an old Bulbul V3 configuration is a poor recovery plan for a retirement deadline. Prepare a working V4 version you can return to if later tuning makes things worse. Keep optional changes to speed, prompt wording or conversation design for a separate iteration.

A worked test plan for a support agent

Consider a fictional delivery-support agent that currently uses Ritu. The migration target is the mapped V4 voice, with the existing business instructions unchanged. A useful test set would cover an ordinary delivery enquiry, an interrupted answer, and a request to repeat a street or product name. Use synthetic customer details rather than real personal information.

Sarvam's Tests tab runs a simulated user against an agent version and has an AI judge grade expected behaviours. Use those tests to check whether the agent still follows its instructions. They should be complemented by listening to actual test-call audio: a correct transcript cannot tell you whether a name was easy to understand.

For the delivery enquiry, give the simulated caller one clear goal: ask when a fictional parcel will arrive, then request clarification of the delivery window. Expected behaviours might be that the agent asks for the required reference, uses the configured lookup tool, and repeats only the window that tool returns. These are suggested acceptance checks, not results from a test performed here.

For the audio check, listen for intelligible names and numbers, a clear response after an interruption, and whether repetitions help rather than repeat the same ambiguity. Compare the old and new versions using the same short script. Write down the outcome of each check instead of recording a general impression that V4 “sounds better.”

Confirm the deployed agent, not just the draft

After deployment, verify that the version serving calls uses V4. Run an authorised test through the same entry point customers use, then review the result. Repeat this for each affected agent, including less frequently used ones that are easy to miss when checking only the main support flow.

The useful completion record is short: agent, deployed version, V4 voice, tested language routes and unresolved issues. A migration is complete when the deployed configuration has passed the checks, not when someone has selected a new model in a dropdown.

That discipline is worth keeping after this deadline. Voice-model upgrades will keep arriving, and a small repeatable test set makes the next change a release decision rather than a last-minute listening exercise.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn product changes and complex engineering work into clear stories developers and customers can use.

Book a 30-minute call.