Model migrations and sunsets: how a voice AI platform keeps running when the models change under it

If you build a voice agent on a single hard-coded model, you've built a countdown timer. STT, LLM, and TTS models now ship new versions every few months, older ones get deprecated on a published schedule, and capabilities move between versions in ways that quietly change agent behavior. A resilient voice AI platform treats "the models will change under us" as a first-class design assumption — not an incident. This post is how that's actually done.

For the fundamentals of how agents are assembled, start with our complete guide to AI voice agents; here we go one layer down, into keeping them alive as the model landscape shifts.

Why model churn is constant now

A production voice agent is usually three models in a pipeline — speech-to-text (STT), a language model (LLM), and text-to-speech (TTS) — or, increasingly, a single speech-to-speech realtime model. Every one of those is a moving target:

• New versions ship (a better, cheaper, or faster generation).
• Providers sunset older versions with a deprecation date, after which calls fail.
• Capabilities are not stable across versions — a newer realtime model might drop proactive audio or async function calling, or swap a `thinkingBudget` parameter for a `thinkingLevel` one.
• Speech models carry a knowledge cutoff — anything after that date the model simply doesn't know.

If any of that is wired directly into your agents, each change is a migration project or an outage. The fix is indirection.

Principle 1: a model registry, not hard-coded model IDs

Agents should reference a model by a stable key ("the fast realtime model"), not a raw provider model ID. A central registry maps keys → concrete provider models, per capability (STT / TTS / LLM / realtime). When a provider ships a new version, you update one registry entry; you don't touch a single agent.

This one indirection buys you almost everything else: staged rollouts, per-tenant overrides, and the ability to repoint a key the moment a provider announces a deprecation.

Principle 2: permanent back-compat aliases

When you rename or replace a model key, thousands of existing agent configs still reference the old name. Deleting it breaks them. So renames ship with a permanent alias table: the old key resolves to the new one forever, consulted before the registry lookup.

Concretely, when we renamed a generic realtime key to a version-specific one, we added a `LEGACYKEYALIASES` map so every agent still pointing at the old name keeps working with zero edits. Aliases are cheap; broken agents are not. The rule: you can rename, but you can never make the old name a hard error.

Principle 3: migrations are reversible and idempotent

Some changes do need to rewrite stored data — for example, moving every agent's stored `REALTIMEMODELKEY` from an old value to a new one, plus the associated voice/TTS keys and defaults. Those run as data migrations with three non-negotiable properties:

1. Idempotent — running it twice does nothing the second time. Migrations get retried; they must be safe to re-run.
2. Reversible — a `down` path restores the prior state. If a new model regresses in production, you roll back data, not just code.
3. Cache-aware — after rewriting config, invalidate the platform-settings and registry caches, or the app keeps serving the old values.

A migration that rewrites JSON config across agents, tenants, and partner accounts — and can be cleanly reversed — turns a scary model swap into a routine, revertible deploy.

Principle 4: gate on capabilities, not version numbers

Here's the subtle one. Two versions of "the same" model family often differ in what they support. A newer realtime model might have no proactive audio, no affective dialogue, no async function calling, and use a different thinking-control parameter than its predecessor. If your code assumes the old capability set, the new model "works" but behaves wrong — a sync function call that stalls audio, or a feature that silently no-ops.

The defense is capability gating: the code checks what the resolved model supports and adapts, rather than assuming. A quality feature that stalls audio on one realtime model but is safe on another should be enabled only where it's safe. Version numbers are a poor proxy for behavior; explicit capability flags are the real contract.

Principle 5: plan for the sunset before it's announced

Deprecations come with dates. A platform that references models through a registry can repoint a sunsetting model to its successor across every agent with one change, staged and monitored. A platform that hard-codes models gets a fire drill. The difference isn't luck — it's the indirection you built months earlier.

There's an adjacent trap worth naming: stale keys. If an agent carries a model key that no longer applies to its current mode (say, a realtime key on an agent now running in pipeline mode), you want that scoped and ignored, not blindly honored. Handling the "this config is stale" case gracefully is part of surviving churn.

Principle 6: knowledge cutoffs are a product concern, not a footnote

Every speech/LLM model has a training cutoff. For a voice agent that must state current facts — today's pricing, a policy that changed last week — the model's own knowledge is not a safe source. The pattern is to inject current facts at call time (from your CRM, a pre-call context API, or an explicit "facts you know" block) rather than trusting the model to remember. When you migrate to a newer model with a later cutoff, that scaffolding still protects you; when a provider's cutoff is earlier than you expected, it saves you from confidently wrong answers.

What this means when you're choosing a platform

Model resilience is invisible in a demo and decisive in production. Questions worth asking a vendor:

• Do agents reference models by a stable key, or is the model hard-coded?
• What happens to my existing agents when you rename or deprecate a model?
• Can you roll back a model change, including any data it rewrote?
• How do you handle capability differences between model versions?
• How do current facts get into calls given model knowledge cutoffs?

A platform that has real answers here is one where your agents keep running while the industry re-invents its models every quarter. That's the whole game. See how we think about model choice and control in models & languages, and how we help you choose a voice AI agent.