Designing agent memory for retrieval, applicability, and updates

Remembering a preference can still produce the wrong response

Suppose a writing assistant remembers that a user prefers brief explanations. Today the user asks for a detailed introduction for new employees. Retrieving the old preference correctly but prioritizing it over today's explicit request produces an unhelpful document. This is a hypothetical example for examining memory design.

Correct recall is only part of the problem. The system also needs to determine whose information it is, when it applied, and whether it governs the current task. Drawing on research and implementation material available by April 8, 2026, this article separates retrieving, applying, and updating memory.

Retrieval methods and memory scope are separate choices

Vector retrieval and short-term, long-term, or shared memory are not competing alternatives. Vector retrieval finds semantically related candidates. Duration and sharing describe other dimensions that can coexist with it. File-backed records can also be indexed, so storage format should be distinguished from retrieval method.

LangGraph documentation separates conversation tracking within a thread from user or application information spanning conversations; its long-term store example uses a user-specific namespace. This illustrates choosing scope before searching. A namespace label alone is not access control: the application must establish that the caller may read that scope.

For the document example, distinguish the user's preference, the current request, and formal organizational writing rules. These distinctions can be represented with subjects, sources, and applicability conditions even inside one database. Adding physical stores is not itself the objective.

Apply corrections before background memory processing finishes

A correction such as “make detailed explanations my default from now on” differs from a request for one document. If it is stored, its continuing scope should be retained. Inferring a permanent preference from one ambiguous action could affect unrelated future work.

I recommend applying explicit corrections to the active task immediately and preventing later background summaries from overriding them. Record source statements, update targets, and effective times instead of ranking facts solely by storage time. A summary created today from yesterday's conversation can contain information older than today's correction.

A graph representation still needs such update rules. Making a relationship explicit does not establish that it is correct or remains valid. Compare graphs, vector retrieval, and structured records using the same update tasks and cost conditions.

Shared memory introduces write conflicts as well as retrieval problems

When several agents edit one project note, an update can be lost. Letta's shared-memory documentation distinguishes appending, targeted replacement, and full rewrites, identifying last-writer-wins behavior for concurrent full rewrites. This is a property of those update operations, not evidence that shared memory always fails.

For example, agent A corrects a deadline while agent B adds an owner to an old copy and saves the whole note, erasing A's change. In this hypothetical case, compare targeted edits, version checks before saving, or one owner for full rewrites. Better retrieval cannot recover an update lost during storage.

Test remembered facts, corrections, and abstention separately

LongMemEval evaluates extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention. It offers a research example of evaluating memory beyond finding a related record. Its categories do not establish a universally best memory architecture for individual business tasks.

For the writing assistant, test a question about the previous preference, a one-off conflicting request, a lasting correction, and a preference never stated. Inspect what was saved and retrieved and which condition was applied, alongside the answer. Check whether the assistant can ask when information is missing and avoid saving a guess as fact.

The number of examples in public documentation cannot establish which design is most prevalent, cheapest, or most accurate. Before adding memory mechanisms, identify the failure being corrected. Missed retrieval, stale applicability, incorrect storage, and lost concurrent updates require different repairs.