# Agent Memory Explained: Types, Tools & How to Add It > Source: > Published: 2026-09-08 14:07:00+00:00 *Originally published on [m-i-n-d.ai](https://www.m-i-n-d.ai/agent-memory). I write and maintain MIND, an MCP memory server — full disclosure up front, since this piece also covers memory options that aren't ours.* The four types, how the major frameworks differ, and how to add real memory to an agent you're building. *By Anthony Conti · Astra AI, LLC · Last updated September 7, 2026* Agent memory is the mechanism that lets an AI agent retain information — facts, preferences, past actions, and outcomes — across turns, sessions, and tools, instead of starting from zero every time its context window resets. An agent without memory can reason brilliantly inside one conversation and remembers nothing about the person or task the moment that conversation ends. Memory is the layer that fixes that, and it is a genuinely separate concern from the model, the framework, and the context window. **Why this matters more in 2026 than it did in 2023.** Early chatbots got away with no memory because a session was the whole product. Agents now run multi-day tasks, hand off work between tools, and are expected to remember a decision made three weeks and two model switches ago. Context windows grew — many models now offer well over 100,000 tokens, and some exceed a million — but a bigger window is still working memory: it resets the instant the call ends. None of that solves persistence. Borrowed loosely from cognitive science, and useful because most "add memory to my agent" questions are really "which of these four do I actually need?" | Type | Lives in | Survives | Example | |---|---|---|---| | Working memory | The context window — the tokens sent to the model on this call | Nothing past this conversation, and often not even the whole conversation once it's long | The last ten messages of the chat you're in right now | | Long-term / semantic memory | External storage — a vector database, a knowledge graph, a document store | Sessions, restarts, and (if the storage is shared) the specific agent that wrote it | "This user prefers TypeScript over JavaScript" — retrieved months later | | Episodic memory | A log of specific past events, usually timestamped | As long as the log is kept — often pruned or summarized over time | "On March 3rd we tried Redis and rolled it back because of latency" | | Procedural memory | Learned patterns about how to do something, not what happened | Indefinitely, and usually generalizes across many episodes | "This codebase always wants tests in the same PR as the feature" | Most real systems only need working memory plus long-term/semantic memory to cover the common cases. Episodic and procedural memory matter more for agents that operate over long, multi-day tasks where the specific sequence of past events, not just the facts extracted from them, changes what the agent should do next. No, though the two are frequently built together and get conflated because of it. Retrieval-augmented generation is a generation technique: fetch relevant chunks, put them in the prompt. Agent memory is the broader system responsible for deciding what an agent should retain, consolidate, or forget over time — RAG is typically the retrieval mechanism that memory system uses at answer time, but memory also covers the write path (what gets stored and when) that RAG alone says nothing about. Because a context window is working memory, and working memory has never been what persistence problems are about. Even a model with a million-token window forgets everything the moment a new conversation starts unless something outside that window wrote the relevant facts down first. Stuffing an entire history into every prompt also gets slow and expensive long before you hit a hard token limit — most production agents summarize or retrieve selectively well under the max, which is a memory-system decision, not a context-window one. There is no single "agent memory" implementation — five well-known projects take meaningfully different approaches, verified against each project's own documentation this session: | Project | Approach | |---|---| | [LangGraph](https://modelcontextprotocol.io/introduction) | Checkpointing — the entire graph state is persisted after each step, so a run can resume exactly where it left off | | [Letta (MemGPT)](https://github.com/letta-ai/letta) | An OS-inspired model — the agent manages its own memory, paging facts between limited "main context" (RAM) and unlimited "archival memory" (disk) | | [Mem0](https://mem0.ai/pricing) | An extraction-and-consolidation layer — an LLM decides what from a conversation is worth remembering, then stores it with vector + optional graph indexing | | [Zep / Graphiti](https://www.getzep.com/pricing) | A temporal knowledge graph — facts are nodes and edges with validity windows, so the system can reason about what was true when, not just what's true now | | [MCP memory servers (this cluster)](https://www.m-i-n-d.ai/mcp-memory-server) | Protocol-level — memory exposed as MCP tools any compatible agent can call, independent of which framework built the agent | Instead of wiring your agent to one framework's specific memory API, you point it at an [MCP memory server](https://www.m-i-n-d.ai/mcp-memory-server) — an external process exposing memory as standard MCP tools (`store_memory`, `search_memory`). The advantage over a framework-native memory module: the same memory becomes reachable from any MCP-compatible client, not just the one framework you built the agent in. The practical setup takes about 10 minutes — see [the setup guide](https://www.m-i-n-d.ai/mcp-memory-server/setup) for exact config. Scope is the other decision worth making explicitly before wiring anything up. Memory can be scoped per-user (every fact tied to one person, the default most products assume), per-agent (a fact one specific agent learned, not shared with others acting on the same account), or global (shared across every agent and every user on an account, which is rare and usually only appropriate for organization-wide facts). Getting this wrong in either direction — leaking one user's memory into another's context, or siloing memory so tightly that no two agents can ever share it — is a more common failure than picking the wrong storage backend. Most agent-memory bugs are not exotic — they are one of the same handful of mistakes, repeated across nearly every framework and storage backend, and nearly all of them show up as the same symptom: the agent confidently says something that used to be true, or something nobody actually told it, with no obvious way to tell where the wrong context came from. **Is agent memory the same as RAG?** No, though the two are often built together. RAG is a generation technique — retrieve relevant text, put it in the prompt. Agent memory is the broader system responsible for deciding what an agent should retain, forget, and update over time; RAG is frequently the retrieval mechanism that memory system uses at answer time, but memory also covers what to write, when to consolidate duplicate facts, and how to expire stale ones. **Why can't a bigger context window just replace memory?** A larger context window (many models now offer well over 100,000 tokens, and some exceed a million) buys you more working memory per call — it does not persist anything after the call ends, and stuffing an entire history into every prompt gets slow and expensive well before you hit the limit. Memory is the system that decides what's worth carrying forward at all, independent of window size. **Do I need a framework to add memory to my agent?** No. The framework (LangGraph, Letta, CrewAI, a bare loop you wrote yourself) decides how the agent plans and acts. Memory is a separate concern you can bolt on via an MCP memory server regardless of framework — that's the point of a protocol-level integration instead of a framework-specific one. **What's the difference between agent memory and a second brain?** Mostly audience. "Agent memory" is the developer-facing term for the same underlying idea a "second brain" describes for a person: information that persists and gets recalled at the right moment instead of re-explained every time. Sources verified this session: [letta-ai/letta on GitHub](https://github.com/letta-ai/letta), [Mem0's pricing page](https://mem0.ai/pricing), and [Zep's pricing page](https://www.getzep.com/pricing). Full piece, kept live and updated, is here: **[m-i-n-d.ai/agent-memory](https://www.m-i-n-d.ai/agent-memory)**. If you want the MCP memory server comparison this piece references, that's at **[m-i-n-d.ai/mcp.html](https://www.m-i-n-d.ai/mcp.html)**.