A model that passes acceptance testing on the day it ships can produce different output three months later with no change on the customer's side. Lingjiao Chen, Matei Zaharia, and James Zou measured exactly this. Comparing the March 2023 and June 2023 releases of GPT-4, both served under the same model name, they found that accuracy at identifying whether a number was prime or composite fell from 84% to 51%, code-generation output picked up formatting that broke direct execution, and the model's adherence to instructions declined. Nobody on the receiving end touched the prompt, the data, or the integration. The provider changed the model under a stable name, and every system calling that name inherited the change. The authors drew the operational conclusion plainly: an organization relying on a hosted model needs continuous monitoring, not one-time validation.
This is the part of the work that begins the day an agent goes live and never ends. The build-time question of whether a workflow can be made reliable in the first place is covered in how production reliability gets engineered. What follows assumes that work is done and the agent is in production, posting to the ledger, sending the dunning email, clearing the match. The question now is how you know it still works tomorrow.
Two kinds of drift, two different detectors
The word "drift" gets used for two failures that share only the symptom. The first is input drift, in which the documents, requests, or transactions flowing into the agent change distribution. A vendor switches invoice templates, a new business line starts booking a transaction type the agent has never seen, or seasonal volume shifts the mix. The agent itself is unchanged. Its inputs moved. The formal treatment of this is old and well settled. Gama, Zliobaite, Bifet, Pechenizkiy, and Bouchachia, in their survey of concept drift adaptation, separate the kinds of distribution shift and the detection methods that catch each, and the durable lesson is that input drift is detectable from the inputs alone, before you ever see whether the output was right.
The second is model drift, in which the agent's inputs are stable but the function mapping them to outputs changed because the provider updated the model. This is the Chen, Zaharia, and Zou finding. It is invisible to any detector that only watches the input distribution, because the input distribution did not move. Catching it requires holding the input fixed and watching the output, which is a different instrument entirely. Conflating the two is the common mistake. A team builds an input-distribution monitor, ships it, and concludes it is covered for drift; then a silent model update degrades accuracy on inputs that look perfectly in-distribution, and the monitor stays green the whole time.
The held-out regression set
The instrument for model drift is a held-out regression set: a fixed collection of representative inputs with known-correct outputs, scored on every model change and every prompt change, with the score compared against the last run. When a provider ships a new model version, or when you change a prompt yourself, the set runs and produces a number. If prime-versus-composite classification is part of what your agent does and the score drops from 84% to 51%, you see it the day it happens rather than discovering it through a customer's reconciliation that no longer ties.
The discipline that makes this work is that the set is built from your task, not from the provider's benchmark. A model's published evaluation scores can rise on aggregate while the specific behavior your workflow depends on degrades, because the aggregate averages over thousands of tasks and yours is one of them. The regression set has to exercise the exact judgments the agent makes in production, scored the way you score them, or it measures the wrong thing with reassuring precision.
Compatibility as an explicit threshold
A regression score is only useful against a stated bound. The 2026 paper 'Test Before You Deploy: Governing Updates in the LLM Supply Chain' argues that organizations consuming hosted models should define explicit, measurable compatibility contracts rather than trusting a provider's benchmark numbers to certify that an update is safe for their use. In practice that means writing the threshold down in advance: this workflow requires at least a stated accuracy on the regression set, latency below a stated bound, and output that parses under the schema the downstream system expects. An update either clears the contract or it does not, and the decision to promote it is made against that number, not against a vendor's release notes describing a model as improved.
This connects directly to the controls that govern what an autonomous agent is permitted to do, covered in controls for autonomous actions. A compatibility contract is the upstream half of the same posture. The threshold gates whether the new model reaches production at all, and the action controls gate what it can do once there.
Logging, replay, and longitudinal evaluation
Two more pieces make the machinery operate continuously rather than at audit time. Every production output is logged with enough context to replay it: the input, the model version, the prompt, the result. Replay is what lets you re-run last month's real traffic against a candidate model and measure the delta on inputs you actually received, which is stronger evidence than a static regression set because it is your live distribution. Metrics are then scored on a schedule, and alerts fire when a metric crosses its bound, so a regression surfaces as a page rather than as a quarterly review finding.
Longitudinal evaluation of a single behavior over time is a worked discipline. Tamber and colleagues, in the Vectara hallucination work presented at EMNLP 2025, track model faithfulness on a fixed task across many models and over time, which is the same shape as a production regression set: one task, scored repeatedly, with the trend line as the artifact. The method that ranks models on a public leaderboard is what a deployed agent runs privately against its own task.
A reasonable counter
A reasonable counter is that this is overhead for a problem providers will eventually solve by versioning their models properly, at which point a pinned version gives you stability without continuous monitoring. There is something to this, and pinning a model version where the provider supports it is genuinely worth doing. But pinning addresses model drift only, and it rests on the provider both offering stable versions and honoring them; what Chen, Zaharia, and Zou documented was the service behind a single model name changing substantially within a few months, with when and how the updates happen opaque to the people calling it. It does nothing for input drift, which arrives from your own business regardless of what the provider does. The operator running an agent against month-end or the ticket queue is not choosing between monitoring and a clean provider guarantee. The choice is between catching a regression with an instrument built for it and learning about it from a customer, and only the first is compatible with an aligned engagement where the deliverable is a running agent that stays correct. The reliability curve tells you what is automatable now; the monitoring is what keeps it on the right side of that line after it ships.