Port an existing voicebot

The goal is to keep the bot's business behavior and delete its duplicate voice infrastructure.

1. Map existing code

Existing code	VAANI destination
persona and flow prompts	dynamic prompt function
personalized first message	dynamic greeting function
caller/customer lookup	@assistant.prepare
CRM or business action	annotated @assistant.tool
session business data	immutable Call.state
alternate flows	named prompts + switch_prompt
language change	preset language bindings + switch_language
ending and transfer	VAANI standard tools
providers, models, VAD, noise, timing	reviewed preset
LiveKit worker, audio, transcripts	VAANI runtime
frontend and telephony	bot/deployment

2. Start beside the existing bot

Generate a separate application. Do not edit the production bot during the port.

Follow the pinned private-GAR install and generate flow, using my-bot-vaani as the project name.

Choose the closest reviewed preset. Move preparation, greeting, prompts, and one complete business flow first.

Migrate preset-only startup

VAANI and the Starter supply the environment, evaluation, deployment, and Assistant(environment=...) APIs used in this migration.

Keep the preset while introducing the environment contract:

1. Add separate, complete, versioned development and production TOML documents. Never merge them or use one as defaults for the other.
2. Put the current preset in both. For development, define the provider/model targets that testers may combine. In production, add one Production Deployment Profile and its reviewed lock.
3. Set VAANI_ENVIRONMENT=development in local startup and VAANI_ENVIRONMENT=production in the deployment. Resolve bootstrap_environment() once and pass it to Assistant.
4. Replace hard-coded frontend options with the backend catalog response. Submit one returned STT ID, LLM ID, TTS ID, language, and voice.
5. Generate and review the production deployment lock, then run connected browser-room and SIP calls before routing traffic.

Do not accept arbitrary per-call provider settings. Bind the backend-approved catalog selection in development; production accepts no selection.

3. Preserve behavior before improving it

Compare the old and new bots for:

• personalized greeting and initial response time;
• language and prompt switching;
• every business tool and failure message;
• silence nudges, interruption, ending, and transfer;
• participant and assistant transcripts;
• analytics, Judge output, and terminal result;
• provider, model, voice, noise, and timing settings.

Do not change business wording and runtime behavior in the same step. A parity regression should have one likely cause.

4. Remove duplicate infrastructure

Once live parity is proven, remove consumer-owned:

• provider client construction;
• LiveKit worker/media and transcript code;
• VAD, buffering, endpointing, and playout loops;
• shared standard-tool implementations;
• duplicated metrics and call-lifecycle logic.

If the Assistant API or preset cannot express required shared behavior, add that capability to VAANI first. Do not hide a second runtime inside the bot.

5. Accept the port with real calls

Run browser and SIP calls using the target credentials and APIs. Cover each language and major branch, test interruption and silence, confirm transcripts, and compare measured response latency with the current bot. Complete the production checklist before routing traffic.

See the advanced loyalty example for a scoped, non-acceptance example of keeping a large business-flow model in consumer code.