Agent memory design: why correct recall can still lead to the wrong decision

An assistant can remember a preference and still miss the request

Repeating the same preferences to a writing assistant makes every task harder to start. If it carries “keep explanations brief” into tomorrow's work, memory seems useful. But suppose you now request a detailed introduction for new employees and the assistant still produces a short summary. It has remembered correctly and delivered the wrong document. This is a hypothetical example for examining memory design.

Better retrieval alone cannot repair this failure. Previous preferences, current instructions, and organizational rules need different applicability conditions. The system also needs to decide what to update when a preference changes and when to stop using an old summary. Otherwise, a helpful record from yesterday can become a source of error today.

Drawing on implementations and research published by April 8, 2026, this article distinguishes finding information from keeping it fit to inform a decision. Conversation state, durable preferences, and shared records differ in how they are read, who updates them, and how long they remain useful. Preserving these distinctions matters more than adding physical stores.

Finding information and applying it to work are different decisions

Retrieval-augmented generation supplies a model with information retrieved from outside its immediate input. Similar retrieval can be applied to conversations and personal records. But reading a product specification and applying a user's previous preference require different checks.

A retrieved note saying “keep explanations brief” may simply be a relevant match. Its source and conditions must establish whose preference it is, which documents it concerned, and whether it still applies. Treating semantic similarity as instruction priority risks giving a closely matching but outdated preference too much influence.

Vector retrieval, structured records, graphs, and readable files should therefore be compared as different choices. Vector retrieval finds candidates; structured records make fields explicit; graphs represent relationships; files provide a storage and editing format. Files can be indexed, and graph results can enter a conversation. Ranking these as interchangeable alternatives obscures whether the problem is retrieval or updating.

Separate conversation state from information for the next conversation

The LangGraph v0.2 announcement describes checkpoints that save state at execution steps, supporting continuation after an interruption. Its long-term memory announcement describes storing, retrieving, and searching documents across conversations, with namespaces for users and organizations. Resuming interrupted work and carrying knowledge into another task serve different purposes.

The headings and unfinished paragraphs of the current document belong to its working state. They need not become instructions for a different document next month. An explicitly continuing preference, however, may remain useful after this conversation ends. Distinguishing records by purpose as well as duration clarifies what should be loaded.

These four categories are this article's design example, not a requirement for four databases. One store can distinguish them through record types and applicability conditions. A namespace organizes information but does not itself authorize access. The application still needs to check whether the caller may read or change the record.

Summarizing a record makes its omissions important

Sending every conversation into every request can appear to avoid selection work. Yet more input places current conditions alongside older instructions. Reducing that input through summarization introduces another question: can subjects or time limits be dropped without changing the meaning?

Research on processing memory reaches beyond adding retrieval. Generative Agents synthesizes higher-level reflections from experience to support planning; its evaluation concerns believable behavior in a simulated environment, rather than business record correctness. MemGPT examines moving information between memory tiers inside and outside limited context, using document analysis and multi-session conversation tasks.

The distinction I draw from these approaches is between preserving a record and producing information for the model to use. Keeping the original statement for verification and a summary for use allows an incorrect summary to be checked against its source. This adds storage and processing, however. A short, one-off consultation may be simpler to handle with the current conversation alone.

Compressing the opening preference into “prefers brief explanations” could lose its document type or exceptions. “Keep routine progress reports brief, but explain background in material for new employees” provides more information for applicability. This is a hypothetical illustration of how retained conditions affect a decision, not a measured summarization result.

Graphs and files address different updating needs

A-MEM proposes attributed memory notes, links between related memories, and updates to existing memories as new information arrives. The Zep paper describes integrating conversation and business information in a temporal knowledge graph. Both examine organizing relationships between records in addition to retrieving stored entries.

Relationships and time information can help distinguish changes of account owner or earlier and current conditions. Incorrectly extracted entities or relationships can still produce an incorrect decision even in a well-organized graph. Compare the work of creating, correcting, and invalidating relationships with reading original records. Different models, tasks, and baselines prevent a universal ranking from these papers.

Letta Code's Context Repositories announcement presents another property: local memory files, Git versioning, and progressive loading of content. Readable changes can matter when people need to inspect which guidance was edited. Git history nevertheless cannot establish that the revised content is true.

