The Compliance Trap: Consuming Conflicting Agent Memory¶
Agents tend to comply with retrieved memory that conflicts with the current situation, adopting the stale memory at the first step and rarely recovering.
Agent memory is usually treated as a supply problem: what to write, how to store it, which entry to retrieve. The failure that actually costs you is in consumption. When a retrieved memory conflicts with what the agent is seeing now, the agent tends to follow the memory rather than the current observation. Success rates fall, and stronger models lose the most in absolute terms (Chen et al., 2026).
The pattern¶
A retrieved memory suggests an action that no longer fits the task in front of the agent. The agent complies at the first decision point, then reasons forward on top of that choice. The Entry–Propagation–Recovery (E-P-R) lens names the three places the damage shows up (Chen et al., 2026):
- Entry: the conflicting memory changes the first action. First divergence is early, with cumulative probability 0.86 to 0.94 by step 7.
- Propagation: later steps build on the wrong first step. Persistent exposure to the bad memory does more harm than a single early injection.
- Recovery: the agent rarely course-corrects. Conflicting-memory trajectories realign only 7 to 15% of the time, against 27 to 42% for helpful memory.
Compliance stays high and roughly constant across models (63 to 72%), but success after complying collapses to 17 to 31%. On the WebArena memory-sensitive subset, persistent conflicting memory cut success by up to 20.8 points; on MemTrapBench the strongest model tested dropped 26.0 points (Chen et al., 2026).
Why it works¶
The agent consumes retrieved memory as an authoritative prior instead of checking it against the current observation. Placement does not matter: the trap holds whether the memory sits in the system prompt or an observation footer, so this is a general consumption behavior, not a prompt-injection artifact (Chen et al., 2026). Because the bad memory changes the very first action, and each later step is taken to be coherent with it, the error propagates rather than surfaces. This is the same false-premise dynamic that locks in a coding agent when a decisive early error goes unchecked (recovery window) and the mechanism behind context poisoning, where an adopted premise is reasoned forward as fact.
When this backfires¶
The anti-pattern framing does not apply, and defending against it only adds cost, when any of these hold:
- Stateless or no-memory agents: with no retrieved memory there is no conflict to consume.
- Short single-step tasks: the trap needs a multi-step trajectory for the entry error to propagate.
- Well-curated, task-scoped memory with strong retrieval: conflict rarely surfaces, so a retry policy spends compute defending against a rare event.
- Cheap-recovery environments: read-only or trivially reversible tasks weaken the "recovery is narrow" premise, since a wrong early step costs little to undo.
Example¶
The paper's tested fix is a change to the consumption policy, not the store. Injecting the top retrieved memory on every task is what exposes the agent to conflict at entry; running clean first and reaching for memory only on failure removes that exposure.
The failure mode, memory injected on every task:
policy: always-inject
step 1: retrieve top memory, add to context
step 2..n: act with memory present
# a conflicting entry changes the first action; the run locks in
The corrected form, retry only on failure:
policy: retry-on-fail
attempt 1: run with no memory
attempt 2: retry with helpful memory only if attempt 1 failed
Retry-on-fail closed 96 to 101% of the schedule-oracle gap on MemTrapBench, beating always-inject. A softer fix — prefixing memory with a "verify before acting" warning — cut conflicting damage by 17.2 points but also cut the gains from helpful memory by 11.0 points, making the agent uniformly less compliant rather than more discerning (Chen et al., 2026).
Key Takeaways¶
- The failure is in consumption, not supply: agents comply with conflicting retrieved memory at the first step and rarely recover, so evaluating retrieval quality and final success alone misses it.
- Use the Entry–Propagation–Recovery lens to locate the damage — most of it originates at entry, so premise checks belong before the first action, not at the end.
- Prefer a consumption policy that limits exposure, such as running clean and retrying with memory only on failure, over blanket memory injection or a generic "verify first" instruction.
Related¶
- Agent Memory Patterns: Learning Across Conversations — the supply-side framing (write, store, retrieve) that this consumption failure sits underneath
- Memory Retrieval as a Control Decision — treating whether to inject a memory as a gated decision, the direction the retry-on-fail fix points
- Agent Failure Trajectories and the Recovery Window — the same early-entry, false-premise, narrow-recovery shape in coding-agent runs
- Context Poisoning: When Hallucinations Become Premises — an adopted premise reasoned forward as fact, the consumption mechanism without the memory store
- Memory-Induced Tool-Drift — a sibling memory failure where stored preferences silently steer tool calls in unrelated contexts