DEV Community: Anthony Conti

Agent Memory Explained: Types, Tools & How to Add It

Anthony Conti — Tue, 08 Sep 2026 14:07:00 +0000

Originally published on m-i-n-d.ai. I write and maintain MIND, an MCP memory server — full disclosure up front, since this piece also covers memory options that aren't ours.

What Is Agent Memory?

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.

The four kinds of memory an agent can have

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.

Is agent memory the same as RAG?

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.

Why can't a bigger context window just replace memory?

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.

How the major frameworks handle it differently

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	Checkpointing — the entire graph state is persisted after each step, so a run can resume exactly where it left off
Letta (MemGPT)	An OS-inspired model — the agent manages its own memory, paging facts between limited "main context" (RAM) and unlimited "archival memory" (disk)
Mem0	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	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)	Protocol-level — memory exposed as MCP tools any compatible agent can call, independent of which framework built the agent

How do you add memory to an agent via MCP?

Instead of wiring your agent to one framework's specific memory API, you point it at an 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 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.

A short checklist for choosing an approach

One agent, one framework, never leaves it? A framework-native memory module (LangGraph checkpointing, Letta's built-in archival memory) is the least friction.
Multiple agents or tools need the same memory? An MCP memory server is the right layer — the memory becomes reachable independent of which framework wrote or reads it.
Need to reason about what was true when, not just what's true now? A temporal knowledge graph (Zep/Graphiti) is purpose-built for that; most vector-only stores are not.
A person, not only an agent, needs to see and edit the memory? That rules out pure developer-infrastructure options — you need a product with a UI on top, which is the gap MIND was built for.

Common mistakes when adding memory to an agent

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.

Storing everything, forgetting nothing. An agent that writes every message to long-term memory builds a haystack, not a memory — retrieval quality degrades as duplicate and low-value facts pile up. Most production systems run an extraction step (an LLM decides what is actually worth keeping) before anything gets written.
No decay or consolidation. A fact from six months ago and a fact from six minutes ago usually should not carry equal weight at retrieval time. Systems that never expire, merge, or re-rank older memories tend to surface stale context alongside current context with no way to tell them apart.
Treating memory as a cache instead of a source of truth. If the memory store can silently be wrong (a preference the user later changed, a fact that was corrected), and nothing in the system ever revisits or overwrites it, the agent will confidently repeat outdated information — often more confidently than it would have guessed without any memory at all.
No write-side review for anything sensitive. An agent with unrestricted write access to memory can also be an agent that stores something it should not have, permanently, with no human ever reviewing what went in. Any memory system that will hold real personal or business information needs a visible way to audit and delete what it stored.
Coupling memory format to one framework. Building memory storage directly into a LangGraph checkpoint or a Letta archival store works fine until you need a second agent, built in a different framework, to read the same facts. This is the specific problem an MCP memory server is built to avoid — the storage format stops being tied to any one framework's internals.

Frequently asked

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, Mem0's pricing page, and Zep's pricing page.

Full piece, kept live and updated, is here: 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.

MCP Memory Server: What It Is & How to Choose (2026)

Anthony Conti — Tue, 08 Sep 2026 14:05:45 +0000

Originally published on m-i-n-d.ai. I write and maintain MIND, an MCP memory server — this piece tries to be straight about where MIND fits and where it doesn't.

What Is an MCP Memory Server?

The definition, the architecture, how to choose one, and an honest comparison of every option — including the GitHub repos that outrank us on this term today.

By Anthony Conti · Astra AI, LLC · Last updated September 7, 2026

An MCP memory server is a Model Context Protocol server whose job is to store and retrieve memories on behalf of an AI agent — facts, preferences, decisions, past conversations — so that what an agent learns in one session, on one tool, is still there the next time it is asked, on whatever tool asks it. MCP is the open standard Anthropic open-sourced on November 25, 2024 for connecting AI applications to external tools and data, and it is now supported by Claude, ChatGPT, Cursor, VS Code, Windsurf and dozens of other clients. A memory server is one specific kind of MCP server: instead of exposing a calendar or a Git repository, it exposes memory itself, as two or three callable tools — typically something shaped like store_memory and search_memory.

The one-sentence version. Without MCP, every AI tool you use has to reinvent memory, and none of them can read what another one remembers. With an MCP memory server in the middle, memory becomes a service any MCP-compatible agent can call — the same way any browser can render any website because HTTP is a shared standard.

Your AI Agent  ←→  MCP (JSON-RPC over HTTP or stdio)  ←→  MCP Memory Server  ←→  Storage
   (Claude, Cursor,        two or three tools:              (this is the part           (vector DB,
    Windsurf, ChatGPT)     store_memory / search_memory)     that varies)                graph, files...)

