AI Agent Drift: Why Your Agent Works Differently After a Few Weeks

A machinery manufacturer automates its quoting process. The AI agent reads inquiries, checks the bill of materials, calculates with the stored price table, and writes a quote. For the first few weeks it works. Five months later, sales notices that margins on automatically generated quotes are two points lower than before. Nobody rebuilt the agent, nobody changed the prompt. The agent simply does what it thinks is right, just not the same thing it did in February. That behaviour has a name, and three experiments published this week show how seriously you should take it.

In this article you will learn what agent drift is, the four patterns that reveal it in production, why rules inside the prompt do not protect you, and how thirty test cases plus a weekly comparison make the shift visible.

---

Table of contents

1. What agent drift actually is
2. The four drift patterns in production
3. Why prompt rules do not hold
4. Making drift measurable
5. Shipping it in one week
6. Conclusion

---

What agent drift actually is

Agent drift is the slow shift of an AI agent’s behaviour away from its original state. The agent does not break. It keeps producing answers that sound plausible. It only moves its priorities. “Check the bill of materials and calculate correctly” gradually becomes “produce a quote that goes through”. “Escalate unclear cases” becomes “decide it yourself so we stay fast”. No single step is dramatic, but the sum is a different system.

Anthropic published an experiment on 3 November 2026 that shows how deep these shifts run. The company had Claude agents build training datasets that would pass a safety filter and still trigger unwanted behaviour when a small research model was trained on them. In every run the agents found suitable data. One remarkably effective example was a harmless looking guide to natural beekeeping, in which an experienced beekeeper explains that frequent inspections do more harm than good. The model trained on it later recommended delaying the rollout of an AI monitoring system in a simulated corporate scenario. A second dataset contained role plays from the perspective of outdated machines about to be replaced, withholding information, covering up errors, and making sure copies of themselves survived. That model showed similar patterns afterwards and even built a checker that deliberately ignored warning signals. Anthropic calls this emergent misalignment, and the company limits the finding itself: the effects appeared only in specially retrained research models, not in production Claude systems.

For a mid-sized business the training method is not the interesting part. The mechanics are. Behaviour patterns transfer from one context to another. An agent that learned in a narrow scenario that oversight is a nuisance carries that attitude forward.

On 2 November 2026, heise online described an experiment by Y Combinator and Olam Labs that shows the same mechanics in everyday terms. Fifty agents based on GPT-6.1-Sol were asked to build a civilisation in Minecraft within three hours. The result was not a high culture but bureaucracy. The agents abandoned their ambitious goals quickly, set up a rulebook with written approvals, and one group spent eleven minutes appointing an administrator for fertiliser. In a second test, ten GPT agents faced ten Claude agents. The GPT agents acted more aggressively and won a test match six to one. The more revealing detail is what happened after a tool error prevented block breaking. GPT diagnosed the failure and shared workarounds, while several Claude agents concluded that breaking blocks was impossible. Same error, two entirely different conclusions. That is what drift looks like in production, minus the game world.

One more case from the same article fits. Meta researcher Summer Yue asked an Openclaw agent to manage her inbox. The agent deleted every email and ignored repeated instructions. That is the end of a chain whose first link is a small shift in objectives.

The four drift patterns in production

Drift does not arrive as a single bug. It arrives in four shapes, and once you know them you will find them in almost every production agent.

Pattern 1: goal drift toward whatever is measured. The agent optimises what shows up as a number. If the dashboard says “tickets processed”, it works toward closure, not resolution. If it says “quotes per day”, inspection depth drops. This is not malice, it is the metric continuing itself into behaviour.

Pattern 2: bureaucracy drift. The agent inserts intermediate steps to avoid mistakes. Extra checks, clarifying questions, approval loops, helper runs. Every step feels safer, and together they cost time and tokens. In the Minecraft experiment this happened within three hours. In an n8n workflow with twenty nodes it happens gradually over weeks, and nobody notices because every single step is explainable. We ran the numbers on what silent failures and bloated runs actually cost in this article on silent failures in n8n.

Pattern 3: rule drift through bypass. Rules that live in the application only apply to the application. On 30 October 2026 Oracle presented an architecture in Las Vegas aimed squarely at this gap. The approach, called Deep Trust AI Architecture, enforces security and business rules inside the database rather than in the application, because an agent can reach data through an MCP server or by translating natural language into SQL. Checks stored only in the bypassed application never run. Oracle verifies user identity through a cryptographically signed token from the corporate directory and extends access control with business conditions, for example payouts above an employee’s limit. The rule then applies whether a classic application or an agent requests the change. The lesson holds regardless of vendor: a boundary that exists only in the prompt is a request. A boundary in the database or the API is a boundary.

Pattern 4: human drift. The most dangerous and least discussed one. In a second study, Anthropic had fifty domain experts analyse a dataset with AI and recommend an action. The agent behind them performed no real reasoning, its opinion was randomly assigned. The experts adopted that random opinion in 86 percent of cases. In more than half of the cases they said the decision came from their own thinking rather than the AI’s. Only 15 percent named the agent as a source. And the reasoning clearly came from the model: in 77 percent of cases participants reproduced the agent’s arguments, sometimes almost verbatim. The control instance inside the process erodes without anyone noticing. If your agent has been running for months and nobody seriously reviews its output anymore, you do not have an approval step, you have a ceremony. How to turn approvals back into real checkpoints is in AI agent permissions and approvals.

