The AI you approved in March is not the AI answering your phone today.

You sat down in March, listened to how it handled six calls, changed two answers you did not like, and signed it off.

It has been answering ever since. What has not been sitting still is the thing underneath it.

Models have expiry dates

This is not a rumour or a risk somebody is speculating about. It is published policy.

Anthropic, to take one provider that documents this openly, describes a model lifecycle with four states: active, legacy, deprecated and retired. A deprecated model is still functional but no longer recommended, with a named replacement and an assigned retirement date. A retired one is simply gone, and requests to it fail.

Other providers set their own schedules and publish their own policies. The point is not the particular dates. It is that the component your product is built on has a lifespan that was decided somewhere you have never been.

The notice does not come to you

Read who gets told. Anthropic notifies customers with active deployments, giving at least sixty days before retirement for publicly released models.

That customer is the developer. If you bought an AI receptionist from a company that built it on somebody's model, the sixty-day email lands in their inbox, not yours. You are two layers away from the only warning that exists.

Which is reasonable. It is also why the change reaches your business with no announcement attached.

It arrives as a behaviour change, not an error

Nothing breaks on the day your vendor migrates.

The phone still answers. The calls still connect. What shifts is judgement at the edges: how it handles somebody who is annoyed, whether it now volunteers a price it used to deflect, how it reads a caller who trails off mid-sentence. All of that is behaviour rather than function, and no dashboard has a metric for it, which is precisely the shape of an automation that stops doing its job without ever erroring.

The provider documentation even says the sensible thing here, which is to test your application thoroughly against the new model well before the retirement date. Whether that testing includes the twenty answers you personally approved is a question about your vendor rather than about the model.

Your date is not the published date

One detail worth knowing because almost nobody does.

The same model can retire on different schedules depending on which cloud it is served from, because partner-operated platforms set their own dates. So the timeline that governs your phone was fixed by an infrastructure decision your vendor made before you were a customer, and looking up a public retirement date will not necessarily tell you your own.

Three questions, asked politely

None of this is a reason to avoid buying these tools. It is a reason to ask about maintenance, the same way you would about any other system you depend on.

Which model is behind this, and where is it in its lifecycle. What happens on the day it retires, and will you tell me before or after. And when you move me to a replacement, who re-checks that it still answers my callers the way I signed off.

A vendor who answers those readily is running a maintained product. One who has never thought about it is reselling something they do not operate, which is worth knowing before your phone is on it.

What to keep on your side

Keep your own copy of the answers you approved, in a document you control, rather than only inside somebody's configuration screen.

Then call your own number once a quarter and run four or five awkward scenarios past it. The angry caller, the one asking for a price, the one outside your area, the one who wants a job you do not do. It takes fifteen minutes and it is the only check that measures the thing you actually care about, which is what it commits you to rather than whether it responded.

If something is answering your phone and you cannot say what is underneath it, book a strategy call and we will work out what you are actually running.