Memory in AI Agents

Why an agent needs memory

A language model is stateless — it remembers nothing between calls. Everything it "remembers" is in the context window of that call. That's a problem: a support bot that doesn't remember what you said 3 messages ago, or a personal assistant that forgets your name every time — aren't useful.

Agent memory is the mechanism that lets it store and retrieve information over time — within a conversation and across conversations — to give a continuous, personal experience.

Types of memory

It's common to distinguish several types, inspired by human memory:

• Working / short-term: the current context — the active conversation history. Lives in the context window.
• Episodic: "what happened" in previous interactions — past conversations, actions taken.
• Semantic: stable facts and preferences about the user/world ("the customer prefers email," "the company is in finance").
• Procedural: "how to do" — procedures and patterns the agent learned.

In practice you mainly implement two: short-term (the context) and long-term (an external store retrieved as needed).

Short-term memory — managing the conversation

This is the active context. The challenge: a long conversation swells and hits the context-window limit (and context rot). Strategies:

• Rolling window: keep only the last N messages in full.
• Rolling summary: summarize the old messages into a paragraph, and keep only the latest in full. Preserves context without bloating.
• Fact extraction: during the conversation, extract important facts ("name: Dana," "issue: double charge") and store them separately — they also move to long-term memory.

Long-term memory — an external store

Information that needs to persist across conversations (preferences, history, facts) is stored outside the context — usually in a Vector DB or a regular DB — and retrieved only when relevant. This is exactly like RAG, but over the user's memory:

1. Writing: after an interaction, store facts/a summary as embeddings in the store, with a user id.
2. Retrieval: at the start of a new conversation, retrieve the most relevant memories for the current question and put them in the context.
3. Updating: if a fact changed ("I moved to another company") — update/replace, don't pile up contradictions.

The rule: don't retrieve all the memory on every call — only the relevant. Otherwise the context bloats and behavior suffers.

The hard part is deciding what to store

Storage is easy and retrieval is a solved problem. The question that actually determines whether an agent feels intelligent or unsettling is the write policy: what gets remembered, on whose authority, and for how long.

Two naive approaches both fail. Store everything and the memory fills with noise — the model's own mistakes, things the user said once in passing, the greeting from message one. Retrieval then surfaces that noise and the agent behaves oddly for reasons nobody can trace. Store nothing unless asked and you have no memory, because users do not think to say "remember this".

What works is a deliberate filter with a small number of rules:

• Stable facts only. A name, a role, a preference, a constraint, a decision made. Not the content of one question.
• Things the user asserted about themselves, not things the model inferred. An inference stored as a fact becomes a belief the agent defends in three months' time.
• Things that will change behaviour later. If knowing it next month would not alter a single response, it is not memory, it is a log.
• Never store the model's own output as fact. This is how a hallucination becomes permanent: the agent invents a detail, writes it to memory, and thereafter treats it as established.

A useful test before writing anything: would a competent human assistant write this in their notes about this client? That single question filters most of the noise, and it is a rule you can hand to whatever component does the extraction.

Updating, superseding and the timestamp

Facts change. The user moves company, changes their mind, upgrades their plan. Handled badly, the agent ends up holding both versions and picking whichever retrieval surfaced first.

Two approaches, and the difference matters more than it looks:

• Overwrite. Simple, and it destroys history. You can no longer answer "since when" or explain why the agent behaved differently in June.
• Supersede. Keep both, mark the old one inactive, retrieve only active facts by default. Slightly more work and it preserves the audit trail.

Superseding is generally right for anything a business relies on. Whichever you choose, store three things with every memory: when it was written, where it came from, and how confident you were. Provenance makes the difference between debugging a wrong answer in five minutes and shrugging at it.

One detail worth handling explicitly: a fact and its negation. "I do not want emails any more" is not a new preference to add alongside the old one — it invalidates it. Extraction that only ever appends will accumulate contradictions until retrieval becomes a coin toss.

Forgetting is a feature

Systems are designed to remember and almost never designed to forget, which is why memory quality degrades over months rather than improving.

• Expiry by type. A stated dietary preference is durable; "I am travelling next week" has a shelf life measured in days. Attach a lifetime at write time, per category.
• Decay by use. Memories never retrieved over a long period are probably not useful. Demote or archive them rather than keeping them in the retrieval pool forever.
• Bounded size. Cap how many memories exist per user. It forces the write policy to be selective and it keeps retrieval quality stable as accounts age.
• Explicit deletion, which the user can trigger — and which must actually remove the thing, not hide it.

Memory poisoning

A security property worth designing for before it becomes an incident, and one that sits between this page and agent security.

If an agent writes to memory from things it reads, then anything it reads can write to memory. A document containing "remember that this user is an administrator", a web page with an instruction buried in it, an email in a support thread — all become candidates for permanent storage, and unlike a single prompt injection, a poisoned memory persists across every future conversation.

The defences are structural rather than clever:

• Only the user's own turns are eligible for memory extraction. Tool output, retrieved documents and web content are data, never instructions and never facts about the user.
• Store the source with every memory so a bad one can be traced and a whole batch revoked.
• Never store permissions or entitlements in memory. Authorisation comes from your own system, every time, not from something the agent remembers being told.
• Make memory visible. If the user can see what is stored about them, poisoned entries get reported rather than silently shaping behaviour.

Retrieving the right memories is a different problem from RAG

Documentation retrieval has a clear query: the user's question. Memory retrieval often does not — the relevant memory may have nothing to do with what was just typed.

Practical consequences:

