Quick Answer

AI agents use four types of memory. Working memory holds the information needed for the current task. The other three persist beyond it: episodic memory stores past events, semantic memory stores facts, and procedural memory stores how to do things.

These are architectural categories, not four built-in features of an LLM. A model ships with none of them. Each one is something you design and add.

Every LLM-based AI agent starts each session the same way: with no memory of anything that came before. That is not a bug. It is the default. Unless an agent is deliberately given a memory system, it has no more continuity between conversations than a fresh instance of the model.

Building that memory system means answering a practical question on every interaction: what is worth keeping, and for how long? Different information needs different answers. The task you are working on right now is useful for a few minutes. A user's stated preference is useful for months. A workflow the agent learned should last until someone changes it.

This post covers the four memory types production agents use, what each one stores, how each is implemented, and how to decide which of them your agent actually needs.

What Is AI Agent Memory?

AI agent memory is the system that lets an agent retain information across turns, tasks, and sessions, and retrieve the right piece at the right moment.

It sits outside the model. An LLM has no mechanism for retaining anything between calls, so whatever memory an agent appears to have was designed and added on purpose. In practice, the system has two paths: a write path that decides what is worth storing from each interaction, and a read path that decides what to bring back when a new request arrives.

Memory is not one store. It separates by how long the information stays useful and by what kind of information it is, which is what the four types below describe.

AI Agent Memory: A Quick Comparison Table

Academic grounding: the CoALA framework from Princeton (Sumers et al., arXiv:2309.02427, 2023) is the canonical reference for these four types.

The Four Core Types of AI Agent Memory

The four types are working memory, episodic memory, semantic memory, and procedural memory. The CoALA paper (Sumers et al., Princeton, 2023) is the reference most of the field now uses for this taxonomy.

The model is a starting point, not a settled answer

A December 2025 survey, "Memory in the Age of AI Agents" (arXiv:2512.13564), notes the field is fragmenting as research expands. Consolidation pathways from episodic to semantic memory, the transition to in-weights implicit knowledge, and multi-agent memory governance are all active areas with no agreed answer.

Treat the four types as a working vocabulary rather than a final taxonomy. It is good enough to design with, and it is not the last word.

Working Memory (In-Context Memory)

In AI agents, working memory corresponds most directly to the context window: the span of tokens a model can hold and reason over during a single exchange. Everything the model is actively using in a given turn has to fit inside it.

Session-scoped memory works the same way at a slightly larger scale. It holds context for the duration of a single conversation or task, then gets discarded once the session ends, rather than being promoted to long-term storage.

Deciding what goes into that limited space, and in what order, is the discipline of context engineering. Working memory is where every other memory type eventually has to land, because the model cannot see anything that is not in the context window when it generates.

Related read: Context Window vs Persistent Memory

What in-context memory stores

• The current user request

• The system prompt and any active instructions

• Recent conversation turns from this session

• Results returned by tools the agent called this turn

• Memories retrieved from long-term storage for this specific request

• Intermediate reasoning or scratchpad notes the agent produced while working

Implementation tools for in-context memory

Most of this is handled by the agent framework rather than a separate product. LangGraph checkpoints graph state between steps, which persists working memory across a multi-step run and allows a paused workflow to resume. For session state that must survive beyond a single process, teams usually reach for Redis or a comparable in-memory store, keyed by session or run ID.

The constraint that shapes every choice here is size. Working memory is bounded by the context window, and every token in it costs money on every call, so the real work is deciding what to leave out.

Long-Term Memory

Long-term memory stores information beyond a single session. It holds everything from learned behaviors to past outcomes and general knowledge. It is divided into three categories: episodic memory, semantic memory, and procedural memory.

The distinction that matters in practice: working memory disappears when the session ends, and long-term memory does not. Anything an agent should know next week has to be written somewhere outside the context window, and retrieved deliberately when it becomes relevant again.

Episodic Memory

In AI agents, episodic memory is the record of a specific past interaction or outcome, tied to a particular moment rather than a general fact.

Here is a timestamped example. On 12 March, an agent helped deploy a model, and latency rose after a cache configuration change. The episodic memory is that event: what was attempted, when, and what happened as a result. It is not a rule, and it is not a preference. It is one thing that occurred on one date.

