Your AI Agent Forgot the Plan. It Never Remembered It.

Your AI Agent Forgot the Plan. It Never Remembered It.

You shipped a multi-step agent. It has a plan. You think it’s following that plan. It isn’t — it’s just re-reading it every turn, and the moment your context management evicts it, the agent goes blind. This paper measures exactly how fast that happens, and the number is brutal.

What happened

(a) Layer profile at step + 1 +1 .
(a) Layer profile at step + 1 +1 .

Researchers at Carnegie Mellon ran a targeted diagnostic on LLM agents to answer a simple question: does a plan live in the model’s hidden state, or does it just live in the context window? The answer is the latter, and it decays fast. Using a technique called replay pairing — running the same trajectory with and without the plan in history, then measuring hidden-state cosine distance — they found that on Llama-3.1-70B, plan signal spikes to 0.453 one step after the plan is written, then drops 4.1× in a single action-observation step. On HotpotQA, it falls 12.4× in that same single step. The practical cost is concrete: naively evicting the plan (standard context compression behavior) cuts ALFWorld task success by 34.7 percentage points. They also tested a “fix” — probe-gated re-surfacing of the plan — and it did not recover the lost performance. Separately, they found that reasoning models like DeepSeek-R1 create a measurement confound: their <think> traces re-derive plan content, masking the decay unless you apply strict stripping, which recovers +163% of the diagnostic signal in-sample.

Cold read

This is a measurement paper, not a solutions paper — and the authors are upfront about that, which is more than most. The probe detects decay as a diagnostic signal; the paper explicitly states it is not proof that the probe reads plan content itself. The ALFWorld benchmark is narrow: it’s a text-based household task environment, and a 34.7pp drop there doesn’t automatically translate to your specific agentic workflow. The probe-gated re-surfacing failure is actually the most important result in the paper and gets the least explanation — we don’t know why it doesn’t recover performance, which means the fix space is still wide open and uncharted. The study uses two models (Llama-3.1-70B and DeepSeek-R1-Distill-Llama-70B); generalization to GPT-4o, Claude 3.x, or any proprietary system you’re probably running is unproven. Finally, the agent memory vs. context window problem is well-known in the field — this paper sharpens the measurement toolkit, but doesn’t move the needle on solutions.

What it means for you

  • Signal maturity: 3/5 — rigorous diagnostics, zero production fixes
  • Who gets hurt: Any team shipping long-horizon agents (customer support automation, coding agents, ops orchestration) that relies on standard context compression or sliding-window eviction
  • What breaks if this is true: Your agent’s “plan” is load-bearing scaffolding in the prompt, not internalized behavior — evict it during a long task and success rates crater in ways your evals almost certainly aren’t catching
  • Why it might not land: If you’re using RAG-style retrieval to re-inject plans on every step anyway, you’ve accidentally solved this; many production systems already do this without knowing why it works
  • Watch for: Eval frameworks that specifically test plan-persistence across eviction events — if this paper gets traction, that becomes the new baseline requirement for any agent benchmark worth trusting

Forecast as of 2026-06-23

By Q3 2027, at least one major agent orchestration framework (LangGraph, AutoGen, or a direct competitor) will have shipped a native “plan protection” or plan re-surfacing policy as a first-class feature, citing context eviction failure rates — but adoption will remain low because teams won’t have evals to measure whether it helps.


Source: Plans Don’t Persist: Why Context Management Is Load Bearing for LLM Agents — Aman Mehta, Anupam Datta. https://arxiv.org/abs/2606.22953v1

Similar Posts