What is AI agent memory?

Three Types, Three Layers

Session memory is the most familiar kind. It's what lets an agent remember what was said earlier in a conversation, or recall the context of a previous session. Without it, every exchange starts from scratch — the agent has no awareness of what you asked yesterday, what you decided last week, or that the conversation even happened. Most modern agent frameworks include some form of session memory. It's a solved problem for basic use cases, though it gets harder to manage reliably as conversations grow long or span multiple sessions.

Retrieved context is what RAG (retrieval-augmented generation) provides. Before the agent responds, the system searches a document corpus and surfaces relevant content — a policy document, a product spec, a support article — to include in the agent's context window. The agent doesn't 'remember' this content in any persistent sense; it's fetched at the moment it's needed. Retrieved context is genuinely useful for anything that exists as a document. The constraint is also its definition: it can only retrieve what's been written down and indexed.

Organisational memory is the layer that's almost entirely unsolved in current tooling. It's the reasoning behind why legal prohibited autonomous outbound emailing, or why a market segment was quietly deprioritised, or why pricing rules changed three months ago. That knowledge exists — but it exists in people, not documents. And in most organisations, most of it was never formally captured anywhere.

Why the Distinction Matters in Practice

The failure mode that follows from conflating these three types is predictable. An organisation deploys agents, implements RAG over its documentation, and considers the memory problem solved. The agents can recall prior conversations and retrieve relevant documents. But they have no idea what the organisation is actually trying to achieve, what constraints they're operating under, or what decisions were made two months ago that changed the direction.

The results look like competence failures but are actually context failures. The agent produces outputs that are technically correct but wrong in ways that are difficult to articulate — because articulating what went wrong requires the context the agent was never given.

Session memory and retrieved context are well-served by existing tools. Organisational memory is not, for a structural reason: most of it isn't in a document. The reasoning behind a constraint, the trade-off accepted in a product decision, the goal that shifted last quarter — this knowledge lives in people, in conversations, in the reasoning that drove decisions that eventually stopped being discussed because everyone assumed they were understood. RAG can't retrieve what was never written. Session memory doesn't persist it. Neither is designed to.

What Organisational Memory Requires

Solving organisational memory is a different kind of problem from the other two. It can't be automated from existing sources, because the sources don't contain it. It requires deliberate authorship: someone — a human, an agent, or both working together — has to surface the knowledge, give it structure, and record it in a form agents can draw on.

That authorship process is harder than implementing RAG. It's also the reason organisations that invest in it get meaningfully different agent behaviour: agents that start from what the organisation actually knows, not just what it has happened to write down.