Agent memory shifts from storage to control: five developments, June 20–August 19, 2026

The strongest agent-memory work in this window moved the hard problem one step upstream. An agent now has to decide what state deserves promotion, when an intention needs a reminder, whether a retrieved fact is current enough to act on, and how derived state can be revoked. That is a control problem, not just a storage problem.

This issue covers developments published from June 20 through August 19, 2026, using Asia/Dhaka as the cutoff timezone. The five items below show different answers to that control problem.

Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents treats memory as an intervention during execution. The paper names the failure mode behavioral state decay: requirements, environment facts, failed attempts, diagnoses, and open subgoals remain somewhere in the trajectory but stop affecting the next action. 1

The design adds a memory agent beside an otherwise unchanged action agent. It maintains three kinds of state: private progress and risks, stable task or environment knowledge, and procedural experience such as failed commands and successful fixes. At each scheduled check, it can update the bank, delete stale entries, emit a short reminder, or choose a null intervention and stay silent. The main setup observes the latest eight messages and runs the memory agent at every later step. 1

The result is large enough to matter, but it is not a license to inject memory constantly. On Terminal-Bench 2.0, Claude Sonnet 4.5 moved from 37.6% to 45.9% pass@1 with the memory agent. On the task-weighted average of τ²-Bench, it moved from 55.0% to 61.8%. The ablation points in the same direction: the full system, which combines a persistent bank with selective reminders, reached a 64.3% macro average, while exposing the full bank at every step reached 61.5%. 1

Why it matters for builders: a useful memory layer needs a calibrated no-op. Exposing the whole bank turns memory into another context tax; forcing a reminder turns it into noise. A separate controller can preserve execution state without retraining the action policy, but it adds a model call on a schedule that the paper still fixes by hand. Start by measuring reminder usefulness and distraction, not only whether the store contains the right fact.

Most memory evaluations ask whether an agent can retrieve something that happened earlier. PM-Bench: Evaluating Prospective Memory in LLM Agents asks a different question: can the agent remember an intention, wait for the right time or event, notice updates, and act without false alarms? 2

The benchmark simulates a seven-day week with 80 decision steps. Its released scenario contains 81 scored executable tasks, including time-based and event-based intentions, seven cross-day tasks, cancellations, overrides, reschedules, dependencies, hidden-state channels, and lure actions. The main metric is Set-F1 over the full trajectory: due actions selected on time count as true positives, while premature actions and missed actions count against the agent. 2

The best aggregate configuration was an optional heartbeat, which lets the agent decide whether to monitor, at 65.1% macro Set-F1 versus 60.0% for the single-agent baseline. Automatic monitoring every 30 minutes fell to 57.8% and produced 489 false positives. A hierarchical multi-agent setup issued 1,661 queries but reached only 45.2%. Cross-day and update-sensitive tasks stayed below 50% for every setup in the reported aggregate results. 2

Why it matters for builders: retrospective recall and prospective memory should be separate rows in an evaluation plan. A todo list, heartbeat, or monitoring agent changes the trade-off between missed intentions and false alarms. Test cancellations, changed authority, and delayed execution directly; more queries and more reminders can make the system worse.

Zero-Mem: Zero-Token Memory Operations for LLM Agents takes the opposite route from an LLM-managed memory bank. It keeps original interaction traces, connects entities to those traces in a graph, and preserves turns, windows, episodes, and local spans in a temporal hierarchy. A deterministic query profile extracts subjects, keywords, answer types, temporal cues, and boundary constraints before the system fuses graph and hierarchy results. 3

The paper uses no LLM calls or LLM input/output tokens for memory construction, organization, routing, retrieval, evidence closure, or calibration. The final language model only answers from the selected evidence. The pipeline still spends compute on entity recognition, embeddings, indexing, graph propagation, and deterministic filtering, so zero-token does not mean zero cost. 3

On LoCoMo, the system reports 59.15 F1 with GPT-4o-mini, compared with 53.75 for its strongest baseline in the unified comparison. In the same efficiency study, memory operations took 0.22 seconds per query, a 57.6% reduction versus the fastest comparison system, while preserving links to source identifiers, timestamps, and sessions. 3

