A memory system that keeps quiet most of the time beat one that always spoke up. It also beat merely making the memory available, beat an advisor that offered guidance, and beat generic retrieval. That result, from a paper submitted on July 9, is the most useful thing published about agent memory this year — and it points the opposite direction from where most teams are building [1].
The reflex, when a long-running agent loses the thread, is to give it more. More context window. A vector store. A retrieval step before every action. The paper's ablations say all of those are the wrong shape of fix, and it says so with numbers.
The failure has a name now
The authors call it behavioral state decay: in long-horizon tasks, decision-relevant information becomes buried in expanding trajectories [1].
That phrasing is precise in a way worth unpacking. The information is not lost. It is present, in the trajectory, exactly where it was written. It has simply been pushed so far from the current decision by thousands of intervening tokens — tool outputs, retries, dead ends, file listings — that it no longer influences behavior. The agent has the fact and acts as though it does not.
Anyone who has watched an agent spend forty minutes on a task recognizes the pattern. It establishes a constraint early ("the test suite must be run with the integration flag"), works productively for twenty steps, and then quietly violates that constraint at step forty. Nothing was forgotten in the storage sense. The signal got diluted.
This is a different problem from a context window overflowing, and treating them as the same problem is why the obvious fixes underperform.
The method: a second agent whose only job is timing
The architecture is deliberately unambitious about the thing everyone else optimizes.
A separate memory agent runs alongside an unmodified action agent, "updating a structured memory bank from the recent trajectory and deciding whether to inject a memory-grounded reminder or remain silent" [1]. It ships as a plug-and-play module compatible with existing agents — the action agent is not retrained, rewired, or told it has a memory.
Two design choices carry the result.
First, the memory agent is separate. It is not a retrieval step inside the action loop; it is a parallel process observing the trajectory and forming its own view of what matters. That separation is what makes it plug-and-play, and it means the memory policy can be improved without touching the agent doing the work.
Second, and this is the whole paper, the memory agent's output is a decision about whether to speak. Not what to retrieve. Whether to interrupt at all.
On Terminal-Bench 2.0, pass@1 improved by 8.3 percentage points. On τ²-Bench, 6.8 points [1]. Those are meaningful gains on long-horizon benchmarks where agents operate in realistic command-line and tool-use environments, and they were obtained without modifying the underlying agent.
The ablations are the actual finding
Headline numbers from a new method are cheap. What makes this paper worth reading is that the authors tested the alternatives you were about to build, and reported that selective intervention outperformed all of them [1]:
- Passive bank exposure — the memory exists and the agent can consult it. Lost.
- Always-on injection — every step gets a reminder. Lost.
- Advisor-only guidance — a helper offering suggestions without structured memory. Lost.
- General retrieval — the standard RAG-shaped answer. Lost.
Take those four together and a pattern emerges. Each represents a different theory of the problem. Passive exposure assumes the issue is availability. Always-on injection assumes it is salience. Advisor-only assumes it is reasoning. General retrieval assumes it is lookup. All four lost to a system that assumes the problem is knowing which moment needs which memory.
The always-on result deserves particular attention, because it is the one that feels safest. If reminders help, remind constantly. But a reminder injected at every step is a reminder that costs tokens on every step and adds noise on the steps where it was irrelevant — which is most of them. Constant intervention re-creates the original disease: important signal diluted among unimportant text.
Restraint, measured, was the feature.
What the benchmarks are actually measuring
The choice of benchmarks matters, because agent memory results are easy to fake on the wrong test.
Terminal-Bench 2.0 and τ²-Bench are both long-horizon evaluations — agents operating over extended sequences in realistic command-line and tool-use environments, where the trajectory grows large enough for decay to appear [1]. That is the necessary condition. A memory intervention tested on a short task will show nothing, because there is nothing to bury.
The training detail is worth noting too: the memory agent was trained on SETA using Qwen3.5-27B [1]. An open-weight model in the mid-tens of billions of parameters, not a frontier system. The memory policy did not require the largest available model to be useful, which is the more encouraging read — deciding when a reminder is warranted appears to be a smaller problem than solving the task itself.
AMA-Bench approaches the same question from the evaluation side, deliberately mixing real agent trajectories with expert-curated question-answer pairs and synthetic trajectories, and measuring retention and retrieval across continuous agent-environment interaction — states, actions, observations, tool outputs [2]. That composition is a hedge against a specific failure: a benchmark built only from synthetic trajectories rewards systems tuned to synthetic structure.
Why the naive versions fail
The companion evidence comes from AMA-Bench, a benchmark built for exactly this question. It combines real agent trajectories with expert-curated question-answer pairs plus synthetic trajectories, and measures retention and retrieval across continuous agent-environment interaction — states, actions, observations, tool outputs [2].
Its diagnosis of why existing memory systems underperform: "they fail to capture causal and objective information and rely heavily on lossy similarity-based retrieval" [2].
Both halves of that matter. Similarity-based retrieval is lossy because semantic nearness is a poor proxy for decision relevance — the chunk that mentions "test suite" is not necessarily the chunk carrying the constraint you must not violate. And causal and objective information is precisely the category that similarity search discards: why a step was taken, what it was in service of, what depends on what.
The benchmark's own proposed system, AMA-Agent, attacks this with causality-graph construction plus tool-augmented retrieval, reaching 57.22% accuracy and outperforming the strongest baseline by 11.16% [2].
Note what 57.22% means. The best result on the benchmark, from a method purpose-built for it, leaves more than four in ten questions wrong. Agent memory is not a solved problem with a known best practice. It is an open research area where the leading approaches are still failing routinely.
The obvious pushback
The honest objections are worth stating.
The deltas are single-digit. 8.3 and 6.8 percentage points are real but not transformative, and they come from one paper that has not yet been independently replicated. Anyone reading this as "add a memory agent and your success rate jumps" is reading it wrong.
The comparison is against baselines the authors chose. That is standard practice and also a standing caveat on every ablation table ever published. The finding that selective intervention beat four alternatives is strong evidence about those four implementations, not proof that no always-on design could win.
There is added cost. A second agent observing every trajectory is a second stream of inference. The paper's framing as plug-and-play addresses integration effort, not compute budget.
What survives the objections is the directional claim, and it is the part that should change how you build: the gains came from a policy about when to intervene, not from more storage or better search. That finding is robust across the ablations even if the exact magnitudes move.
Memory is becoming a policy, not a store
The mental model most teams carry is that agent memory is infrastructure — a database you write to and query. Both papers point somewhere else. What these systems do is make decisions: what to record, what to discard, whether this moment warrants an interruption. That is a policy, and policies have their own objectives, their own failure modes, and apparently their own agent.
It also explains why the plug-and-play framing is more than a convenience claim. If memory were infrastructure, it would belong inside the agent, coupled to its reasoning. If memory is a policy, it can live outside — observing, deciding, and improving on its own schedule, against its own objective, without the action agent knowing it exists [1]. Separation is not a compromise in that design. It is the consequence of taking the policy view seriously.
The practical read for anyone building long-horizon agents today: stop treating "the agent forgot" as a retrieval bug. Instrument for it instead. Log the constraints established early in a task and check, at the end, whether they were honored. The gap between what your agent was told at step three and what it did at step forty is measurable, and until you measure it you will keep buying context window to fix a timing problem.
And when you do add memory, measure the silent version against the chatty one. Every instinct will push toward injecting more often. The only published ablation on the question says that instinct loses [1].
The teams that get this right will not be the ones with the largest memory. They will be the ones whose agents know when to remember out loud.
References
[1] Wu, Zhang, Zhou, Wang, Peng, Li, Fan and Zhao — Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents — (2026-07-09). Paper
[2] Zhao, Yuan, Huang, Yuan, Yu, Xu, Hu, Shankarampeta, Huang, Ni, Tian and Zhao — AMA-Bench: Evaluating Long-Horizon Memory for Agentic Applications — (2026-02-26). Paper