What Drift Actually Looks Like

Three months after you deploy an agent, it starts doing subtly wrong things. Not catastrophically wrong — the kind of wrong that's easy to miss. It sends a follow-up email in a tone you've since moved away from. It files a ticket in a project that got renamed. It escalates an issue using a threshold you updated everywhere except the agent's instructions.

This is drift. Not a bug. Not a model failure. Just the slow divergence between how an agent was configured and how your business actually operates today.

Every agent drifts. The question is whether you're watching.

Why It Happens

Drift has three sources, and the first one is the most obvious: your processes change.

When you deployed your agent, it encoded your then-current understanding of how things should work. But companies aren't static. You renamed a project. You changed your support triage SLA. You decided to stop CCing a former team member. None of these changes made it back to the agent's instructions, because why would they? You updated your docs. You told your team. You just forgot the agent.

The second source is subtler: model updates. If your agent runs on an underlying model that gets updated — and they do — the same instructions can produce different outputs. A wording that reliably produced structured JSON last quarter might have more variability now. A tone that was "professional" six months ago might read slightly different from a model trained on more recent data. No single output is obviously wrong. The drift is statistical, not binary.

The third source is context decay. Agents don't just run on instructions — they run on context: the tools they can access, the data they can read, the memory they accumulate. APIs get deprecated. Data structures change. If an agent was optimized to work with a schema from six months ago, it isn't working with the schema you have now. It's working around it, quietly, in ways you haven't noticed yet.

All three sources are invisible until the accumulation matters.

The Signals You're Probably Missing

Most agent drift goes unnoticed for the same reason most process errors go unnoticed: you're busy, the outputs are mostly fine, and the cases that are wrong get silently corrected by whoever receives them without escalation.

Watch for these:

The tone feels off. You read an email your agent drafted and it doesn't sound like you. It's not wrong — it's just behind. Like reading a version of yourself from eight months ago. This is usually the earliest sign of style drift, and it's easy to dismiss as a one-off when it's actually systemic.

Edge cases are bunching up. When the number of cases flagged as "needs a human" starts climbing, that's rarely because your business is getting more complex. It's usually because your agent's instructions no longer cover the territory it's encountering. The world moved; the instructions didn't.

Outputs reference outdated context. The agent mentions a person who left, a tool you deprecated, a process you changed. When this happens more than once, stop treating it as a one-off. It's a symptom.

You stopped reading its work. This one is counterintuitive, but it's real. When agents run smoothly, humans stop spot-checking. The gap between when oversight drops and when drift actually matters is exactly where problems compound quietly.

Running a Recalibration Review

You can catch drift before it costs you anything. The process is not complicated; it just has to be deliberate.

Start with a sample audit. Pull the last 20–30 outputs from any agent you care about and read them in one sitting — not to evaluate individual outputs, but to look for pattern. Does the tone match where your brand is today? Are the decisions consistent with your current priorities? Are there recurring cases where the output needed to be overridden?

Then audit the instructions themselves. Read your agent's system prompt or configuration as if you were a new employee being onboarded. Does it describe how your company actually works right now? Pay specific attention to anything with a number (thresholds, timing, limits), anything with a name (person, project, tool), and anything conditional — "if X, do Y" — because both X and Y may have changed.

Finally, check the context. What data is the agent pulling? Is that data current? If the agent reads from a doc, a spreadsheet, or an API, when was that source last updated? Stale context is functionally the same as wrong instructions. The agent is confident and wrong, which is the worst combination.

This is a 90-minute exercise, maybe two hours if you're thorough. It's worth doing quarterly for any agent running at meaningful volume.

Making Agents More Drift-Resistant

You can't eliminate drift, but you can design for it.

Prefer principles over specifics where possible. "Match the tone of our most recent public communications" drifts less than "use a formal, professional tone" — because the standard is adaptive by design. If you must use specifics (thresholds, names, dates), group them together so they're easy to find and update in one pass.

Build in natural tripwires. Give agents instructions that reference datable things: "as of [month, year], the process is..." The instruction signals when it was written and prompts you to check it on review. It feels low-tech. It works. You'll notice a six-month-old timestamp much faster than you'll notice a vague policy statement that's been quietly wrong for six months.

Route edge cases explicitly and log them. Any case the agent marks as requiring human review is a diagnostic signal. A cluster of similar edge cases almost always means the instructions need a revision, not that the cases are genuinely exceptional. If you're not logging what gets escalated, you're discarding the most valuable feedback your agent produces.

Version your agent instructions. If you're changing a system prompt significantly, keep the old version. You'll thank yourself when outputs start looking off and you need to isolate whether it was the instruction change or something else. This is just version control for configuration — obvious in principle, skipped in practice more often than it should be.

Drift Is a Maintenance Problem, Not a Deployment Problem

Here's what most agent deployment guides miss: the work of deploying an agent is not finished when the agent goes live. That's version 1.0.

Software gets deprecated and replaced. Employees get managed, reviewed, and sometimes retrained. Agents need the same. The framing of "I'll build it and it'll run" is exactly the framing that produces agents nobody trusts after six months — not because the agents failed, but because nobody maintained the relationship between the agent's instructions and reality.

The better framing: treat your agent roster the way you'd treat a small team. Check in periodically. Update their context when the business changes. Review their work, not to micromanage, but to calibrate. Give them updated information when something significant shifts.

This doesn't require a lot of time. But it does require a calendar entry that actually gets honored. Most agent maintenance failures aren't technical. They're scheduling failures dressed up as technical ones.

The Compounding Return on Staying Current

When you get this right, you get something unusual: a workforce that gets slightly better over time instead of slightly worse. Every recalibration is compounding. Every updated instruction means future outputs are more accurate. Every caught drift is a class of errors that stops accumulating.

The agents founders trust after a year aren't the ones that were perfectly configured at launch. They're the ones that got maintained. The ones where someone cared enough to read the outputs, audit the instructions, and close the gap when it opened.

Ninety minutes a quarter. That's the actual cost. The cost of not doing it is invisible right up until it isn't.

Agent Drift: Why Your AI Workforce Needs Regular Recalibration