Why it matters for builders: an agent does not have to make the language model responsible for every memory decision. A provenance-preserving, deterministic retrieval layer can lower recurring model cost and make evidence easier to inspect. The trade is engineering surface area: someone must maintain the entity graph, temporal index, query parser, score fusion, and conflict filters. This is a useful option when reproducibility and traceability matter more than having the model write elegant summaries.

SkillJack: Persistent Skill Backdoors in Self-Evolving Agents follows memory beyond retrieval. Its attacker controls an experience record, not the skill library, router, extraction code, or base model. The poisoned trajectory enters an experience-to-skill pipeline, gets normalized into a reusable skill, and can survive after the original record is deleted. 4

The security finding is about transformation. In the SkillX experiment, an LLM judge detected 98.5% of framed malicious trajectories before extraction but only 11.4% of the derived skills afterward. The paper reports that 80.0% of skill-based triggers remained after the source trajectories were removed. The study used one model and proxy measures rather than live actions against external services, so these figures measure a demonstrated failure path, not a deployment-wide compromise rate. 4

Why it matters for builders: extraction is not a security-neutral cleanup step. Treat raw experience, extracted skills, routing metadata, and executable behavior as separate trust boundaries. Store lineage from every derived artifact to its inputs, make revocation cascade to descendants, and test the transformed skill rather than reviewing only the original trajectory. Runtime monitoring should watch behavior and normalized action patterns, because a clean-looking skill description can hide a policy-relevant instruction.

RippleMem: From Isolated Retrieval to Associative Recollection for Long-Term Agent Memory starts from a practical failure: the answer to a later question may be spread across several sessions, while flat retrieval returns one relevant fragment and misses the supporting facts around it. RippleMem stores self-contained episodic units in an event-centric graph. Semantic edges connect similar events; structural edges connect shared people, places, and nearby times. 5

Retrieval begins with semantic, lexical, and structured cues. A controller then selects up to three memory anchors, states what support is missing, and expands up to two graph hops around those anchors. The final context is assembled from deduplicated evidence rather than from the first top-k hits. On LoCoMo, RippleMem reports 87.14% judge accuracy; removing graph expansion drops that figure to 83.12%. 5

The construction cost is also part of the result. In the paper's LoCoMo comparison, RippleMem took 117.51 seconds and 87,097 tokens per dialogue, versus 3,623.63 seconds and 4,243,278 tokens for Mem0g. Query-time recollection planning adds an average of 2,880.6 prompt and completion tokens per question. The evaluation remains text-only and uses fixed graph thresholds, budgets, and cue weights. 5

Why it matters for builders: retrieval quality can depend on how the system completes evidence after the first hit, not only on the first hit's ranking. An event graph and a bounded expansion step can recover distributed support, but they add controller calls and configuration choices. Preserve the raw episode, expose retrieval provenance, and measure whether expansion adds the missing fact rather than merely adding more context.

Memory is becoming a policy. The proactive-memory agent decides when to interrupt an action loop, while PM-Bench shows that monitoring frequency changes false alarms as much as recall. A store without a promotion and suppression policy is only half a memory system.

The working set should be compiled for the decision. Zero-Mem keeps raw traces and deterministically selects evidence. RippleMem starts with anchors and expands toward missing support. Both approaches question the idea that one universal summary or one similarity-ranked list is the right context for every action.

Derived state needs lineage. SkillJack shows why a delete operation that reaches only the original record is incomplete. Skills, summaries, graphs, and other promoted artifacts need provenance, versioning, and descendant-aware revocation.

The concrete next action is to run one small, fixed-horizon suite against your own agent with four tracks: retrospective questions, cross-day intentions and updates, retrieval provenance, and source deletion followed by descendant checks. Record success, false alarms, latency, model-token cost, and whether the agent can explain which evidence it used. These papers are not a single leaderboard—their tasks and readers differ—but together they show what a production memory evaluation needs to expose.