Giving an agent memory without giving it amnesia
Since models retain nothing between calls, memory is something the application constructs. Useful systems separate short-term working context from durable facts worth storing, write memories deliberately rather than automatically, and make what is remembered visible and correctable by the user.
Because a model starts each request empty, anything resembling memory is built by you. Which means "should it remember this?" is not a technical question with a default answer. It is a design decision, made repeatedly.
Two different things called memory
Working memory is the context of the task in progress — what has been tried, what came back, where we are. It is large, detailed and disposable when the task ends.
Durable memory is the small set of facts worth carrying into a conversation next month: a preference, a constraint, a decision that was made and should not be relitigated. It should be short enough to read.
Conflating them produces the two classic failures — an assistant that forgets what you said two turns ago, or one that opens every conversation by reciting your history.
Write sparingly
The instinct is to save everything and sort it out at retrieval. In practice a memory store grows into noise quickly, and retrieval starts surfacing the incidental over the important. Extracting a handful of durable statements per conversation beats indexing the transcript.
Retrieve by relevance
Even a good memory store should not be loaded wholesale into every request. Retrieve what relates to the current turn, the same way you would retrieve documents.
Injecting fifty stored facts to answer a question that needed one is the context-dilution problem again, arriving through a different door.
Make it visible
An assistant that has quietly formed beliefs about a user, with no way to inspect or correct them, is unsettling when it is right and infuriating when it is wrong.
A plain list of what is stored, with a delete control, turns a black box into a feature people trust. It is also the honest answer to the privacy question your first enterprise customer will ask.
Let things expire
Timestamp everything. Prefer recent facts when two conflict. Let some categories age out entirely — a project context from eight months ago is usually noise, not history.
Forgetting is part of the design, not a failure of it.
Frequently asked questions
Should I just save every conversation and retrieve from it?
It is the obvious design and it disappoints. Raw transcripts retrieve badly — they are long, repetitive and mostly incidental. Extracting a small number of durable statements works much better than indexing everything.
How do I stop memory going stale?
Timestamp every entry, prefer recent statements on conflict, and let a new fact supersede an old one explicitly. A preference from a year ago should not outrank one from this morning.
