Best Memory Tools for AI Agents and Coding Assistants
Most AI assistants forget everything when the context window fills up or a new session starts. Memory tools fix that in different ways: some store facts from conversations, some keep a structured picture of your project, and some index your code so the agent can look things up instead of reading whole files.
Decide which kind of memory you need before you compare. The tools below fall into three groups: agent memory frameworks, memory for coding assistants, and code-intelligence graphs.
AgentIndex · Updated 2026-10-14
Quick picks
- letta — a platform for stateful agents with persistent, self-improving memory; the most established option here.
- mcp-memory-service — persistent memory across AI sessions for MCP clients; pick it if you want one memory shared between clients.
- mex — structured project memory scaffold for coding agents, with a CLI that detects drift between memory and code.
- codebase-memory-mcp — indexes a codebase into a knowledge graph so agents use fewer tokens exploring it.
- LycheeMem — memory framework with working, semantic and procedural stores on SQLite and LanceDB; a young project.
Side-by-side comparison
| Tool | What it is | Stars | License | Last push | Install |
|---|---|---|---|---|---|
| letta | Stateful agents with persistent, self-improving memory | 25.1k | Apache-2.0 | 2026-09-10 | npm install -g @letta-ai/letta-code |
| mcp-memory-service | Persistent memory across AI sessions for MCP clients | 2.0k | Apache-2.0 | 2026-10-13 | pip install mcp-memory-service |
| mex | Structured project memory scaffold for AI coding agents with drift detection | 1.8k | MIT | 2026-10-13 | npx mex-agent setup |
| codebase-memory-mcp | Code knowledge graph that cuts agent token use on codebases | 46.5k | MIT | 2026-10-13 | curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/mai… |
| gortex | Code intelligence engine exposing a repo knowledge graph to coding agents | 1.9k | n/a | 2026-10-13 | OS=$(uname -s | tr '[:upper:]' '[:lower:]') |
| PrismerCloud | MIT harness for long-running agents: context cache, memory, shared error-fix learning, task retry and messaging via SDK, CLI, MCP and a Claude Code plugin | 1.4k | MIT | 2026-10-11 | npm i @prismer/sdk |
| LycheeMem | Apache-2.0 memory framework for LLM agents with working, semantic and procedural stores on SQLite and LanceDB, plus MCP and an OpenClaw plugin | 1.1k | Apache-2.0 | 2026-08-06 | git clone https://github.com/LycheeMem/LycheeMem.git |
Tools in this list with an in-depth AgentIndex review: 7/7
How to choose
- Separate conversation memory from project memory and from code indexing. They solve different problems.
- Check where memories are stored. Local SQLite or files keep data on your machine; hosted services send it elsewhere.
- Look for MCP support if you want the same memory across Claude, Cursor and other clients.
- Stored memory can contain sensitive conversation content, so check how to inspect, edit and delete it.
- Younger projects change fast; check the last-push date and whether the API is still moving.
FAQ
What is the difference between agent memory and RAG?
RAG retrieves from a fixed document collection to answer a question. Agent memory records what happened in conversations and work over time, such as preferences, decisions and past mistakes, so the agent can use it later. Some tools combine both.
Where is the memory stored?
It depends on the tool. Several here keep data locally in SQLite or files, while hosted offerings store it on their servers. Check the project's README for the storage location before you put personal or company data into it.
Do coding agents need a code knowledge graph?
Not for small projects. On large repositories, an index or knowledge graph lets the agent look up the relevant functions instead of reading whole files, which can cut token use and speed up answers.
How we compiled this list
Tools are chosen by hand from the projects in our index, favouring those we have reviewed in depth. Stars, licence, last-push date and install command come from each repository and are refreshed with the site data. We read each project's README and docs; we have not run every tool ourselves, so test before you depend on one.