That specificity is the value. When the same agent prepares a similar deploy in June, the episodic record lets it check the cache settings first, rather than rediscovering the problem. This is what allows an agent to avoid repeating a mistake, rather than only knowing a static preference.

What episodic memory stores and how it works

• Past interactions and their outcomes, with a timestamp

• Decisions made, and the reasoning available at the time

• Failed attempts and what caused the failure

• Tool calls and the results they returned

• Task completions, including what was produced

• The session or run the event belonged to, for scoping

Retrieval is usually semantic search over embeddings, filtered by time and by scope. Because each record belongs to one moment, episodic memory grows faster than the other types and ages faster too, so production systems summarize, prune, or decay old records rather than keeping everything.

Episodic memory implementation

In Mem0, an episodic record is created through add() and retrieved with search(). Scoping is the part that matters most: user_id ties the event to a person, agent_id ties it to a specific agent instance, and run_id ties it to a single task or workflow execution. Those scopes compose, so you can retrieve everything that happened in one run, or everything that ever happened to one user, from the same store.

Metadata filtering is what makes episodic retrieval practical at scale. A timestamp in metadata lets you ask for recent events rather than merely similar ones, which is usually what you want when the question is "what did we try last time."

Semantic Memory

In AI agents, semantic memory is generalized knowledge accumulated across many interactions, rather than knowledge tied to any single one.

"This user works in fintech and prefers concise answers" is a semantic memory. It is a pattern, not a record. Compare it with the episodic example above: "the deploy on 12 March increased latency" is one event on one date, while "this user prefers concise answers" has no date attached and applies to every future conversation until something changes it.

That is the dividing line. A general fact stays true across situations. A specific past event stays true about one moment. Both are worth keeping, and they behave differently enough that storing them the same way causes problems.

What semantic memory stores

• User preferences, such as format, tone, and level of detail

• Role, domain, and organization facts about the user

• Domain knowledge the model was not trained on

• Product, policy, and configuration facts specific to your deployment

• Relationships between entities, such as which team owns which service

• Standing constraints, such as an approved vendor list

Implementation tools for semantic memory

Vector databases are the common storage layer, because semantic retrieval depends on embedding similarity. Qdrant, Chroma, Weaviate, Milvus, PGVector, and Pinecone all serve this role, and the choice usually turns on deployment model rather than retrieval quality.

Knowledge graphs are the alternative when relationships matter more than similarity. A graph answers "which services does this team own" in a way vector search cannot, by traversing explicit edges rather than comparing embeddings.

Most production systems combine signals rather than rely on one. Semantic similarity finds meaning, keyword matching catches exact terms such as IDs and code symbols, and entity matching connects related facts. Mem0 fuses all three into a single score at retrieval time.

