Should your AI agent remember users between sessions?

Usually not. Memory is sold as an upgrade and mostly buys you a privacy surface, a staleness problem, and a system that confidently repeats something a user corrected months ago. It is worth it when continuity is genuinely the product, and that is a smaller set of cases than the market implies.

JarvisBitz

Memory is the feature everyone asks for after the first demo. The assistant should remember me, remember my preferences, remember what we discussed last week. It sounds obviously good, it is sold as the difference between a tool and an assistant, and it is mostly a liability.

Worth noticing who is answering this question in public. A large share of the material recommending persistent memory is published by companies selling memory infrastructure, which does not make it wrong and does mean the contrarian case is under-written.

What memory actually costs

It changes your privacy surface. A system that holds nothing between sessions is a fundamentally simpler thing to explain, to secure and to delete from. The moment it retains, you have a store of personal information with a retention question, a deletion path, an access control model, and a residency answer, which we cover in data residency. None of that is hard. All of it is work nobody scoped.

It goes stale, confidently. A preference recorded in March is asserted in November as though it were current. Users change their minds, circumstances change, and a memory system has no mechanism for noticing. The failure is specific and irritating: the assistant confidently repeats something the user corrected months ago, which reads as not listening rather than as remembering.

It accumulates contradictions. Long lived memory ends up holding things that cannot all be true, and nothing arbitrates. The system then answers from whichever fragment retrieval surfaced, which makes behaviour non reproducible: the same question gets different answers on different days for reasons nobody can reconstruct.

It costs tokens on every turn, since retrieved memory joins the context on each request whether or not it is relevant.

When it is genuinely worth it

The test is whether continuity is the product or a nicety. Three cases pass it.

• Long horizon work that spans sessions by nature. A research assistant building understanding over weeks, a tutor tracking what a learner has covered. Here the memory is the value and removing it removes the product.
• Expensive to re-establish context. If every session begins with the user restating their situation for five minutes, memory buys back real time and users will notice its absence immediately.
• Genuine personalisation with a feedback loop, where preferences are confirmed rather than inferred, and there is a way to correct them.

Most support assistants, internal search tools and document systems fail all three. The task is complete within a session, and what feels like memory is usually just the session context working correctly.

The middle option most teams should take

The choice is not between amnesia and an accumulating profile. Between them sits explicit, scoped memory, which gets most of the benefit and few of the costs.

• Remember facts, not conversations. A small structured record of confirmed preferences beats a growing pile of past transcripts, because it is inspectable, editable and boring.
• Make it visible and correctable. Users should be able to see what is held and change it. This converts staleness from a silent failure into a thing someone can fix, and it makes the deletion story trivial.
• Record confirmations, not inferences. Store that a user chose something, not that the system concluded they prefer it. Inferred preferences are where the confidently wrong behaviour comes from.
• Expire it. Something not reconfirmed within a period should stop being asserted. Almost nobody implements this and it prevents the most common failure.
• Scope it per surface. Memory from a support conversation appearing in a sales one is a surprise nobody wants.

What users usually mean when they ask for it

Worth separating, because the request and the requirement are frequently different things.

When people say they want the assistant to remember them, they often mean one of three narrower things. They want it to stop asking for information the business already holds, which is a systems integration problem rather than a memory one: the account, the order history and the entitlement are in your systems and should be retrieved per session.

Or they want continuity within a task that spans a few days, which a scoped conversation or case identifier handles without a general memory store. Or they are describing an experience rather than a mechanism, having found the assistant repetitive, which is usually a prompt problem.

All three are cheaper and safer than persistent memory, and all three are what actually gets built when someone asks the follow up question. Ask it before scoping the store.

How to decide in an afternoon

• Look at real sessions and count how often a user restates something the system could have known. If it is rare, you have your answer.
• Ask what happens when a remembered fact is wrong, and who fixes it. If there is no mechanism, do not build the memory yet.
• Ask what you would have to delete on request, and whether you can currently find it.
• If you proceed, start with a handful of explicit fields rather than general recall, and add more only when the absence of something is a real complaint rather than an imagined one.

This is the same instinct as preferring workflows to agents: take the constrained version until the unconstrained one is demonstrably needed, because the constrained version is the one you can debug, explain and delete from.

If you are being sold persistent memory as a default and want a read on whether your sessions actually need it, our free AI audit covers it, and how we build agent systems covers the scoped version when the answer is yes.

Related reading

A2A explained: when AI agents need to talk to each other

Most businesses do not need it yet. A2A standardises how agents built by different teams or vendors delegate work to each other, which only starts to matter once you have more than one agent and the other one is not yours to change.

Prompt injection: why filters fail and what actually works

Not with filters. A model cannot tell where an instruction came from, so any defence that tries to spot a malicious one will eventually be talked past. What holds is constraining what the agent is able to do after it reads untrusted content, which is an architecture decision rather than a prompt.

Where human approval actually belongs in an AI agent

In front of actions that cannot be undone, or that reach further than a blast radius you have deliberately chosen. Gating everything is close to gating nothing, because a control that fires constantly stops being read. The design work is deciding which actions qualify, then shrinking permissions so the list stays short.