Is an MCP memory server the same thing as a vector database?

No — this is the single most common confusion, so it is worth being precise about. A vector database (Pinecone, Weaviate, Qdrant, pgvector) is a storage engine: you send it embeddings, it returns nearest neighbours. It has no concept of a tool call, a session, or an agent. An MCP memory server is the layer above that: it decides what gets stored, when, and how it is exposed to an agent as a callable tool. Several servers in the comparison table below use a vector database as their storage engine internally (Puliczek/mcp-memory runs on Cloudflare Vectorize, for instance) — the vector database itself has no idea MCP exists.

Is an MCP memory server the same as RAG?

They overlap but answer different questions. Retrieval-augmented generation is a technique: fetch the most relevant chunks of text and stuff them into the prompt before generating an answer. An MCP memory server is an integration surface: a standard interface an agent calls as a tool, regardless of what retrieval technique runs behind it. Most MCP memory servers use RAG-style retrieval internally, but RAG is the algorithm and MCP is the protocol carrying the request. You can build a memory server with no RAG at all (a flat key-value store would still qualify), and you can do RAG with no MCP in sight (most chatbot RAG pipelines predate MCP entirely).

The architecture, concretely

Every MCP memory server, however it stores data underneath, is built from the same three MCP primitives, formalised in the 2025-06-18 specification and refined again in the 2025-11-25 revision:

Tools. The callable actions an agent invokes — store_memory, search_memory, sometimes delete_memory or list_memories. Since the 2025-06-18 spec, tools can declare a structured output schema, so the agent gets typed results back instead of a raw string.
Resources. Read-only, URI-addressable context the server can expose — think of a specific saved memory or a document the agent can fetch by reference rather than by search.
Transport. Either local stdio (the server runs as a child process on your machine — simplest, single-user) or remote HTTP (the server runs somewhere else and the agent authenticates over OAuth — multi-device, multi-tool).

How to choose an MCP memory server

Five questions narrow the field fast. Most projects fail at least one of them for most people, which is fine — they were not built to pass all five.

