Drift is the silent killer.

In traditional operations, the failures you fear most are the ones that page at 3am. In AI fleets, the failures that should scare you are the ones that never page at all. An agent that throws an exception gets fixed within the hour. An agent whose accuracy slides half a point a week gets "fixed" when a customer escalates — three months later, after hundreds of degraded interactions.

Drift isn't really a model problem. It's an everything problem: someone edits a prompt, upstream data shifts, user behavior changes, a dependency updates its API. Any of these quietly moves the ground under your agent's feet. The agent keeps answering with exactly the same confidence. The answers just get worse — in accuracy, in tone, in instruction-following.

Baselines, not vibes

You can't detect drift without a reference point. Rolling baselines — a trailing 7-day window on accuracy, tone scores, task completion — give you one that moves with the fleet instead of going stale. Tolerance bands, say ±2σ around the baseline, turn "this feels off" into "this is measurably off." Without them, every conversation about quality is an argument about vibes, and vibes lose to shipping pressure every time.

The metrics worth baselining are the ones closest to customer impact: task success rate, answer accuracy against a held-out eval set, tone scores on outbound messages, and escalation rate — the fraction of interactions the agent itself flags as uncertain. Baseline the outputs, not just the internals. Infrastructure metrics tell you whether the fleet is running; they tell you nothing about whether the answers got worse.

Alert on the slope, not just the line

Static thresholds fail because fleets are seasonal and prompts change; a threshold set at launch is fiction by month two. What matters is the first derivative: is the metric getting worse, and is it getting worse faster? A slope alert fires while there's still time to intervene. A threshold alert fires after the damage is already visible to customers. Here's what a drift policy looks like when it's written down instead of hoped for:

Note the structure: a baseline, bands, a slope condition with a duration — three days, not three minutes. Drift is a slow signal, and alerting on noise is how you train people to ignore alerts. The policy names a defined action for when the math says the agent is broken, so nobody has to improvise one at midnight.

Slope alerting has a failure mode of its own: legitimate change. A prompt rewrite, a new product launch, a seasonal spike — all of these move the baseline on purpose. That's why baselines must reset on declared change, and why the policy above uses a three-day window instead of firing on the first bad hour. The goal is a signal the team trusts enough to act on at 3am, which means it has to stay quiet when things are fine.

Quarantine is the last resort, not the first

Auto-quarantine exists for exactly one reason: an agent that's provably broken should stop touching customers before a human reviews it. The bar should be high, the action reversible, and the record complete — because every quarantine is also a learning event. Quarantine too eagerly and you've built an outage machine; quarantine too late and the drift already did its damage. The band between those two is where all the real tuning lives. Picture the failure it exists to prevent: a support agent whose tone has drifted hostile over six weeks, still answering with full confidence, still passing every static threshold because the thresholds were set back when it was polite. Not the dramatic outage — the slow rot. That's what quarantine is for.

All of this runs out-of-band. Drift detection never touches the execution path — it reads the telemetry the fleet emits and compares it against history. When the slope turns, the command center sees it first, and a human decides what happens next. That's the whole game: catch the slow failure with the same seriousness as the loud one.

← Back to all posts