From Sanskriti Khandelwal | Product & Market Analysis
Agent Drift: Deployed AI Changes Underneath You, and Only 14% of Teams Watch
On this page
Your deployed AI system is changing while you read this. Model versions retire, retrieval corpora grow, prompts accumulate patches, and none of it fires an alert. Agent drift is the distance between the behaviour you tested and the behaviour you are shipping today. Only 14% of observability teams monitor LLM applications in production. Most of the rest hear about it from a customer.
Key takeaways
- Drift has four independent sources and only one of them is the model. Provider updates, shifting user inputs, growing retrieval corpora and your own accumulated prompt patches all move behaviour, and they move it on different clocks.
- The behaviour change is measured, not theoretical. Across four months of 2023, GPT-4 fell from 84.0% to 51.1% on prime identification while GPT-3.5 rose from 49.6% to 76.2% on the same task, in peer-reviewed work published by Harvard Data Science Review.
- The migration calendar belongs to your provider, not to you. Nine Claude models retired in the 12 months to 23 August 2026, and Anthropic's published notice floor is 60 days against OpenAI's stated 6 months for generally available models.
- Only 14% of observability teams monitor LLM applications in production. That is up from 5% a year earlier, which means the instrumentation gap is closing slowly while deployment races ahead of it.
What agent drift actually is
Agent drift is the accumulated behaviour change in a deployed AI system that nobody deliberately shipped. The output is still fluent, the API still returns 200, and the answers are quietly different from the ones you signed off. It matters because nothing in a normal application stack watches for it.
This post is written for whoever runs delivery. If you own the on-call rota for a system that calls a model, this is your problem before it is the data scientist's. The failure arrives as a support ticket rather than an exception.
Four sources of change, and only one is the model
Teams hear "drift" and think about the provider. That is one input of four, and it is the only one you can blame on somebody else.
The other three are yours. User inputs shift as your product finds new customers. Retrieval corpora grow, and the document that used to rank first stops ranking first. Prompts accumulate patches, each one added to fix a specific complaint, each one changing behaviour on cases nobody retested.
Drift is not a bad model. It is an unnoticed one.
A model that fails loudly is a good model for operations. You get a stack trace, an alert and a rollback. Drift is the opposite shape of problem, because every individual response looks plausible.
That is the whole reason it survives. Plausible wrong answers pass every check a normal service has, and they keep passing until a human with domain knowledge reads enough of them to notice a pattern.
| Source | What moves | Earliest honest detection | Cadence |
|---|---|---|---|
| Provider model update or retirement | Weights, defaults, refusal behaviour, formatting | Replay a fixed task set on every published model change | On announcement, plus weekly. |
| Input distribution | The questions your users actually ask | Topic mix and input embedding distance from baseline | Daily. |
| Retrieval corpus | The documents the agent reads before answering | Index freshness and chunk hit distribution | Daily. |
| Prompt and tool sprawl | Your own instructions, tool list and routing rules | Diff on prompt versions, tool call mix per run | On every deploy. |
The fourth row is the one teams resist, because it is self-inflicted. It is also the cheapest to instrument, since the change is already in your version control system.
The behaviour change is measured, not theoretical
The strongest public evidence is now three years old, which says something about how little of this gets published. It is still the cleanest study of the effect.
Lingjiao Chen, Matei Zaharia and James Zou evaluated the March 2023 and June 2023 versions of GPT-3.5 and GPT-4 across eight tasks. The work was published in Harvard Data Science Review in March 2024, and the preprint is arXiv 2307.09009.
On identifying prime versus composite numbers, GPT-4 went from 84.0% to 51.1% while GPT-3.5 went from 49.6% to 76.2%. On counting happy numbers, GPT-4 fell from 83.6% to 35.2%. On code generation, the share of directly executable output dropped from 52% to 10%, while multi-hop question performance rose from 1.2% to 37.8%.
Why the aggregate score hid it
Read that list again. Two tasks collapsed, one improved sharply, and one model moved in the opposite direction to the other on identical questions.
A single blended quality score across those tasks would have looked roughly flat. This is the practical lesson and most teams get it backwards: drift shows up per task, not in the average. If you monitor one number, you have built an instrument that is designed not to see this.
Your own prompts and context drift too
Blaming the provider is comfortable and usually incomplete. Two of the four drift sources sit entirely inside your deployment, and one of them gets worse every time your product succeeds.
Retrieval-augmented systems grow. More documents land in the index, the corpus gets noisier, and prompts get longer to carry more context. Teams treat that growth as neutral because the context window is large enough to hold it. It is not neutral.
Longer context is not free
Chroma's context rot study, published in July 2025 by Kelly Hong, Anton Troynikov and Jeff Huber, ran six experiments across 18 frontier models from Anthropic, OpenAI, Google and Alibaba. Every model tested performed worse as input length grew, and performance depended on how the relevant content sat inside the surrounding text rather than on length alone.
One result deserves a place on your wall. Models scored better on shuffled document collections than on logically ordered ones, consistently across all 18. That is the opposite of what most retrieval pipelines are tuned to produce.
The operational point is narrow and useful. If your corpus doubled since launch and your prompt grew with it, you changed the system as surely as the provider would have. Nobody logged it as a change, because adding documents feels like content work rather than a deploy.
The retirement clock nobody put on the roadmap
The most predictable source of drift is also the one teams plan for least. Models retire on a published schedule, and the schedule is not yours.
I counted every entry in Anthropic's published deprecation table on 23 August 2026. Nine model identifiers reached their retirement date in the preceding 12 months. Two more, Claude Sonnet 4.5 and Claude Haiku 4.5, carry tentative retirement dates inside the next eight weeks.
Sixty days against six months
Notice periods differ sharply between providers, and the difference is written down. Anthropic commits to at least 60 days of notice for publicly released models. OpenAI's published policy is at least 6 months for generally available models, and at least 3 months for specialised variants such as Codex and chat-latest. Anything carrying "preview" in its name can go with as little as 2 weeks.
The recent Claude retirements sit almost exactly on the floor. Opus 4.1 got 61 days, Sonnet 4 and Opus 4 got 62, Haiku 3 got 60. Two months is not long enough to run a real evaluation, negotiate a change window and retrain a support team. That is why the differences between provider terms deserve a line in your vendor comparison rather than a footnote.
| Retirement date | Models retired | Days from notice to retirement |
|---|---|---|
| 28 October 2025 | Claude Sonnet 3.5, both snapshots | 76. |
| 5 January 2026 | Claude Opus 3 | 189. |
| 19 February 2026 | Claude Sonnet 3.7, Claude Haiku 3.5 | 114 and 62. |
| 20 April 2026 | Claude Haiku 3 | 60. |
| 15 June 2026 | Claude Sonnet 4, Claude Opus 4 | 62. |
| 5 August 2026 | Claude Opus 4.1 | 61. |
Counted from Anthropic's own deprecation history on 23 August 2026. Day counts run from the announcement date the company publishes for each retirement. Partner platforms such as Amazon Bedrock and Google Cloud set their own dates, so a workload running there sees a different clock.
The gateway may not serve the model you asked for
There is a second layer of uncertainty that almost nobody instruments. Many teams reach models through a third-party gateway or aggregator rather than the vendor API, usually for routing, cost or a single billing relationship.
A measurement study presented at the 2026 ACM Internet Measurement Conference audited that layer directly. GateScope, by researchers at the University of Massachusetts Boston and Arizona State University, tested 10 commercial gateways against 24 models, with 15,840 baseline records drawn from the official APIs.
Self-identification rates for gpt-4o ranged from 46.91% to 98.18% across gateways. One platform returned the correct identification for gpt-5 only 13.09% of the time. Self-identification is an indirect signal rather than proof of substitution, and the authors are careful about that, but a spread that wide across a single model name is not noise.
The billing gap nobody reconciles
The same study found billing deviations against measured token usage, including a gap of 62.8% at one gateway and 7.6% at another. Latency stability varied too, with a coefficient of variation between 0.25 and 1.10 against a baseline of 0.63.
Treat this as one more reason your invoice and your usage logs should be reconciled monthly by someone who is allowed to escalate. It is the same discipline as working out why cheaper tokens have not produced smaller bills, applied to a layer most finance teams do not know exists.
What to monitor, at what cadence, and who gets paged
Most drift advice arrives as a platform recommendation. Start somewhere cheaper, because the first version of this needs no procurement.
Build a golden set. Take 50 to 200 real requests that represent the work your agent actually does, write down the correct outcome for each, and store them in your repository next to the code. Replay them nightly and on every model or prompt change. Score them the same way each time.
That is the whole minimum viable version, and it catches the failure mode that matters most, which is a task that used to work and now does not. Note that the Chen study needed exactly this shape of instrument to find what it found.
Thresholds, cadence and who gets paged
A signal without a threshold is a dashboard nobody opens. Decide in advance what counts as a regression, and write it down before you look at the data, because a threshold set after the fact is a story rather than a rule.
Set a per-task pass rate floor, not a global one. Route a breach to the team that owns the workflow rather than to platform on-call, because the first question is always whether the change is acceptable, and only the workflow owner can answer that. Keep the escalation path the same one you use for incidents where an agent commits you to something.
| Signal | What it catches | Cost to build | What it misses |
|---|---|---|---|
| Golden-set replay | Behaviour change on tasks you already care about | An afternoon, then a nightly job | Anything outside the set. |
| Output distribution and refusal rate | Silent shifts in tone, format and willingness to answer | Days, and it needs a clean baseline window | Slow decay that stays inside the band. |
| Tool-call and step-count mix | Agents taking new paths or looping longer than before | Days, and it needs traced runs end to end | Wrong answers reached by the usual route. |
| Downstream business signal | Everything, eventually | Nothing, you already have it | Speed. This is the customer telling you. |
The last row is the one every team already relies on, and it is genuinely the most complete signal available. It is also the slowest and the most expensive, because the detection event is a complaint.
None of this is exotic. It is the same evaluation discipline that separates agent pilots reaching production from the ones that stall. Why they stall is covered in the six failure modes behind stalled agent deployments. If your orchestration layer already traces every step, most of the raw material exists, which is worth checking before buying anything, since what these tools actually orchestrate varies a great deal.
Where this argument is weakest
Four things in this post are softer than the confident version of the argument would like.
The best measurement of provider drift is from 2023. Chen, Zaharia and Zou studied two models across four months, three years ago, and nothing of comparable rigour has been published since on current frontier models. Providers have also improved pinning and notice practices since then. Anyone citing that study as proof of what is happening this quarter, including this post, is extrapolating.
The gateway study measures self-identification, not substitution. A model that misidentifies itself may simply have a system prompt that says so. The spread is a strong prompt to go and check your own gateway, and it is not a finding that any specific provider swapped a model.
The strongest case against building this is cost. Continuous evaluation is real engineering, it produces alerts, and alerts consume attention that a small team does not have. If your agent handles low-stakes internal work, a quarterly manual check of 30 outputs may be the right amount of monitoring. Building a pipeline instead is a way of feeling responsible rather than being useful.
The compliance deadline moved, and that cuts both ways
Article 72 of the EU AI Act requires providers of high-risk systems to run a documented post-market monitoring system. It must actively collect and analyse performance data across the system's lifetime. The Act required the Commission to adopt a template for that plan by 2 February 2026.
Then the Digital Omnibus on AI, in force from 27 July 2026, deferred the stand-alone Annex III high-risk obligations to 2 December 2027, and the Annex I product-embedded obligations to 2 August 2028. So the regulatory forcing function most vendors quoted at you this year is 15 months further away than the deck said. The rest of the transparency timetable is set out in the EU AI Act transparency checklist.
My own position, stated plainly: build the golden set anyway. The regulation was never the reason, and a delay in Brussels does not make your retrieval corpus smaller or your provider's retirement calendar slower.
Frequently asked questions
What is model drift in LLMs?
Model drift in LLM systems is a change in output behaviour over time that nobody deliberately shipped. It has four common sources: the provider updating or retiring the model, the distribution of user inputs shifting, the retrieval corpus growing or changing, and your own prompts and tool definitions accumulating edits. Unlike a crash, drift produces plausible output, so standard application monitoring does not catch it.
How do you detect AI degradation in production?
Start with a golden set of 50 to 200 real requests with known correct outcomes, stored in version control and replayed nightly and on every model or prompt change. Score each task separately rather than blending into one quality number, because drift shows up per task and cancels out in an average. Add output distribution, refusal rate and tool-call mix once the golden set is running.
Does GPT-4 actually get worse over time?
It changed in both directions. Chen, Zaharia and Zou found GPT-4 accuracy on prime identification fell from 84.0% in March 2023 to 51.1% in June 2023, and directly executable code dropped from 52% to 10%. On multi-hop questions it improved from 1.2% to 37.8%. GPT-3.5 rose from 49.6% to 76.2% on the same prime task. Drift means dispersion, not guaranteed decline.
How much notice do model providers give before retiring a model?
It varies by provider and is published. Anthropic commits to at least 60 days of notice for publicly released models, and recent Claude retirements landed within a day or two of that floor. OpenAI's stated policy is at least 6 months for generally available models, at least 3 months for specialised variants such as Codex, and as little as 2 weeks for preview models. Partner clouds set separate schedules.
What is LLM observability and how is it different from APM?
Application performance monitoring answers whether the call succeeded, how long it took and what it cost. LLM observability adds whether the answer was any good, which is not derivable from a status code. In practice it means tracing every step of a run, storing inputs and outputs, scoring them against a fixed task set, and alerting on a per-task pass rate rather than on latency and errors alone.
How many companies monitor their AI systems in production?
Grafana Labs surveyed more than 1,300 observability practitioners and leaders across 76 countries between October 2025 and January 2026. Of those, 14% used observability for LLM production workloads and 29% said it was not on their radar. A year earlier the same figures were 5% and 42%. Production monitoring nearly tripled in a year and still covers roughly one team in seven.
Where to start this week
Two tasks, both finishable before Friday, neither requiring a budget line.
First, write down which model identifier every production system is calling, and check it against the provider's published retirement date. If any workload calls a rolling alias rather than a pinned version, that system accepts silent updates by default, and somebody should have decided that on purpose.
Second, collect 50 real requests from last week's logs and record the correct outcome for each. That file is your baseline. It is worth more than any dashboard you could buy this quarter, and the reason is unglamorous: on the day behaviour changes, it is the only artefact that can prove it.
If you take one thing
Score your evaluation set per task, never as one blended number. An average is the instrument least likely to detect the thing you built it for, which is the same lesson buried in why agent pilots stall before production.
References
- Chen, Zaharia and Zou, How Is ChatGPT's Behavior Changing over Time?, Harvard Data Science Review 6.2, 12 March 2024. Preprint at arXiv 2307.09009. Used for every March-to-June 2023 accuracy figure. Peer reviewed, and now three years old.
- Grafana Labs, 2026 Observability Survey. More than 1,300 observability practitioners and leaders across 76 countries, fielded October 2025 to January 2026. Used for the 14%, 29%, 5% and 42% adoption figures. Self-selected respondent pool, skewed toward observability users.
- Anthropic, Model deprecations, read 23 August 2026. Used for the retirement count, every date in the retirement table and the 60-day notice floor. The nine-retirement count is my own tally from that table.
- OpenAI, Deprecations, read 23 August 2026. Used for the 6-month, 3-month and 2-week notice periods.
- Lin, Wan, Pei, Xu, Xu and Xue, Behavioral Consistency and Transparency Analysis on Large Language Model API Gateways, Proceedings of ACM IMC 2026, arXiv 2604.21083, 22 April 2026. Used for the gateway identification rates, billing gaps and latency variation.
- Hong, Troynikov and Huber, Context Rot: How Increasing Input Tokens Impacts LLM Performance, Chroma, 14 July 2025. Used for the 18-model result and the shuffled-haystack finding. Vendor-published research, not independently peer reviewed.
- Chishti, Oyinloye and Li, Test Before You Deploy: Governing Updates in the LLM Supply Chain, arXiv 2604.27789, 30 April 2026. Used for the finding that targeted risk-area testing surfaces regressions that aggregate metrics miss.
- EU Artificial Intelligence Act, Article 72, post-market monitoring by providers, with deferral dates from the Digital Omnibus on AI as summarised by Gibson Dunn, 27 May 2026. Used for the monitoring obligation and the 2 December 2027 date.
The weakest thing about this source base: the only rigorous measurement of provider-side behaviour change studied two models over four months in 2023, and no equivalent study of current frontier models has been published. Everything more recent here measures the surrounding infrastructure rather than the models themselves.
Related reading