Local file or real storage? A JSON file on disk (okooo5km/memory-mcp-server's default) is fine for one machine and a few hundred memories. It has no semantic search and does not survive a reinstall.
Remote or local-only transport? Local-only (stdio) means the memory lives on one machine. Remote HTTP means any device, any tool, can reach the same memory — the tradeoff is you now depend on someone's uptime.
Self-hosted or hosted? Letta and MIND's local path are fully self-hostable at zero cost. Zep retired its self-hosted Community Edition in 2026 — cloud only now, though the underlying Graphiti engine stays open source.
Does it stop at memory, or is there a product on top? Most entries in the table are pure infrastructure — a server and nothing else. If you personally want to open a page and see what's remembered, that rules most of them out.
One agent, or memory that has to be shared across agents and models? A memory store built for a single coding agent's context cache (JamesANZ/memory-mcp) is a different shape of tool than one meant to be read by five different AI products at once.

The honest landscape

Six real, currently-maintained options, verified against their own repos and pricing pages this session — MIND included, and not flattered. Every one of these is legitimately good at something.

Project	What it stores memory in	Hosting model	Worth knowing
MIND	Knowledge graph (entities + relationships + embeddings), MongoDB-backed	Remote (one-paste OAuth) or self-hosted local via npm — both free tiers	Memory plus a real product (web/mobile app) on top; 50+ LLM models can read the same graph
Mem0 (via coleam00/mcp-mem0)	Mem0's own vector + graph memory store	Template server you run yourself, pointed at Mem0 Cloud or self-hosted Mem0	A reference/template implementation, not an official Mem0 product — good starting point to fork
okooo5km/memory-mcp-server	A local knowledge graph (entities, relations, observations) in a JSON file	Local only, runs as a stdio MCP server	Closest thing to a reference implementation for graph-shaped memory over MCP; also ships a Go port
JamesANZ/memory-mcp	MongoDB-backed memories with tag-based search	Self-hosted; you provide the MongoDB connection	Built for coding-agent context caching across Cursor and Claude Desktop specifically
Puliczek/mcp-memory	Vector embeddings on Cloudflare Vectorize, metadata in D1	Cloudflare Workers — you deploy your own instance	Purpose-built for remembering user preferences/behaviors, not general knowledge capture
Zep (Memory MCP Server seats)	Temporal knowledge graph via Zep's Graphiti engine	Cloud only — Zep retired its self-hosted Community Edition (Graphiti itself stays open source)	Bills by 'credits' (roughly 1 credit per 350 bytes ingested); Free tier caps at 1 MCP seat
Letta (formerly MemGPT)	An OS-style memory model — active context is 'RAM', archival memory is 'disk'	Fully open source and self-hostable, or Letta Cloud	23,081 GitHub stars as of this writing — the most-starred project in this table by a wide margin

Star counts and pricing were checked against each project's own GitHub repo or pricing page during this session (2026-09-07); all three change constantly — verify against the source before deciding.

What tools does an MCP memory server usually expose?

Almost every project in the table above converges on the same small tool surface, even though the storage underneath is completely different from one to the next:

store_memory (or add_memory). Takes a piece of text plus optional metadata — a user id, tags, a timestamp — and writes it. This is where the interesting engineering differences actually live: does it deduplicate, does it consolidate near-duplicate facts, does it run an extraction step first to decide what is even worth keeping.
search_memory (or retrieve_memory). Takes a query and returns the most relevant stored memories, typically ranked by vector similarity, graph proximity, or recency. Zep and MIND both add graph traversal on top of similarity search; the smaller local-file projects do straightforward keyword or vector search only.
delete_memory / list_memories. Not every project implements these, but a memory server without a way to see or remove what it stored is hard to trust with anything sensitive — this is worth checking before adopting one for real use.

Where is MCP itself headed?

Worth knowing if you are betting infrastructure on this protocol: Anthropic open-sourced MCP as a company project in November 2024, but has since moved to hand off governance. Anthropic announced it is donating MCP to a newly established Agentic AI Foundation, moving the specification out from under a single vendor and toward the kind of neutral stewardship that standards like HTTP or OAuth have. For anyone choosing an MCP memory server today, that is a modest but real signal that the protocol itself is built to outlast any one company's roadmap — including Astra AI's.

Where MIND fits

Full disclosure: this page is published by Astra AI, LLC, which builds MIND. Here is the honest version anyway. Every project above except MIND stops at the server — there is infrastructure, and then it's your job to build something a person actually opens. MIND is an MCP memory server (connect it in one paste at /mcp-memory-server/setup) backed by a real knowledge graph, with a web and mobile app on top, so the same memory Claude Code just wrote is visible to you, searchable, and readable by 50+ other LLM models the next time you switch tools. If you specifically want the leanest possible memory API for one coding agent and nothing else, Mem0 or Letta may be the better fit — we would rather say that than sell you the wrong tool.

Frequently asked

Is an MCP memory server the same as a vector database?
No. A vector database (Pinecone, Weaviate, Qdrant, pgvector) is a storage engine for embeddings — it answers similarity queries. An MCP memory server sits on top of some storage engine (a vector database, a knowledge graph, a plain document store, or all three) and exposes it to an AI agent through the Model Context Protocol's tool-calling interface. Several of the servers in the table above use a vector database internally; the vector database itself has no idea what MCP is.

Is an MCP memory server the same as RAG?
They overlap but answer different questions. Retrieval-augmented generation is a technique — fetch relevant chunks, stuff them into the prompt. An MCP memory server is an integration surface — a standard way for an agent to call store_memory and search_memory as tools, regardless of what retrieval technique runs underneath. Most MCP memory servers use RAG-style retrieval internally, but MCP is the protocol, not the algorithm.

Can I just use a local JSON file instead of a real memory server?
For a single-machine, single-user coding assistant that never needs to search or grow past a few hundred entries, yes — several of the projects above started exactly there. It stops working the moment you need semantic search over the memories, multiple agents writing concurrently, or memory that follows you to a second machine.

Does MIND compete with Mem0, Zep, and Letta?
Partially, and we say so on purpose. Mem0, Zep, and Letta are excellent developer-infrastructure choices if you are building a single coding agent and want the leanest possible memory API. MIND is the pick if a person, not just one agent, needs to open a product, see their own graph, and have every AI they use — not one integrated app — read and write to it.

Sources verified this session: Anthropic — Introducing the Model Context Protocol, the MCP 2025-06-18 tools specification, Anthropic — donating MCP to the Agentic AI Foundation, and each listed project's own repository or pricing page.

Full piece, kept live and updated, is here: m-i-n-d.ai/mcp-memory-server. If you want the 10-minute MCP setup guide or the docs for MIND itself, that's at m-i-n-d.ai/mcp.html.