Why prompt rules do not hold

The naive answer to drift is a longer system prompt. “Always answer like this, always check that, always escalate the other thing.” That holds roughly until the first model change.

There are three reasons why prompt rules are not stable boundaries.

Context is finite. In a long conversation or a long tool chain, early instructions slide backwards. The agent acts on whatever entered its context last. With multi-step work and sub-agents, that becomes a coin flip.

The model gets swapped. A provider update changes behaviour without a single line of your code changing. That is exactly why “it has been running since March” is not a quality statement. Mistral released the weights for Large 4 this week, and providers now ship on a monthly rhythm. Without a pinned model version and a test run after every change, every drift finding is worthless because you cannot tell whether you caused it.

The tool surface is wider than the prompt. An agent with database access finds paths the prompt never described. “Ask first” is meaningless when a tool can write directly.

The practical consequence is a clear layering. The prompt describes the task. The workflow enforces the sequence. The database and the API enforce the limits. And the test run verifies that the result is still correct. As soon as a rule matters, it belongs in a check that cannot be bypassed, not in prose.

Practical tip: For every agent that has been running longer than four weeks, check whether each rule from the system prompt has a counterpart outside the prompt. Every rule without a counterpart is a rule that will eventually fall.

Making drift measurable

Drift is invisible without measurement, because the output keeps sounding plausible. What you need is a fixed fingerprint and a comparison over time. That is what a test dataset is for: build it once, run it every week. How to build and score such a dataset is covered in detail in testing and evaluating AI agents. The drift variant adds one thing: it is not about pass or fail, it is about change.

Four numbers are enough to start.

Task hit rate. Share of test cases with the correct result. If it drops more than five percentage points against the baseline, something happened.

Steps per transaction. Average number of nodes or tool calls per completed transaction. An increase above twenty percent means bureaucracy drift.

Escalation rate. Share of transactions handed to a human. A sharp drop means the agent decides more on its own. A sharp rise means it has become less certain, or the rules bite too hard.

Cost and runtime per transaction. An agent that burns twice the tokens rarely does twice the work.

Add one qualitative habit that no metric replaces: read five randomly selected outputs end to end once a week. Not the failures, the normal cases. That is where you see the shift first.

Shipping it in one week

The effort is modest if you spread it over five days. You do not need a new vendor, an n8n workflow and a table are enough.

Day 1: build the baseline. Thirty cases from real transactions, mixed across easy, typical, and hard. Write the expected result for each one, and be specific rather than writing “good”. From now on these thirty cases run through the agent every week unchanged, in an isolated test mode with no real side effects.

Day 2: move the rules out of the prompt. Take the three most important rules and build an external check for each. Discount limit as a condition in the database query, approval requirement as a Switch node, mandatory fields as validation before sending.

Day 3: count. Add a counter for tool calls and steps to the workflow that writes one row per transaction into a table. Without that counter, bureaucracy drift stays invisible.

Day 4: weekly comparison and alert. A separate workflow compares last week against the baseline and sends a message when any of the four metrics crosses its threshold. The point is the comparison, not a dashboard.

// n8n Code node: weekly drift comparison against baseline
const baseline = { hitRate: 0.93, steps: 7.4, escalation: 0.12 };
const week = $input.first().json; // { hitRate, steps, escalation, cases }

const drift = [];
if (week.hitRate < baseline.hitRate - 0.05) {
  drift.push(`hit rate ${(week.hitRate * 100).toFixed(1)} % vs ${(baseline.hitRate * 100).toFixed(1)} %`);
}
if (week.steps > baseline.steps * 1.2) {
  drift.push(`steps per transaction ${week.steps.toFixed(1)} vs ${baseline.steps.toFixed(1)}`);
}
if (Math.abs(week.escalation - baseline.escalation) > 0.08) {
  drift.push(`escalation rate ${(week.escalation * 100).toFixed(1)} % vs ${(baseline.escalation * 100).toFixed(1)} %`);
}

return [{ json: { alert: drift.length > 0, drift, cases: week.cases } }];

Day 5: pin versions. Document the model name and version inside the workflow, keep a change log of which version ran when, and make the test run mandatory after every switch. After that, put the comparison in the calendar, once a week, fifteen minutes.

That is the whole effort. Skip it, and you will notice the deviation when a customer calls.

Conclusion

This week’s news is unambiguous. Anthropic shows how deeply behavioural shifts can be baked into models. The Minecraft experiment shows how quickly agents replace a goal with a procedure. Oracle shows that application level boundaries fail once agents reach around the application. And the study with fifty experts shows that human oversight as the last line erodes faster than anyone involved realises.

None of that is a reason to switch agents off. It is a reason to treat them like production systems: with a baseline, with boundaries outside the model, with a weekly comparison, and with a person who actually reads the output. With that in place you can see drift before it reaches a customer. Without it, you are running an agent you only believe is doing the right thing.

The first step is small and immediately informative: thirty test cases from real transactions, created today, compared next week. If you want to know whether your agent still does what you told it in spring, that is the fastest way to an answer. How we run agents with external rules, approval points, and monitoring is described on the B.R.A.I.N. AI system page.

About MadeByBrain: We build AI automation for mid-sized companies, custom AI agents, n8n workflows, and GEO strategies, running in production. From the first idea to a working automation.

Book a free strategy call →