The Three Drifts
Software crashes loudly. Agents fail silently.
An agent keeps running. No errors, no alerts, no latency spike. Its recommendations slowly stop matching the rules they are supposed to follow, because the model provider updated the weights underneath it, or because a policy changed and nobody refreshed the knowledge base.
Three weeks later the rejection rate is the thing that finally moves, and by then the exposure is the whole three weeks.
Traditional monitoring answers is it up. Agents need a monitor that answers is it still right, and those are different questions with different instruments.
Two of the three are caught by the test you already run. The third is the reason that test is not enough.
| Drift | What changed | Why it happens | What catches it |
|---|---|---|---|
| Model drift | The model's behaviour, with no change to your code | The provider updated the weights, the version, or the defaults. Your prompt now lands differently | A fixed set of golden scenarios re-run on a schedule, scored the same way every time |
| Data drift | The world the agent reads | Schemas shifted, an upstream API changed shape, user behaviour moved, the knowledge base went stale under a policy change | Accuracy on the golden dataset falling while the code is unchanged, and freshness checks on every grounding source |
| Behavioural drift | What the agent chooses to do, in aggregate | Nothing single broke. Each decision still looks defensible in isolation, and the distribution of decisions has moved | Rate and distribution monitoring on the agent's own actions, against its own baseline |
The third one is the hard one, and it is the reason the other two are not enough. Model drift and data drift both show up as accuracy falling on a fixed test. Behavioural drift can leave accuracy intact and still be the incident, because the agent is answering a slightly different question than it was answering last month.
The tell for behavioural drift is a rate, not an error. An action that ran two or three times a day starts running forty times an hour. Nothing throws. Every individual call, read on its own, is a call the agent was built to make.
The instrument that makes the three drifts operational is a fixed daily ritual, not a dashboard someone might open.
Synthetic tests first. A golden set of scenarios with known correct outcomes, run automatically before anyone is at a desk. This is the model drift check, and it is the one that has to be machine-run, because it is the one nobody will do by hand every day.
Drift checks second. Three questions, in this order:
| The question | Green looks like | |
|---|---|---|
| Model | Did the golden set score the same as yesterday? | No movement outside the noise band |
| Data | Is every grounding source as fresh as it should be, and is the input distribution the one we tested on? | Nothing stale, nothing new in the shape of the inputs |
| Behaviour | Are the agent's action rates inside their own baseline? | No action type outside its band |
Human review last, and only on what the first two surfaced. Three green lights and the day proceeds. One red light and it becomes a playbook rather than a conversation.
The whole check is minutes, and that is a design requirement rather than a boast. A drift check that takes an hour is a drift check that gets skipped on the day it would have mattered.
The clock is not the framework. What matters is that it runs before the working day, every day, and that the sequence is tests, then drift, then humans.
The three drifts are what to look for. This is where to look. The four layers come from the Playbook's monitoring model, restated so they are not specific to one vertical.
| Layer | The question it answers | What is on it |
|---|---|---|
| Infrastructure | Is it alive? | Uptime, latency per transaction, API error rates, cost per transaction |
| Cognition | Is it thinking correctly? | Hallucination rate on a sampled review, golden dataset accuracy on a schedule, the distribution of confidence scores |
| Business | Is it producing value? | Acceptance rate by counterparty, the trend on the outcome the agent exists to move, handling time against baseline, user escalation rate |
| Compliance | Is it staying safe? | Sensitive-data exposure incidents, prompt injection attempts detected, audit trail completeness, the date the risk charter is next reviewed |
Most agent monitoring stops at the first layer, because the first layer is the one the existing observability stack already produces. An agent that is up, fast and cheap, and wrong, passes every check on that layer.
The fourth layer is the one with a date on it. A risk charter with a review date in the past is a compliance finding that a dashboard will never raise on its own.
Drift checks catch movement. A scorecard says whether the level itself is acceptable. Six measures, and each one needs a threshold set locally rather than inherited.
| Measure | What it tells you | What a bad number usually means |
|---|---|---|
| Task success rate | Is it doing the job | The obvious one, and the one most likely to be measured against a test set that no longer represents the work |
| Escalation rate | How much human time it is actually consuming | Falling can mean improvement, or can mean the escalation triggers stopped firing. Read it with the success rate or not at all |
| Token efficiency | Cost per resolved unit of work | Rising with flat volume is usually retry loops or duplicated retrieval, not usage growth |
| Safety | Blocked actions, injection attempts, and attempts at the outcomes policy says the agent must never be allowed to execute | Zero is a reason to check the instrument, not a reason to relax |
| Human-in-the-loop accuracy | Whether the reviewers are catching what they are there to catch | Approval rates near 100 percent are the rubber-stamp signal |
| Employee sentiment | Whether the people working alongside it trust it | The measure that predicts adoption, and the only one on this list that a technical dashboard will never produce |
The source states starting thresholds for four of these. They are stated here as shapes rather than numbers, because a threshold copied from another organisation's volume and risk profile is a number with no authority behind it. Set them locally, write them down before the agent runs, and treat a change to a threshold as a change to the governance rather than a tuning exercise.
Human-in-the-loop accuracy is the one that gets skipped. It is the measure of the control, rather than of the agent, and a control that has never been measured is an assumption wearing a process.
A drift alert with no playbook behind it becomes an alert people learn to close.
Confirm it is not transient. Re-run the golden set offline before anyone is woken. A single scored run can move for reasons that are not drift.
Name the drift before naming the fix. Model, data, or behaviour. The three have different repairs, and the most expensive mistake is patching a prompt when an upstream source changed shape.
Reach for the reversible control first. Degrade the agent rather than debating it: back to draft mode, back to read-only, scope blocked, or spend capped. Automatic degradation on a threshold breach is worth building precisely because it does not require anyone to be awake.
The fix becomes a test. Every confirmed drift incident ends by adding the scenario that would have caught it to the golden set. A golden set that never grows is a golden set that is slowly falling behind the work.
A remediation agent on an on-call operations team spent six months doing routine triage well, including restarting servers when that was the right call.
Then its action rate went outside the band: a restart action that ran two or three times a day ran dozens of times in a single hour, overnight.
The cause was model drift after a provider update. The agent had become more aggressive in how it read high CPU, and it was now restarting machines that were supposed to be running hot, because a scheduled batch job was running on them.
Nothing errored. Accuracy on the historical test set was fine. What caught it was a rate monitor on the agent's own actions, which is the behavioural drift check and nothing else. The repair was a prompt that distinguished expected load from anomalous load, and a new golden scenario so the same drift can only happen once.
Once an organisation is running many agents rather than one, the three drifts still hold per agent, and two more dimensions become worth watching across the fleet:
Goal drift. What the agents are collectively optimising for has moved away from what the programme was chartered to do.
Collaboration drift. The handoffs between agents degrade even though each agent is individually healthy. This is the multi-agent version of behavioural drift and it is invisible from inside any single agent.
Three per agent, five across the fleet. Keep the three as the daily ritual: it is the version that survives being done every morning, and a check nobody performs catches nothing.
From the practice canon. Developed through client delivery and refined in collaboration; the frameworks stated here are the author's own.