Memory — long-term

ConceptWhat it is

Long-term memory is what an agent retains after a task ends: preferences, facts about the user, prior decisions, accumulated context that makes the next session start warmer than the last. It is the feature that makes an assistant feel like it knows you.

It is filed here as a security topic rather than an architecture one, and that is the argument of this page. Everything that makes long-term memory valuable makes it dangerous in the same motion: it is durable, it is derived from user content, it is injected into prompts automatically, and it is usually invisible to the person it describes. What persists between sessions is what can leak between users, and the failure is silent — a retrieval scoped one key too wide does not error, it just answers somebody else's question with your data in it.

How it worksThe mechanics

Writing is a decision, not a side effect. Something is promoted to long-term memory when it is durable and reusable — a stated preference, a confirmed fact, a settled decision — and everything else is left in the task. A store that writes on every turn fills with transient noise and then retrieves it confidently later.

Reading is a retrieval scoped to an owner. The scope key is the security boundary and it belongs in the query, never in a filter applied afterwards — a post-filter that is skipped, mis-ordered or short-circuited returns another user's rows, and the surrounding code cannot tell the difference. Records carry provenance so a claim in an answer can be traced to the session that produced it, and they expire, because a preference from a year ago asserted as current is its own kind of wrong.

The part most often skipped is the human one: the user can see what is stored, correct it, and delete it. That is a legal requirement under several regimes and it is also the only practical way to find out what the store has quietly got wrong about someone.

At a glanceSee it

The scope key sits inside the query, never in a filter applied afterwards — a post-filter that is skipped returns another user's rows and nothing errors.

When to use itWhere it fits

• When continuity across sessions is genuinely the product, rather than a feature added because it is possible.
• For stable preferences a user would be annoyed to restate — the clearest honest case.
• Where a decision made once should hold, and re-deriving it each session would be both slower and less consistent.
• Only alongside the controls below; the store and the user's access to it ship together, not in that order.

When NOT to use itLimits & anti-patterns

• In any shared or multi-tenant context without a scope key inside the query — the highest-severity mistake on this page.
• For anything sensitive that the task did not require keeping, since storing it creates an obligation that outlives the value.
• As a substitute for retrieval over a corpus; RAG answers what is true, memory answers what is true of this user.
• Writing on every turn, which fills the store with transient noise and then retrieves it as fact.

Trade-offsAdvantages & costs

ExampleIn the real world

An assistant stores user preferences in a vector store and retrieves the nearest matches at the start of each session. The scope key is applied as a filter after the similarity search rather than as a condition inside it. For most users nothing happens, because their own records are the nearest anyway. For a new user with almost no records, the nearest neighbours are somebody else's — and the assistant opens the session by referring to a project that belongs to another customer. Every test passed, because the tests were written by users who already had records.

ToolsHow to implement it

• The scope key inside the querythe security boundary, never a filter applied afterwards.
• A write policypromote durable facts at task end, not everything on every turn.
• Expiry and provenance on every recordso a claim can be dated and traced to its session.
• A user-facing view with correct and deletea legal requirement in several regimes and the only way to find what the store got wrong.

Cost & effortWhat it takes

Storage is small; the retrieval is one lookup per session and rounds to nothing against the generation it precedes. The real cost is obligation. A durable store of user data brings deletion requests, residency questions, breach exposure and an audit surface, none of which appear in a token bill and all of which arrive later. Budget it as a data-protection commitment rather than as an infrastructure line, and store only what the product genuinely needs to keep.

RelatedGo deeper