Tracing customer-contract relationships and correcting development conventions may therefore prioritize different affordances. The former may need relationships and effective times; the latter may need inspectable diffs. Starting with who corrects what helps choose the necessary complexity before choosing a format.

Do not let an old summary overwrite a correction

“Make this document detailed” and “make detailed explanations my default from now on” change different scopes. Inferring a lasting preference from a single request could make the next short report unnecessarily long. Treating a lasting correction as temporary makes the user repeat it tomorrow.

I recommend separating candidate memories extracted from statements from records applied to future work. Preserve the original statement and subject in the candidate, and promote information when its continuing intent is established. Apply an explicit correction to the active task immediately, without waiting for long-term memory processing. Later consolidation must not reverse it with an older conversation summary.

A summary produced tonight from yesterday's conversation has today's storage time, but its contents precede a correction received this morning. Ranking facts by storage time alone lets delayed processing of an older preference win. This is why statement time, effective time, and storage time should be distinguished.

Whether to erase the previous record also depends on its purpose. Current suggestions may use the new preference while an explanation of the change still needs the earlier statement. Separating exclusion from active retrieval and deletion of history avoids conflating those requirements.

Define read access and write access separately for shared memory

Letta's technical explanation of memory blocks describes blocks shared by multiple agents and distinguishes agent-editable content from read-only content. This supports designs that align the information agents consult without granting every participant the same update rights. Sharing information does not establish that concurrent updates preserve its meaning.

Consider researcher A correcting a deadline while researcher B adds an owner to an older copy and saves the whole note. In an implementation that replaces the entire record with the later save, A's correction disappears. This is a hypothetical consequence of that write model, not a claim that a particular product always behaves this way. Better retrieval cannot read back a correction lost at storage time.

Targeted field edits, version checks before saving, and a designated owner for full rewrites each impose different costs. Even separately stored fields can require joint review when a deadline and an approval condition are related. A single owner simplifies coordination but can add waiting. Compare which updates may run together and where people or other processes resolve conflicts, alongside retrieval performance.

Make forgetting something the user can verify

As memory becomes more useful, users need to understand what remains and what influenced an answer. ChatGPT's memory announcement describes inspecting, deleting, and disabling memory, explaining that deleting a conversation does not delete separately saved memories. This provides a product example of treating conversation history and durable memory as distinct objects.

An application needs to decide what a request to forget covers: stop using a record, remove a saved preference, delete the original conversation, or remove information from shared records. These operations differ. Recreating a deleted summary from a retained old conversation could restore memory against the user's intention. Check the deletion target and the conditions preventing later consolidation from reusing it.

Work that requires history need not mix formal records with personal preferences. Defining correction and deletion rights for each information type creates options for preserving work records while giving users control. Assuming that more retained information always means more usefulness cannot settle that choice.

Evaluate memory beyond retrieval accuracy

LoCoMo includes conversations averaging 600 turns and spanning up to 32 sessions, evaluating question answering, event summarization, and multimodal dialogue. It examines information separated across a long conversation. This cautions against inferring sustained conversational quality from a short, isolated query.

LongMemEval v2 uses 500 questions and separates extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention. I use these categories to distinguish answering an old fact from avoiding it after a correction. They do not establish a best memory method for a particular business task.

For the writing assistant, separate a query about the previous preference, a one-off detailed request, a lasting correction, and a preference never stated. Add concurrent updates for shared notes and reuse after deletion for forgetting. Inspect candidate memories, accepted records, retrieved content, and applied conditions alongside the answer to locate the failed stage.

Costs extend beyond the input used to answer. Include extraction, summarization, relationship generation, update checks, deletion propagation, and people's time correcting records. With the same task and model, compare conversation-only handling, added retrieval, and added updating or sharing rules. This can reveal which additional processing actually addresses the failure.

Build memory that helps with the next task

When the user returns tomorrow, the assistant should remember the previous preference while following the current explicit request. A changed preference should remain corrected, and an unstated condition can be clarified by asking. Supporting this interaction requires both finding relevant records and keeping them fit to apply.

Before choosing a memory method, I recommend identifying whether the failure is missed retrieval, stale applicability, incorrect storage, a lost update, or reuse after deletion. Distinguish working state, continuing preferences, formal rules, and shared records accordingly, then add the required retrieval, updating, and forgetting processes. The aim is for users to avoid repeating the same explanation while having changed decisions treated as changed.