Memory in an AI agent is everything that lets it remember beyond the current turn: it distinguishes between working memory, which lives in the context window and is wiped when the session ends, and long-term memory, which stores facts and experiences in an external store to retrieve when they are needed. Without memory, an agent starts from scratch on every session. In this guide you will see why it needs memory, how it splits into short and long term, the three types it borrows from cognitive psychology, how it is stored with vector databases and which libraries (Mem0, Letta, Zep) solve the problem. The same explanation is available in Spanish.

Key takeaways

  • An agent’s working memory is its context window: fast but ephemeral and limited in size. Its long-term memory is an external store that survives between sessions.
  • Three types of long-term memory are usually distinguished, borrowed from psychology: episodic (what happened), semantic (facts about the user and the world) and procedural (how to do something).
  • The common storage is a vector database: each memory is saved as an embedding and retrieved by similarity to the current query.
  • The paper Generative Agents (2023) proposed the idea of a memory stream with retrieval by recency, importance and relevance, the basis for almost everything that followed.
  • Libraries like Mem0 (around 60,000 GitHub stars) cut more than 90% of the tokens versus stuffing the whole history into context, according to its paper on the LOCOMO benchmark.

Why does an agent need memory?

A language model remembers nothing on its own. Each API call is independent: the model only sees what you pass in that request and, once it answers, it forgets everything. The illusion that a chatbot "remembers" the conversation holds because the application resends the full history on every turn. For an AI agent, which can take dozens of steps and work for hours, that trick stops working quickly.

The problem is twofold. First, the context window has a ceiling: even though 2026 models accept hundreds of thousands of tokens, packing the whole history in there is expensive, slow and degrades answer quality once the context fills up. Second, there is information you want to keep across separate sessions: the user’s preferences, what the agent learned yesterday, the result of a task from last week. None of that fits (nor should it fit) in a single request.

Memory solves both by separating what the agent has in front of it right now from what it can retrieve when it needs to. It is the difference between what you hold in mind while talking and what you have jotted in a notebook to look up later.

Working memory versus long-term memory

The fundamental distinction is between working memory (short term) and long-term memory, and it maps fairly well onto how human memory works.

Working memory is the model’s context window: the goal, the last messages, the available tools and the recent observations. It is immediate and free to consult, because the model is already looking at it, but it is ephemeral (it disappears when the session ends) and limited (everything you put there competes for the same token budget). Managing that space well is a topic in itself, context engineering.

Long-term memory is a store outside the model (a file, a database, a graph) that persists between sessions. The agent does not see all of it at once: it queries it with a search tool and brings only the relevant fragments into context. It is the difference between a computer’s RAM and its disk, an analogy the MemGPT project pushed to the limit by describing the model as "a process running on a memory-constrained operating system". The agent decides what to page from disk to RAM at any moment.

In practice, an agent combines both. A coding assistant keeps the file it is editing now in working memory, and the project conventions it learned in earlier sessions in long-term memory. The art is bringing just enough into context, neither too much (you waste tokens) nor too little (the agent loses the thread).

What are episodic, semantic and procedural memory?

Within long-term memory a taxonomy from cognitive psychology is usually copied, with three types, useful because each is stored and used differently.

Episodic memory stores concrete experiences: what the user asked on Tuesday, which tool failed, how a similar issue was resolved. These are dated events, and they help the agent learn from what it already did instead of stumbling over the same stone twice.

Semantic memory stores timeless facts about the user and the world: "her name is Ana", "she works in Madrid", "she prefers short answers". It does not matter when the agent learned it, only that it knows. This is what makes an assistant seem to know you.

Procedural memory stores how to do something: the steps of a task, the system rules, the good practices the agent should follow. It is often not kept in a separate database but lives in the system prompt or in the tools’ own code, because it defines the agent’s behaviour at all times.

A good memory system decides, for each new piece of data, which drawer to store it in and which to retrieve it from. Many modern libraries do that classification automatically with a helper model that extracts the facts worth remembering.

Storing memories with vector databases

The most common mechanism for long-term memory is the vector database. Each memory (a sentence, a fact, the summary of a conversation) is turned into an embedding, a vector of numbers that captures its meaning. When the agent needs to recall something, it turns the current query into another embedding and searches for the closest memories by cosine similarity. That way it retrieves what is relevant even when the words do not match exactly.

