What is AI drift, and why do good agents get worse?

AI drift is the gradual or sudden change in how an AI system behaves over time, even though nobody set out to change it. For a customer-facing chatbot, voice agent or AI support agent, it means the system your customers talk to today may not behave the way it did when you tested and launched it. Answers get longer or shorter, refusals appear where there were none, a policy is explained differently, or a handoff that used to work quietly stops happening.

In machine learning, drift often refers to data drift or concept drift: the world a model was trained on moves away from the world it is used in. For a business running a customer-facing agent built on a large language model, the practical definition is simpler and broader. Anything that changes the agent’s behavior without a deliberate, tested decision on your side is drift. This guide explains where it comes from, what it has looked like in public, and how to catch it before your customers do.

What AI drift means for a customer-facing agent

A modern customer-facing agent is rarely one thing. It is usually a stack: a foundation model from a vendor, a platform that wraps it, a set of instructions or prompts, a knowledge base of your policies and products, and integrations into your order system, calendar, CRM or phone line. Each layer can change independently, and each change can alter what a customer experiences.

That is the core reason drift matters to a business owner. You can test an agent thoroughly at launch and still be surprised three months later, not because the launch test was wrong, but because the thing you tested no longer exists in exactly that form.

Vendor model updates and retirements

The most common source of drift is the model underneath the agent. Model vendors release new versions, update existing ones and retire old ones on their own schedules. They publish these lifecycles openly. OpenAI’s API deprecations page says that as it launches newer models it regularly retires older ones, and that software relying on its models may need occasional updates to keep working. Anthropic’s model deprecations page describes a lifecycle in which models move from active to legacy to deprecated to retired, after which requests to them fail.

When a model is retired, whoever runs your agent has to move it to a newer one. Newer models are often better overall, but better overall is not the same as identical on your specific conversations. A replacement model can phrase refusals differently, follow instructions more or less literally, or handle an ambiguous question in a new way.

Behavior can also shift between versions of what customers experience as the same service. A widely cited 2023 study by Lingjiao Chen, Matei Zaharia and James Zou, How is ChatGPT’s behavior changing over time?, compared March 2023 and June 2023 versions of GPT-3.5 and GPT-4 on the same tasks and found that performance and behavior could vary greatly between versions, including changes in willingness to answer some kinds of questions and in how well the models followed instructions. The authors concluded that the behavior of the “same” LLM service can change substantially in a relatively short time, and called for continuous monitoring.

If you buy your agent from a platform rather than building it, you may not be told when the model underneath changes. Many platforms upgrade models for all customers as part of normal product updates. Ask your vendor which model your agent runs on, how you will be notified of changes, and whether you can pin a version.

Prompt and knowledge base changes

The second source is your own side. Instructions get edited to fix one complaint and quietly break something else. A new product page is added to the knowledge base, and an old one with outdated pricing is never removed. A seasonal promotion is added to the prompt and never taken out.

These changes are made with good intentions, often by different people at different times, and they are rarely tested against the full range of conversations the agent handles. A single sentence added to fix a refund answer can change how the agent responds to every question that mentions money.

Knowledge base drift deserves special attention because it produces the most damaging failure: a confident, wrong answer about a price or policy. If your agent retrieves information from documents, any time those documents change, the answers change with them.

Integration and tool changes

Agents that take actions, such as looking up an order, booking an appointment, issuing a refund or transferring a call, depend on connections to other systems. When those systems change, the agent can fail in ways that look like an AI problem but are not. An order system field is renamed and lookups start failing. A calendar integration changes its time zone handling and bookings land an hour off. A phone system update changes how transfers work, and the handoff to a person drops.

From the customer’s side, none of these distinctions matter. The agent said it booked the appointment and it did not. That is why testing from the outside, the way a customer experiences the whole stack, catches problems that testing any single layer can miss. See how to test AI agents your customers talk to for agents that take actions.

Your customers change too

Not all drift is in the system. Customers change what they ask about. A new product launches, a shipping problem hits the news, a price rises, or a competitor runs a promotion, and suddenly a large share of conversations are about something the agent was never tested on.

Customer expectations also move. As people get used to AI agents elsewhere, they phrase requests differently, ask for a person sooner or later, and try things they would not have tried a year ago, including deliberately trying to talk a bot into saying something it should not. An agent can perform exactly as it did at launch and still serve customers worse, because the customers are not the same.

What drift has looked like in public

