What 'Memory' in an AI Assistant Really Means
Remembering a preference across sessions usually means a stored note that gets added to the context. It is useful, and it has rules worth understanding.

On this page
When an assistant seems to remember that you prefer short answers, something specific is happening. The model itself does not carry that preference from one conversation to the next. A product has stored a note or a summary and placed it into the context of later conversations. The mechanism is simple, and it has consequences for accuracy, privacy and control that are worth understanding before you rely on it.
What the model itself keeps
A language model does not update itself as it talks with you. Its weights stay the same during a conversation. Whatever it appears to know about you has to be present in the text it is given at the moment it answers. Within one conversation, that text is the conversation history. Across conversations, it has to be supplied by the surrounding system.
Hold on to that point. Memory is a process of building the input, not a property of the model. Once you see it that way, most of the behavior you observe becomes easier to predict.
It also helps to separate what is stored from what is shown. A product can keep a fuller record of your conversations for its own purposes while only a small part reaches the model. Which part reaches the model determines how the assistant behaves, and that is rarely visible in the interface.
Common designs
Products tend to use one or more of three designs. Stored notes are short statements, such as a stated preference or the name of a project, saved when the system judges them useful and added to future prompts. Summaries are compressed records of earlier conversations, rewritten at intervals. Retrieval indexes earlier conversations or documents and pulls the most relevant fragments into the prompt for a given request.
Each design keeps different things. Notes keep little and are easy to review. Summaries keep the gist and lose detail, and each rewrite can drop something that mattered. Retrieval keeps more, but it depends on the search finding the right fragment at the right time. Which design a product uses, and the rules for what it saves, are details to look up in its documentation rather than assume.
The designs also differ in when they cost you. Stored notes sit in every prompt, which adds weight to each request and can crowd out the content that matters. Retrieval adds only what seems relevant, but a relevant memory can be missed, and then the assistant behaves as if nothing was ever said. Both trade-offs show up in how the assistant behaves, which is one reason to test memory deliberately.
Where it goes wrong
Stored facts go stale. A preference stated last year may no longer apply, and a project name may have changed. A note can also be saved too broadly. A single complaint about one answer can become a general rule that then applies everywhere. A summary can introduce errors when it compresses a nuance into a flat statement. When several notes conflict, the assistant may use whichever one is most similar to the current request, which is not necessarily the most recent.
These failures look like personality rather than error, which is why they are easy to miss. The answer is oddly shaped, and it takes a moment to notice that the shape came from a stored line rather than from the question.
A related problem is confidence. An assistant may say it remembers something that is not in the context it is actually using, or describe a memory in more detail than the stored note contains. Treat a claim of remembering as something to check, not as evidence that the stored item exists in the form described.
Privacy and control
Memory is personal data by design. Find out where memories are stored, who can see them, how long they persist, whether they are used beyond your own sessions, and whether you can turn the feature off. Check whether conversations or memories are used to improve models, and find the setting that controls that. Wording differs between products and changes over time, so the current policy and settings page is the authority, not a summary from memory. Read the retention statement with the same care you give the feature list, since the two often differ in what they promise.
Do not store secrets, credentials or other people's personal information in any memory feature, even when the interface permits it. A memory is a copy, and copies outlive the context in which they were made. Memory tied to an account can also surface in places you did not expect. A shared computer, a shared workspace or a family login can expose stored items to people who never saw the original conversations. Check who else can open the account before deciding what belongs in it.
Practice: audit a memory store
If an assistant you use has a memory feature, open it and list each stored item. For each one, decide three things. Is it still true? Is it needed? Could it cause harm if it were applied in the wrong context? Delete anything stale or unneeded.
Then test one preference. Start a fresh conversation and ask a question where the preference should matter, and check whether the answer uses it as you intended. If the product offers no way to see what is stored, write that down as a finding about its control. A memory system you cannot inspect is one you cannot correct, and that is worth knowing before you depend on it.

