How Do Personal AI Assistants Use Memory?

What does a personal assistant need to remember?

Three categories carry almost all the value: stable facts about the person, the history of what has already been discussed or done, and the working preferences that shape how output should look. Everything else that gets stored is usually noise competing with these for retrieval.

Stable facts are the ones users are most annoyed to repeat. Dietary requirements, the names of family members, the city they live in, their role, the tools they use, their working hours. These change rarely, apply broadly, and are cheap to store, which makes them the highest return per memory in the entire system.

History is what makes a follow-up possible. Which task was in progress, what was decided last week, what the assistant already suggested and the person rejected. Without it, an assistant restarts every conversation with the same suggestions, which reads as not listening rather than as forgetting.

Working preferences govern the shape of a response rather than its content. Short answers rather than long ones, bullet points rather than prose, being asked before an action is taken rather than after. These are procedural rather than factual, and they are the category most systems fail to store because they arrive as corrections rather than statements.

A fourth category is worth naming so it can be deliberately excluded. Passing remarks, one-off moods and small talk are the bulk of any conversation and almost never worth storing. An assistant that remembers everything said to it retrieves badly, because the useful memories are competing with hundreds of trivial ones.

Those categories map onto distinct memory types, and the mapping decides the architecture: which memory types a personal assistant needs.

Is there an AI assistant that can remember you?

Yes. Persistent memory is now a standard feature in mainstream consumer assistants, and it works the way this site describes: a filtered set of facts is extracted from conversations, stored outside the model, and retrieved into later sessions. It is not the model remembering; it is a system around the model.

Two things about those products surprise people, and both follow from the mechanism. They remember less than users assume, because extraction discards most of a conversation by design. And what they remember is editable, since each memory is a record rather than a change to the model, which is why these products can show a list of what they know and let you delete an entry.

For anyone evaluating rather than building, the useful questions are not about model quality. Ask whether memories persist across devices and sessions, whether you can see and edit them, whether the assistant tells you when it stores something, and what happens to the memories if you stop using the product. Those four answers separate a genuine memory feature from a longer context window described as one.

For anyone building, the more important observation is that consumer expectations are now set by those products. A new assistant that forgets a stated preference is measured against tools that do not, which moves memory from a differentiator to a baseline requirement.

The comparison against a bigger context window, which is the other thing marketed as memory, is on long context versus memory.

Building it starts at the write path, which is where most of the quality is decided: how an assistant decides what to remember.

How does an assistant retrieve the right memory?

It embeds the incoming question, searches the store scoped to that person, ranks candidates on recency, importance and relevance, and injects only the top few into the prompt. The number injected is a real design parameter and smaller is usually better.

The canonical scoring comes from the Generative Agents paper (Park et al., 2023), which sums recency, importance and relevance with each weight set to 1.0 and decays recency exponentially at 0.995 per hour since the memory was last accessed. For a personal assistant the importance signal matters more than in most applications, because a stated dietary requirement should outrank a topically similar restaurant mentioned once.

One retrieval decision is specific to this product shape. A small set of core facts is relevant to almost every conversation: name, working style, key constraints. Many assistants always inject those cheaply, and run the full search only when the query looks historical. That keeps the always-relevant facts present without paying for a full retrieval on every trivial turn.

The failure to watch for is retrieving too much. Every injected memory occupies prompt space and adds a chance of the answer anchoring on the wrong detail, which is the effect Liu et al. documented in “Lost in the Middle” (arXiv:2307.03172). Three well-ranked memories generally beat twelve. The mechanism is on memory retrieval.

Retrieval is also where a personal assistant can go wrong in a way no other product can: the line between helpful and unsettling.

How do you handle facts that change about a person?

Mark the old fact superseded rather than deleting it, and rank a direct statement above an inference when the two disagree. A personal assistant accumulates facts about a life, and lives change, so this is not an edge case but the normal condition of the store.

The categories that change most are predictable: where someone lives, what they do, who they work with, what they are currently focused on. Those deserve shorter retention or explicit revalidation, while genuinely stable facts such as a dietary requirement or a family relationship can be held indefinitely.

Keeping the superseded version rather than overwriting it buys two things. The assistant can answer questions about the past, which people do ask. And a correction made in error is reversible, which matters because extraction is imperfect and a misheard statement should not permanently overwrite something true.

Where the ranking cannot separate two versions, asking is better than guessing. “You mentioned Berlin in March and Munich last week, which should I use?” is specific, shows the evidence, and takes a moment to answer. Silently picking one and being wrong is the option users find hardest to forgive. The full procedure is on handling conflicting and stale memories.

Change also means the store grows, which raises the operational question: what assistant memory costs to run.

How does an assistant build memory from nothing?

Slowly, and the first two weeks are the period most likely to lose a user, because an assistant with an empty store is strictly worse than one without memory: it has all the cost and none of the benefit. Designing for that window matters more than optimising the steady state.

Three approaches are used, and they combine well. Ask directly, once. A short onboarding that captures the handful of facts that apply to almost every conversation, meaning name, role, working style and any hard constraints, seeds the store with exactly the memories that will be retrieved most often. It feels like setup rather than surveillance because the user is choosing what to share.

Import what already exists. Where a user already has data in a connected system, a calendar, a task list, a profile, the durable facts in it are better seeds than anything inferred from early conversations. This has to be scoped and consented explicitly, but it converts a cold start into a warm one.

Extract aggressively at first, then taper. A store with ten memories can afford a lower bar for what counts as durable than a store with ten thousand, because there is nothing yet for a marginal memory to compete with. Tightening the extraction threshold as the store grows keeps early usefulness without producing long-term noise.

The failure to avoid is announcing memory before it has anything to remember. An assistant that says it will learn your preferences and then demonstrably has not, three sessions later, has spent credibility it did not have. Under-promising during the cold start and letting the behaviour speak once the store fills is the pattern that works.

Where those memories physically live is the other decision specific to personal products: on device or in the cloud.

How do you let users see and control their memories?

Show the list, allow editing and deletion, and make the scope identifier a first-class field from the very first record. This is both a product feature and a compliance requirement, and retrofitting it is painful.

The technical prerequisite is scope. Every memory needs a user identifier attached at write time and applied as a filter during search rather than after it. A store built without that cannot answer “show me everything you hold about this person”, cannot delete it reliably, and cannot guarantee that one person’s memories never reach another’s prompt. Adding the field later means rewriting every row.

The product surface that follows is straightforward and unusually well received. A list of stored memories, each editable and deletable, with an indication of when it was learned. Users who can inspect what an assistant knows are markedly more forgiving of it being occasionally wrong than users who cannot, because a visible error is a correctable one rather than evidence that the system is unreliable.

Two smaller behaviours help disproportionately. Telling the user when something is stored, lightly rather than intrusively, converts memory from something that happens to them into something they participate in. And honouring a deletion completely, including any summaries derived from the deleted memory, avoids the situation where a fact was removed and its shadow keeps influencing answers.

The storage requirements that make all of this possible are covered on the infrastructure cluster, and the scoping detail on the memory layer.

Finally, none of this can be assumed to work without measurement: how to evaluate a personal assistant’s memory.

Frequently asked questions

The questions that follow: how much an assistant should store, and what happens to memories across devices.