Two publicly reported cases show how a change on the system side can turn into a customer-facing problem.

In January 2024, the parcel delivery company DPD disabled the AI element of its online chat after a customer got it to swear and to criticize the company. Time reported that DPD said an error had occurred after a system update and that the AI element was immediately disabled and being updated.

In 2023, the National Eating Disorders Association took down its chatbot, Tessa, after it gave weight loss advice to people asking about eating disorders. NPR reported that Tessa’s responses had originally been preprogrammed, and that the company operating it later added generative AI as part of what its CEO described as a systems upgrade.

In both cases, the system customers met was not the system that had originally been designed. You can read more cases like these, and the human test that would likely have surfaced each, in our guide to chatbot failures in business.

Why dashboards often miss it

Most teams watch their agent through a vendor dashboard: containment, resolution, handle time, satisfaction ratings. These numbers are useful, but they are measured by the same system that is drifting, and they tend to move slowly. A change in tone, a new habit of inventing a policy, or a broken handoff for one type of request can hide inside a healthy looking average for weeks.

Dashboards also count what the system can see. They do not see the customer who gave up and called instead, or who bought from a competitor. Our guide to chatbot KPIs and what they miss goes through each common metric and the specific way it can hide a problem.

Automated tests that run a fixed script against the agent are valuable for catching outright breakage. They are less good at catching the subtle shifts that make a real customer give up, because the judgment of whether an answer was good enough is itself automated. The question “would I have stayed?” needs a person.

How to detect drift with a fixed rubric

Detecting drift is a measurement problem. To know whether something changed, you need to measure it the same way, repeatedly, and compare. For a customer-facing agent, that means three things held constant.

1. The same scenarios. Keep a core set of customer scenarios that covers your top tasks and your riskiest areas: refunds, pricing, cancellations, requests for a person. Run them every time. You can add new scenarios as your business changes, but keep the core set fixed so results stay comparable.
2. The same personas. An angry customer, a confused first-timer, someone asking for a human, a non-native speaker. Run the same personas each time so a change in results reflects a change in the agent, not in who was testing it.
3. The same rubric. Score every session on the same criteria and scale. We use eight criteria scored 1 to 5 with a written reason for each score, published on our rubric page. A fixed rubric turns impressions into a trend line you can read.

Then rerun on a schedule. Monthly works well for most businesses: frequent enough to catch a change within weeks, not so frequent that the effort becomes a burden. Track each rubric criterion separately as well as the overall score, because drift often shows up in one criterion first. A drop in “got it right” points to knowledge or model changes. A drop in “handoff” often points to an integration or phone system change.

• Write down which model and platform version your agent runs on today.
• Ask your vendor how you will be told about model changes, and whether you can pin a version.
• Fix a core set of scenarios and personas, and store the exact wording.
• Score a baseline run on a fixed rubric and keep every transcript.
• Rerun the same set monthly and chart each criterion separately.
• Agree in advance how large a drop triggers a closer look.
• Keep a simple change log of prompt, knowledge base and integration edits, with dates.

This is exactly what our Watch plan does: a small monthly panel of real people runs the same scenarios on the same rubric, you get a trend line per criterion, and you are alerted when the score drops.

When to rerun outside the schedule

Some changes are too significant to wait for the next monthly run. Rerun your core scenarios after any of the following:

• Your vendor announces a model change, retirement or platform upgrade.
• Anyone edits the agent’s instructions or prompts.
• You change prices, policies or products the agent talks about.
• You add, remove or restructure knowledge base documents.
• An integration it depends on (orders, calendar, CRM, phone system) is updated.
• You expand to a new channel or language.
• Customers start complaining about something the agent said.

Our page on testing after an update covers how a rerun after a change is set up and what it compares against.

What to do when the score drops

A drop is a signal, not a verdict. Start with the transcripts behind the lower scores and read what the testers actually experienced. Then match the timing against your change log and your vendor’s announcements. Most drift can be traced to a specific change once you know when the score moved.

Hand the transcripts and the criterion that dropped to whoever maintains your agent, whether that is your own team or your vendor. Specific, reproducible examples (the exact wording, what the agent said, why the tester scored it low) are far more useful than a general complaint that the bot got worse.

We only diagnose. We do not sell fixes, tuning or consulting, which is why a score from us has no reason to be higher or lower than what testers saw. When you are ready to measure your agent the way your customers experience it, request a test.