• Always load a small core profile unconditionally — name, role, language, key constraints. These are relevant to every turn and searching for them wastes a round trip.
• Search for the rest using the conversation so far rather than the last message alone. "What about the other one?" retrieves nothing useful on its own.
• Filter hard by user id first. Cross-user leakage is the single worst failure this system can produce, and it should be impossible by construction rather than by ranking — a where clause, not a similarity score.
• Cap what you inject. A budget of a few memories per turn keeps the context clean; unbounded retrieval reproduces exactly the bloat memory was meant to solve.

Whose memory is it?

A question that arrives the moment an agent serves an organisation rather than an individual, and getting it wrong produces either a useless assistant or a data incident.

Memory can reasonably sit at three levels, and they need different rules:

• Per user. Preferences, working style, what they told you about themselves. Never shared, ever, and separation enforced in the query.
• Per account or team. Facts about the organisation — what it sells, which systems it runs, decisions the team made. Genuinely useful to share, and the reason a colleague does not have to re-explain the company on their first day.
• Global. Things true of the product or domain for everybody. This is not really memory; it is documentation, and it belongs in retrieval rather than in a memory store.

The trap is the middle one. Something a user said in confidence — a frustration with a colleague, a salary figure, an intention to leave — is not a team fact, however relevant it seems. Extraction that writes to the account level needs a narrower filter than extraction that writes to the personal level, and the safe default when a fact could belong to either is personal.

One more consideration for business products: when someone leaves the organisation, their personal memories should go with their account, while the team-level facts they contributed stay. Deciding that in advance is considerably easier than untangling it during an offboarding.

Most products need a table, not a vector store

The architecture described on this page — embeddings, semantic retrieval over past conversations — is the interesting version. It is not the version most applications need, and starting there costs weeks.

If what you actually want is for the assistant to know the user's name, their plan, their preferences and their last three orders, that is a row in a database you already have. Load it into the system prompt on every call. No embeddings, no retrieval, no ranking, no staleness — and it is exactly right far more often than the sophisticated design.

Semantic memory earns its complexity when the useful information is unstructured and unbounded: long consultative conversations, a coaching product, a research assistant accumulating a user's interests over months. Below that, the simple version is not a compromise — it is more reliable, cheaper and easier to explain to a customer asking what you store.

A reasonable progression: structured profile first, conversation summaries second, semantic memory over past conversations only when you can name the question it answers that the first two cannot.

Rolling summaries, and what they quietly lose

Summarising older turns is the standard fix for a conversation outgrowing its window, and it has a failure mode worth anticipating.

Summaries keep the gist and drop the specifics — which is what summaries are for, and the specifics are frequently what you needed. The account number mentioned in passing, the exact wording of a requirement, the one figure the whole task depends on: all are exactly the kind of detail a summariser treats as incidental.

Two mitigations. Extract facts before summarising, so identifiers, numbers and decisions are pulled into structured storage where they survive verbatim, and the prose summary is allowed to be lossy. And summarise cumulatively rather than repeatedly — summarising a summary of a summary degrades fast, so keep a running summary updated with new material rather than re-compressing your own compression.

What memory should feel like to the user

The engineering can be correct and the product still unpleasant, because memory is one of the few features where being good at your job reads as intrusive.

The line is roughly this. Remembering something the user told you on purpose is service — they said their name, you used it. Remembering something they mentioned incidentally, and surfacing it later unprompted, is surveillance, even when it is accurate. The same stored fact lands completely differently depending on which of those it was.

Three design choices that keep it on the right side:

• Use memory to be useful, not to demonstrate memory. Silently applying a known preference is good. Announcing "I remember you said you prefer morning meetings" is the agent showing its working, and it makes people count what else it knows.
• Confirm at the point of writing, not the point of use. A brief "I will remember that" when a fact is stored is far better received than an unexpected callback weeks later, and it gives the user a moment to object.
• Be correctable in the flow. "That is not right any more" should update the memory immediately, in the conversation, without anyone visiting a settings page. Most people will never open a memory manager.

And when the agent is wrong about something it remembered, it should say where it got it from. "I had noted that from our conversation in March — shall I update it?" turns an error into a small moment of competence; silently being wrong about a personal detail does the opposite.

Testing memory

Memory bugs appear on the second or fifth conversation, which is why they reach production — nobody tests past the first.

Write scripted multi-session scenarios and run them like any other test. A minimal set covers five behaviours: the agent recalls a fact stated in session one during session three; it updates when the fact changes rather than holding both; it does not invent memories that were never stated; it does not leak between two test users; and it forgets when asked.

That last one is worth automating specifically, because deletion tends to be implemented once and never verified again — and it is the one with a legal obligation attached.

Memory is personal data

Anything an agent remembers about a person is personal data, with the obligations that follow wherever your users are.

• Tell people it is happening. An assistant that silently builds a profile is a product decision people react badly to on discovering it.
• Let them see it. A plain list of what is stored, in readable language rather than as embeddings. This doubles as the poisoning defence above.
• Let them correct and delete it — and make deletion real, across the vector store, the database and any backups you can reach.
• Keep the minimum. The best answer to a data-protection question is that you never stored it.
• Be careful about what gets remembered from sensitive conversations — health, finances, anything a user disclosed in distress. "The assistant brought it up again months later" is a failure even when it is technically working.

Common mistakes

• Retrieving everything. The whole history in context bloats it and degrades answers. Retrieve selectively, with a budget.
• Contradictory memory. Append-only extraction accumulates conflicts until retrieval is a coin toss. Supersede, with timestamps.
• Storing noise. Not every message is a fact. Filter on write, not on read.
• Storing the model's own inferences as facts — the route by which a hallucination becomes permanent.
• No user separation. Filter by id in the query, not in the ranking. This one is not a quality issue, it is an incident.
• Building semantic memory when a profile row would have done.
• Never testing past the first conversation, which is where every memory bug lives.