Key facts.
- MIT NANDA (2025): goal alignment in 15+ step tasks declines 22% per 5-step interval without verification checkpoints; held below 5% with checkpoints.
- Drift in long-running agents has three causes: context window compression (earlier instructions become lower-attention as context grows), plan-goal misalignment (agent optimizes the plan rather than the original goal), and external state change (the world changes during a long task, making the original plan obsolete).
- End-of-task verification tells you the goal wasn't achieved. It doesn't tell you where the drift started. Remediation is expensive: re-run from scratch instead of re-anchor from the drift point.
- Verification checkpoints: 5-10% overhead on execution time. Catch drift early and full-task re-run cost drops 60-80%.
- Long-horizon drift is systemic; a frontier model inherits it, and end-of-task checks only price the rework late.
The three causes of agent drift
Context window compression causes earlier instructions to receive lower attention weight as the context grows. In a 15-step task, the original goal specification is in the earliest part of the context by step 12. it's still there - but it competes for attention with 11 steps of intermediate results, tool outputs, and updated plans. The agent's effective goal representation shifts from the original specification toward the most recent plan state, which may have drifted.
Plan-goal misalignment emerges when the agent optimizes its current plan rather than the original goal. It happens gradually. Step 4: an obstacle, plan adjusted to work around it. That adjustment is subtly different from the original goal. Step 10: the plan has shifted 3-4 times. The original goal is only partially represented in what's actually executing.
External state change affects tasks that run for minutes to hours in a changing environment. If the agent begins a customer outreach task at 9am and the customer's account status changes at 9:15am, a plan that was correct at 9am may be wrong at 9:15am. End-of-task verification detects the outcome mismatch but can't attribute it to the state change - and can't recover the work already done toward the original, now-stale plan.
Continuous verification checkpoint design
A checkpoint consists of three components: a goal re-read (retrieve and re-anchor to the original goal specification), a state consistency check (confirm that the current plan is consistent with the current world state and the original goal), and a progress evaluation (confirm that the work completed so far is moving toward the goal, not away from it).
Checkpoint frequency should match the drift risk profile of the task. Tasks with stable external state and simple plans can run 10-15 steps between checkpoints. Tasks with volatile external state (prices, availability, account status) or complex plans need checkpoints every 3-5 steps. Irreversible action points always require a checkpoint immediately before the action regardless of step count.
# Continuous verification checkpoint class AgentCheckpoint: def __init__(self, original_goal, step_interval=5): self.original_goal = original_goal self.step_interval = step_interval self.step_count = 0def after_step(self, agent_state, world_state): self.step_count += 1 if self.step_count % self.step_interval != 0: return
Re-read original goal
goal_alignment = measure_alignment(agent_state.current_plan, self.original_goal) if goal_alignment < 0.8: # below threshold return CheckpointResult.REALIGN(original_goal=self.original_goal)
Check world state consistency
if not world_state.consistent_with(agent_state.plan_assumptions): return CheckpointResult.REPLAN(current_step=self.step_count)
return CheckpointResult.CONTINUE
Checkpoint strategy comparison
| Strategy | Drift detection point | Remediation cost | Overhead |
|---|---|---|---|
| End-of-task only | After full task run | Full task re-run | Very low |
| Fixed-interval checkpoints | Within interval window | Re-run from checkpoint | 5-10% |
| Risk-triggered checkpoints | Before high-risk actions | Partial re-run or re-anchor | 3-7% |
| Continuous state monitoring | At each step | Surgical re-anchor | 15-25% |
The Pattern Intelligence Layer specifies checkpoint intervals as a required attribute of every long-running pattern. The interval is determined by the pattern's drift risk classification: stable-environment patterns use 10-step intervals; volatile-environment patterns use 3-step intervals; all patterns require a checkpoint before irreversible actions. Continuous verification isn't an operational afterthought - it's a specification requirement in the pattern design.