Types of AI Agent Memory: Episodic, Semantic, Procedural

What Are the Types of AI Agent Memory?

When people talk about the types of AI agent memory, they are borrowing a vocabulary from cognitive science and applying it to software. The borrowing is useful because a capable agent needs several distinct kinds of memory that behave differently, get stored differently, and get retrieved at different moments. Lumping them together as one big "memory" feature is exactly how teams end up with agents that recall trivia but forget how to do their job, or agents that follow a workflow perfectly but never remember a single thing about the user.

There are three long-term categories worth naming: episodic, semantic, and procedural. On top of those sits a separate axis, working (short-term) memory versus long-term memory, which describes not what is stored but how immediately available it is. The three categories tell you what kind of information you are keeping. The short-term versus long-term axis tells you where it lives right now. Both matter, and this article walks through each with concrete examples and how they show up in real agent code.

Episodic Memory: Remembering What Happened

Episodic memory is the record of specific events and experiences: what happened, when, and in what order. For a human it is remembering yesterday's meeting. For an agent it is the log of past interactions: the user asked about their invoice on July 2, the agent looked it up, the user said the amount was wrong, the agent filed a correction.

Episodic memory is inherently tied to a timeline and to particular instances. It answers questions like "what did we decide last week?" and "have I seen this error before?" In practice it is usually stored as a sequence of timestamped entries: a conversation transcript, an event log, or a table of past tool calls and their results. When an agent needs it, the agent either replays recent entries directly or retrieves older ones by similarity, pulling back the two or three past episodes most relevant to the current turn.

The honest limitation is volume. Episodic memory grows without bound, one entry per event, so you cannot keep all of it in the context window. This is why episodic memory almost always pairs with retrieval and summarization: keep everything on durable storage, but fetch only the relevant slices, and compress old episodes into summaries when the raw detail stops earning its space.

Retrieval quality is what makes episodic memory feel intelligent rather than random. A good implementation does not just grab the most recent entries; it embeds the current situation and pulls the past episodes most similar to it, so an agent hitting a database timeout can surface the three previous times it hit that same timeout and what fixed it. Timestamps still matter for ordering and for recency weighting, but similarity is what lets the agent find a relevant event that happened weeks ago and would otherwise be buried under thousands of newer entries.

Semantic Memory: Facts and Knowledge

Semantic memory is general knowledge stripped of the specific event that produced it. You know that Paris is the capital of France, but you do not remember the moment you learned it. For an agent, semantic memory holds durable facts: the user prefers metric units, the company's fiscal year ends in March, the production database is named orders-prod, this customer is on the enterprise plan.

The difference from episodic memory is subtle but important. Episodic memory says "on July 2 the user told me they prefer metric units." Semantic memory says "the user prefers metric units," full stop, with the originating event abstracted away. Many agent memory systems build semantic memory by extracting facts out of episodic logs: a background step reads the conversation, pulls out durable statements, and writes them to a facts store. Tools like Mem0 (github.com/mem0ai/mem0) are built specifically around this extraction step.

Semantic memory is typically stored as embeddings in a vector database so it can be retrieved by meaning rather than exact keywords. A common backing store is pgvector (github.com/pgvector/pgvector), which adds vector similarity search to PostgreSQL. At query time the agent embeds the current question, finds the most similar stored facts, and adds them to context. The tradeoff is staleness: facts change, and a semantic store needs a way to update or supersede old entries, or the agent will confidently repeat something that was true three months ago.

Procedural Memory: Knowing How to Act

Procedural memory is knowledge of how to do things: skills, routines, and workflows. For a human it is riding a bike or touch-typing, actions you perform without narrating each step. For an agent, procedural memory is the encoded know-how that shapes behavior rather than supplying facts: the system prompt, few-shot examples, tool definitions, and learned routines like "to refund an order, first verify the customer, then check the return window, then call the refund API."

Procedural memory is different from the other two because it is often baked into the agent's configuration rather than stored in a database and retrieved per turn. The system prompt is procedural memory. A library of tool schemas is procedural memory. Some advanced agents also learn procedures over time, saving a successful multi-step plan so they can reuse it later instead of re-deriving it, which starts to blur the line into episodic memory of "how I solved this before."

The practical point: when an agent knows the right facts but keeps botching the steps, the gap is usually procedural, and the fix is in prompts, examples, and tool design, not the vector store. Adding more facts to a semantic store will not teach an agent a workflow it does not have, just as reading more recipes does not by itself make someone a faster cook. The two failure modes call for different repairs, and mislabeling one as the other is a common way to spend a week fixing the wrong layer.

Working Memory vs Long-Term Memory

The three categories above describe long-term memory, information kept across turns and sessions. Working memory (also called short-term memory) is a different axis entirely: it is what the agent has immediately available inside the current context window right now.

Working memory is small, fast, and volatile. It is the system prompt, the last several messages, the tool outputs from this turn, and whatever facts you just retrieved. It vanishes when the context window is rebuilt for the next turn unless something writes it to long-term storage. The relationship is a loop: long-term memory (episodic, semantic, procedural) lives in databases and files, and on each turn the agent loads a relevant slice of it into working memory to reason with, then writes any new durable information back out.

Getting that loop right is the heart of context engineering for AI agents, which covers how you decide what to promote from long-term storage into the limited working set each turn. And when working memory is not written back to durable long-term storage correctly, you get the classic symptom where an AI agent forgets everything between sessions: plenty of working memory during a session, nothing kept after it.

Comparing the Types of AI Agent Memory

Here is how the four line up side by side:

The table makes the practical split clear. Working memory is the window. Episodic and semantic memory are data you store and retrieve. Procedural memory is mostly configuration and prompt design. A production agent touches all four on nearly every turn.

How These Map to Real Agent Implementations

In a real system the categories overlap and reinforce each other rather than living in neat boxes. A support agent built on a framework like LangChain (python.langchain.com/docs) typically wires them together like this:

1. Procedural memory is the system prompt plus the set of tool definitions that tell the model how to look up orders and issue refunds. It is loaded on every turn and rarely changes.

2. Episodic memory is the conversation history, written to durable storage as it happens. Recent turns go into context verbatim; older ones are retrieved by similarity only when relevant.

3. Semantic memory is a vector store of extracted facts about each customer, queried at the start of a turn so the agent greets a returning user already knowing their plan and preferences.

4. Working memory is the assembled context window for the current request: system prompt, retrieved facts, recent turns, and this turn's tool output, packed together and sent to the model.

The design decisions that matter are which store holds what, and when each is read or written. Facts that should persist forever belong in semantic memory. A running account of what happened belongs in episodic memory. Behavior belongs in procedural memory. The current turn's scratchpad is working memory and is expected to be discarded.

One infrastructure requirement cuts across all of the long-term types: the storage has to survive restarts. Episodic logs, the semantic vector index, and any saved procedures are only useful if they are still there after the agent's process is redeployed or crashes. Platforms that keep an agent's files on durable storage by default, such as Sokko, make persistence the default instead of something you engineer by hand, and our overview of running AI agents on Kubernetes covers how durable storage for agents works in general. Once you can name which of the types of AI agent memory a given piece of information belongs to, and you have durable storage for the long-term ones, the rest of agent memory design becomes a set of concrete, tractable choices instead of a vague hope that the agent will "remember."