What context drift is
You ask the agent to fix a failing test. It opens the test, opens the file under test, notices an unrelated lint warning, fixes that, reformats the file, spots a second file with the same pattern, starts refactoring that one - and twenty turns later it is deep in a cleanup you never asked for and the original test is still red. Every individual step looked reasonable. The trajectory left the goal behind.
The mechanism is the context window. The instruction you gave sits at the top, and every tool result, error, and file dump piles on top of it. The model attends most to what is recent, so with each turn the original goal carries a little less weight and the latest shiny distraction carries a little more. Drift is not a mistake the model makes once; it is a slow gradient it slides down when nothing holds the goal in place.
How to detect drift
Drift is invisible turn-to-turn and obvious across the run. The signals:
- The working set widens. The agent is touching files that have no path to the thing it was asked to do.
- The goal stops being referenced.The original instruction hasn't been mentioned or acted on in many turns.
- New sub-goals appear.The agent starts announcing work - “while I'm here I'll also…” - that you never scoped.
- The finish condition recedes. The test that defined done is still failing while unrelated work accumulates.
How to pull it back at the hook layer
The fix is to keep the goal alive outside the run and enforce it at the harness hook layer. failproof holds the original objective where the context window can't bury it, and as the agent acts it checks the direction of travel against that objective. When the actions stop serving the goal, the policy pulls the agent back: it injects a concise reminder of what the task actually was, re-anchoring the next turn - or, if the drift is severe, it pauses and surfaces the divergence to you before more effort is spent off-track.
Because the check runs at the hook and not in the prompt, it doesn't rely on the model remembering to stay disciplined - the exact thing drift erodes. It is the same hook-level enforcement that catches the other failure modes, applied to trajectory instead of a single bad call, and it behaves the same across Claude Code, Cursor, Codex, and opencode.
Concretely, the policy holds the goal outside the run and re-asserts it at the PreToolUse hook as the turn count climbs:
// goal-guard.js — re-assert the original goal on long runs
import { customPolicies, allow } from "failproofai";
const GOAL = "fix the failing test in auth.test.js"; // what this run started with
let turns = 0;
customPolicies.add({
name: "goal-guard",
description: "Nudge the agent back to the goal as the run grows",
match: { events: ["PreToolUse"] },
fn: async () => {
if (++turns % 15 === 0) {
return allow("Still on task? The goal is: " + GOAL);
}
return allow();
},
});Install it with failproofai policies --install --custom ./goal-guard.js, or run failproofai policies --install to enable the built-in drift guard that pulls the agent back automatically.
Watch the trajectory, tune the anchor
Drift is easiest to understand by watching it happen. Session replay in agenteye lets you walk a run span by span and see the exact turn the agent left the goal - the tangent that pulled it away. That tells you where to set the anchor and how tight to make it, so the policy re-asserts the goal at the right moment on the next run instead of too early or too late. Find the turn in the trace, fix the anchor in the policy.
Get started
failproof is free, open-source, and runs on your machine. Install the CLI, enable the built-in policies, and the drift check is live at the hook layer.