The performance numbers are worth noting. The Mem0 research paper (arXiv:2504.19413, April 2025, Mem0's own research) benchmarks its memory layer at 91% lower p95 latency and over 90% token cost savings against naive context stuffing, with a 26% relative improvement over OpenAI's default memory approach on the LOCOMO benchmark. Retrieval architecture matters more than storage volume.

Procedural Memory

In AI agents, procedural memory is knowledge of how to do something, rather than knowledge of a fact.

Where semantic memory stores "this user works in fintech," procedural memory stores "when this user asks for a report, format it as a table with totals at the bottom."

Two sources feed it, and systems that only use one are incomplete. Some procedures are explicitly given: an instruction written into a prompt template, a tool-use rule that says which API to call for which request, an approved workflow that must be followed in order. Others are learned from repeated patterns, where the agent notices a user always rejects a certain suggestion and stops making it. Both belong in procedural memory. The explicit kind is more common in production, because most teams would rather write a rule than wait for an agent to infer one.

This shows up most clearly in coding agents and workflow automation, where the value is not remembering a fact about the user but remembering the sequence of steps that reliably completes a task.

What procedural memory stores

• Explicit instructions and standing rules

• Tool-use rules: which tool for which situation, and in what order

• Reusable workflows and multi-step sequences

• Output format and structure conventions

• Error-handling routines and retry behavior

• Behaviors inferred from repeated interactions, such as a consistently rejected suggestion

How the Memory Types Work Together

The types are easier to see in one request than in the abstract. Take a support agent handling a refund request from a returning customer.

• Working memory holds the current ticket: the customer's message, the ticket ID, the order number, and the system prompt that tells the agent how to behave. This is what the model sees directly.

• Episodic memory supplies one past event: this customer requested a refund in January, and it was approved after a supervisor review. That is a record of one thing that happened, with a date.

• Semantic memory supplies a standing fact: this customer prefers email over phone contact. No date, no single event, just something that stays true.

• Procedural memory supplies the rule: refunds above $500 require supervisor approval before the agent commits to anything.

For this request, the retrieval step pulls the January refund record, the email preference, and the escalation rule, and places them into working memory alongside the current ticket. It does not pull the customer's twelve other tickets, their shipping address, or the forty other procedures the agent knows, because none of those bear on a refund request.

That selection is the whole job. The agent then answers with the right process, the right history, and the right contact method, without the user restating any of it.

How to Choose What Your Agent Should Remember

Not everything belongs in memory. Six criteria cover most decisions.

• Reuse value: Will this information be useful in a future request? A stated preference will be. A one-off clarification about the current task will not. If you cannot name a future situation where it helps, do not store it.

• Freshness: How fast does this go stale? A user's role changes slowly. An account balance changes constantly. Volatile information should be fetched from the authoritative system at the moment it is needed, not cached in memory where it will be confidently wrong later.

• Source reliability: Did the user state this, or did the model infer it? An inference stored as a fact becomes a fact the agent never questions. Keep the two separate, and record which is which.

• Sensitivity: Should this be stored at all? Memory persists data, which creates obligations around access control, retention, and deletion. Some information is better not written down, regardless of how useful it would be.

• Retention period: How long should this live? A session preference might last an hour. A standing instruction might last until someone revokes it. Deciding this at write time is easier than deciding it later, when the store is full.

• Session state or persistent storage: Does this need to survive the session? If the answer is no, it belongs in session state, and writing it to long-term memory adds cost and noise with no benefit.

One more thing, which is easy to miss. Storing information is not the same as using it. A memory that is never retrieved at the right moment has no effect on any answer. The retrieval path deserves as much design attention as the write path, because a perfect store that surfaces nothing useful performs exactly like no memory at all.

Frequently Asked Questions

Q. Is a context window the same as memory?

No. A context window is the span of tokens a model can process in one request. It has no persistence: once the request ends, nothing in it carries forward unless the application sends it again. Memory is a storage and retrieval layer outside the model that holds information between requests and brings back what is relevant. A context window is where memory is delivered, not where it lives.

Q. What is the difference between episodic and semantic memory?

Episodic memory records a specific past event, such as a particular deployment or conversation outcome, and is tied to a moment in time. Semantic memory stores a generalized fact learned across many interactions, such as a recurring preference, and is not tied to any single event. Episodic memory answers "what happened." Semantic memory answers "what is generally true."

Q. Does every AI agent need long-term memory?

No. An agent that handles one-shot, self-contained requests does not need it: a classifier, a translator, or a single-turn lookup gains nothing from remembering yesterday. Long-term memory earns its cost when a user returns, when a task spans sessions, or when past outcomes should change future behavior. If a user has to repeat themselves, that is the signal.

Q. What tools are used to implement AI agent memory?

Four layers, usually. Vector databases such as Qdrant, Chroma, Weaviate, and Pinecone store embeddings for semantic retrieval. Agent frameworks such as LangGraph and LangChain manage working memory and session state. Dedicated memory layers such as Mem0 handle extraction, scoping, updating, and retrieval as a single service. Session stores such as Redis hold short-lived state. Many teams combine several, since each layer solves a different part of the problem.

Q. How do AI agents implement long-term memory?

AI agents implement long-term memory as a storage and retrieval layer that sits outside the model's context window. Systems like Mem0 extract facts, past interactions, and learned behaviors as they happen, then retrieve only the relevant ones at the right moment instead of replaying the full history every time.