Agent Memory Now Includes Retrieval Decisions and Learned Procedures
Seven recent preprints show why long-running agents need different memory structures, explicit retrieval decisions, revision, forgetting, and tests based on actual work.

Scope note: This review covers how seven recent preprints define, retrieve, test, and revise memory for long-running AI agents. It does not compare commercial memory products or establish one correct architecture for every agent.
Most agent memory still behaves like saved text plus similarity search. The agent records an interaction, converts it into an embedding, and later retrieves whichever record looks related to the current prompt.
That design is useful. It is also incomplete.
Across seven recent preprints, researchers are treating memory as a set of decisions: what should be recorded, which form it should take, when it should be retrieved, whether it remains true, and which past action should affect the next one. The change is practical. An agent that works for weeks cannot treat every prior sentence as equally useful evidence.
My reading is that agent memory is becoming part of agent behavior. Storage remains necessary, but storage alone does not explain how an agent learns from experience.
Recall is not enough
LifeBench tests memory across long simulated lives built from events, calendars, locations, preferences, habits, and procedures. The strongest systems reached only 55.2 percent accuracy. The important difficulty was not recalling a sentence. Agents had to infer repeated behavior from several kinds of evidence gathered over time.
AMA-Bench reaches a similar conclusion with trajectories from real agent applications. The authors report that common memory systems lose causal and objective information because similarity search favors related wording, not necessarily the event that caused the current state. Their proposed system adds a causality graph and tool-assisted retrieval, improving average accuracy by 11.16 percentage points over the strongest baseline they tested.
These findings matter because an agent can retrieve a relevant record and still make the wrong decision. “Relevant” does not mean “causally important.” It also does not mean “still valid.”
The agent must decide when retrieval is worth doing
Ask Only When Needed makes retrieval an explicit agent action. Its ProactAgent system learns when a knowledge gap warrants a memory lookup and which kind of experience to request. The memory is divided into facts, episodes, and behavioral skills. Retrieval is rewarded when it improves the next decision or reduces wasted work.
The reported results are substantial: 73.5 percent success on SciWorld and 71.28 percent on AlfWorld, with less retrieval overhead than systems that consult memory more routinely.
I find the efficiency result as important as the success rate. Retrieval consumes tokens and time. It can also introduce an old detail that distracts the agent. A competent memory system needs a reason to retrieve, not a general instruction to remember everything.
Choosing How to Remember applies the same principle to memory structure. Its FluxMem framework selects among several forms of memory based on the interaction. It reported average improvements of 9.18 percent on PersonaMem and 6.14 percent on LoCoMo. The result argues against one fixed format for every task.
Procedures deserve their own representation
Some experience is best recorded as an event: a deployment failed after a dependency changed. Some is better recorded as a procedure: inspect the lockfile before rebuilding. If both are stored as undifferentiated prose, the agent must reconstruct the procedure every time.
PRO-LONG stores a complete structured interaction history and lets coding agents search it programmatically. On the public ARC-AGI-3 games, it improved average pass rates by 18 percentage points while using 4.2 to 5.8 times fewer tokens than specialized alternatives. The paper shows that complete retention can remain useful when the system supplies an exact method for querying the history.
MemPro changes a different part of the system. It treats the entire memory construction and retrieval process as an editable program. The system keeps runnable versions, diagnoses recurring failures, and creates revised implementations. Across four benchmarks, those program revisions continued to improve results beyond static and prompt-only baselines.
The distinction is important. A memory record can be correct while the memory process remains poor. If the system repeatedly stores the wrong detail or retrieves at the wrong time, editing individual records will not correct the process.
Long-term memory requires governance
Is Agent Memory a Database? identifies four recurring failures: uncontrolled growth, missing semantic revision, capacity-based forgetting, and read-only retrieval. The authors propose explicit operations for ingestion, revision, forgetting, and retrieval, with correctness defined across the changing state of memory.
That last point deserves attention. A long-running agent will encounter corrections. A project changes its name. A person changes roles. A workaround becomes unnecessary. The system must preserve useful history without presenting an obsolete state as current fact.
This is where I think many production designs remain weak. Teams discuss persistence before they define revision authority. They discuss retrieval quality before they define deletion. They discuss personalization before they define what the agent must not infer.
What I would require
The seven papers do not identify one winning implementation. They do identify a more demanding test for agent memory.
I would ask whether the system can distinguish facts, events, habits, and procedures. I would test whether retrieval improves the next action rather than merely returning similar text. I would record why a memory changed, who or what authorized the change, and whether older conclusions remain available for audit. I would also measure repeated work over time, because a question-answer benchmark cannot show whether the agent develops a useful procedure.
The practical conclusion is simple. Persistent storage gives an agent a history. A governed process for selecting, revising, and applying that history gives the agent a chance to improve.