This semantic-retrieval approach was popularised by the paper Generative Agents: Interactive Simulacra of Human Behavior (2023), where 25 agents lived together in a simulated town. Each agent kept a memory stream of all its experiences in natural language and, to decide what to recall, scored each memory with three factors: recency (how long ago it was), importance (how much the memory matters) and relevance (how similar it is to the current situation). That combination, plus a reflection phase that summarises memories into high-level conclusions, is still the reference pattern.

Not all long-term memory is vector-based. Some systems use a knowledge graph, where facts are nodes and edges with explicit relationships between entities. It is more precise for reasoning about how data changes over time, at the cost of being more complex to maintain.

Memory libraries: Mem0, Letta and Zep

You do not need to build all of this by hand. Three open projects dominate the space in 2026, with different approaches.

Mem0 is the most popular option (around 60,000 GitHub stars, version 2.0.12 in July 2026). It sits as a memory layer on top of any LLM: you pass it the messages, it extracts the facts worth remembering and saves them in a vector store; later it retrieves them with a search. According to its research paper[1] on the LOCOMO benchmark, it improves accuracy by 26% over OpenAI’s memory and uses around 1,764 tokens per conversation instead of the 26,031 of stuffing the whole history in, more than 90% savings. Getting started is direct:

pip install mem0ai
from mem0 import Memory

m = Memory()  # uses a local vector store by default

m.add("Ana prefers short answers and works in Madrid", user_id="ana")

memories = m.search("how do I answer this user?", user_id="ana")
print(memories)  # the most relevant memories for this user

The first block installs the package with pip; the second imports the class with the from mem0 import Memory statement, saves a memory with the add method and later retrieves it with search, which returns the list ranked by relevance.

Letta (formerly MemGPT) goes a step further and lets the agent manage its own memory through tools. It organises memory like an operating system in three tiers: core memory (editable blocks that live in the context, such as human and persona), recall memory (the searchable message history) and archival memory (long-term storage the agent queries with a tool). The agent decides when to write or read each tier.

Zep, through its open engine Graphiti (around 28,000 stars), builds a temporal knowledge graph. Each fact has a validity window, so when a datum changes (the user moves city) the system marks the old one as expired instead of leaving two versions that contradict each other. In its paper[2] it reports accuracy gains of up to 18.5% and up to 90% less latency versus dragging the whole context. It is the best fit when the history of how data evolves matters.

Frequently asked questions

Isn’t a large context window enough?

Not quite. Even though 2026 models accept hundreds of thousands of tokens, packing the whole history into every call is expensive, adds latency and lowers quality once the context fills up, an effect known as long-context degradation. Besides, the window is wiped when the session ends, so you still need an external store to remember from one day to the next. A large window helps, but it does not replace long-term memory.

What is the difference between memory and RAG?

They overlap, but they are not the same. RAG retrieves fragments from a fixed knowledge base (manuals, documentation) to answer better. An agent’s memory is information it generates and updates itself: what it learned from the user, what it did in earlier tasks. Technically both use embedding search over a vector database, but memory is personal, changing and written by the agent itself.

Where are memories stored?

In a store external to the model. The most common is a vector database (Qdrant, Chroma, pgvector) that keeps each memory as an embedding and retrieves it by similarity. Other systems, like Zep, use a knowledge graph to reason about how facts change over time. Libraries like Mem0 or Letta abstract that choice away and manage the store for you.

Conclusion

Memory is what turns a stateless model into an agent that learns. The key is separating working memory (the context window, fast but ephemeral) from long-term memory (an external store that persists and is queried on demand), and organising the latter into episodic, semantic and procedural memories. The engine is almost always a vector database that retrieves by similarity, with the recency, importance and relevance pattern popularised by Generative Agents. To avoid building it from scratch, start with Mem0 if you want a simple layer, Letta if you prefer the agent to manage its own memory, or Zep if you need to track how data changes over time. The next step is learning to manage the context that does reach the model: continue with context engineering for agents.

Sources: [1] Generative Agents, Interactive Simulacra of Human Behavior (arXiv 2304.03442)[3], [2] Mem0, Building Production-Ready AI Agents with Scalable Long-Term Memory (arXiv 2504.19413)[1], [3] Mem0 GitHub repository[4], [4] Letta memory architecture[5], [5] Zep, A Temporal Knowledge Graph Architecture for Agent Memory (arXiv 2501.13956)[2].

Visitas: 0

Sources

  1. research paper
  2. paper
  3. Generative Agents, Interactive Simulacra of Human Behavior (arXiv 2304.03442)
  4. Mem0 GitHub repository
  5. Letta memory architecture

Route: AI Agents Fundamentals