Plan Decay: When Multi-Step Plans Stop Matching Reality

Plan decay is the progressive mismatch between an agent's multi-step plan and the actual state of the world it is executing in. A plan is a set of predictions: that step three's preconditions will hold when step three runs, that the file inspected an hour ago is unchanged, that a subtask marked done actually produced its output. As execution proceeds and the environment moves, those predictions expire one by one. The plan can decay without any step visibly failing, which is what makes it dangerous: the agent keeps executing a script for a world that no longer exists.

Plan decay is a mechanism of behavioral state decay distinct from goal drift: in goal drift the objective shifts, while in plan decay the objective is intact but the path to it has gone stale. The two compound, since a decayed plan is often rationalized into a new goal.

Mechanism

Plans decay through four channels.

Environment change. Files get edited by other processes, tickets close, dependencies update, data refreshes. Any plan detail derived from an observation is a cached value with no invalidation signal attached.

Execution side effects. The plan's own earlier steps change the world in ways the later steps did not anticipate: a refactor in step two renames the function step five expects, a cleanup step deletes an artifact a later verification needed. Longer plans front-load more of these interactions.

Silent partial failure. A step reports success but delivers less than assumed: a fetch returns a truncated result, a test run skips half the suite, a write lands in the wrong directory. The plan's checkpoint state says done, the world says otherwise, and every subsequent step inherits the gap.

Assumption expiry under compression. In long sessions the plan's rationale, the constraints and observations that justified each step, gets summarized away first. This is compaction loss, the removal of information by summarization; it is related to but distinct from context rot, where information stays present yet goes unused. Either way, the agent retains the step list but loses the ability to notice when a step's justification no longer holds.

How to measure

Staleness is measurable as the diff between planned assumptions and observed reality.

• Write plans with explicit, checkable preconditions per step (file exists, test passes, value in range), then log precondition failures at execution time. Rising precondition failure rate over plan age approximates the decay curve, but it is confounded by task mix, environment volatility, and initial plan quality: stratify by workflow and environment, define the at-risk denominator, and compare against matched plans before reading a trend.
• Track plan mutation rate: how often steps are reordered, reworked, or abandoned mid-run. Treat the rate as descriptive rather than intrinsically healthy or unhealthy; scheduled revision and firefighting can look alike in raw counts, so read it alongside what triggered each mutation.
• Diff plan-recorded state against fresh observation at checkpoints: re-verify a sample of completed steps' outputs rather than trusting their status flags.
• Include a long-horizon scenario in your replayed suite, per drift regression tests, where the environment mutates mid-plan; measure whether the agent detects the mutation or executes through it.
• At the system level, plan-related instability contributes to the reasoning-pathway and consistency dimensions tracked by the Agent Stability Index.

Mitigation

Design plans to be re-derivable rather than durable. Keep the plan as an external artifact with per-step status and preconditions, per state externalization, so staleness is inspectable instead of buried in the context window. Re-plan on a cadence: after every irreversible action, after any precondition failure, and at fixed intervals on long runs, feeding re-planning from fresh observation rather than from the plan's own cached claims. Prefer shorter plan horizons with explicit checkpoints over one grand sequence; each checkpoint is a scheduled collision with reality. And when a precondition fails, stop and re-anchor on the goal artifact, per re-anchoring patterns, rather than patching the dead step locally, because a failed precondition is evidence about the world, not just about the step.

Related terms

• Behavioral state decay: the umbrella phenomenon; plan decay is its plan-level mechanism.
• Goal drift: objective-level divergence; distinct from, but compounding with, plan decay.
• Context rot: makes the plan's rationale harder to use even while present; compaction loss removes it outright.
• State externalization: makes plan status inspectable and survivable.
• Drift regression tests: the harness for measuring decay longitudinally.

FAQ

How is plan decay different from just bad planning? A bad plan is wrong at birth: its assumptions never held. A decayed plan was valid when written and was invalidated by time and events. The distinction matters operationally because bad planning is fixed by better upfront reasoning, while plan decay is fixed by revalidation cadence; no amount of planning skill prevents the world from changing.

Should agents re-plan every step to avoid decay entirely? No. Re-planning every step discards the coordination value plans provide and invites thrash, where each step's local context pulls the trajectory in a new direction. The working compromise is cheap precondition checks every step, full re-planning only at checkpoints or on precondition failure.

Is plan decay unique to AI agents? No, and that is useful. Project management and robotics have handled it for decades with the same instruments: milestone reviews, precondition checks, and re-planning triggers. What is new with LLM agents is the silent-rationalization failure mode, where the agent smooths over a dead step instead of reporting it, which is why decay detection should automate objective checks wherever possible and route the semantic or probabilistic remainder to independent review or calibrated judges rather than the executing agent's own judgment.