Best AI Agent Memory Tools for Coding in 2026
Six products get called AI agent memory.
They answer at least three different questions, and the one that matters for a codebase is not the one most of them were built for.
Short answer
There is no single best one, because the category holds three different products: memory about a user or conversation, general memory infrastructure you call from your own code, and project knowledge for a coding agent. Pick by the unit you need stored and by whether knowledge should arrive on request or before the agent acts.
What this covers
- Mem0, Zep, Supermemory and Letta are built primarily for the first two. Mem0 stores facts scoped to a user, session or agent and returns them from an explicit search call. Zep models facts about a subject as a temporal graph with validity windows. Letta is a platform for building a stateful agent that edits its own memory blocks rather than a layer that feeds an agent you already run.
- ByteRover and Pathrule are built for coding agents. ByteRover keeps markdown in a domain and topic tree under .brv/context-tree and retrieves it by query with BM25 ranking. Pathrule keys memories, rules and skills to repository paths and delivers the matching slice at hook time, before the first tool call.
- The Model Context Protocol ships a reference memory server that stores entities, relations and observations in a JSONL file. It is the right answer for one person who wants durable local scratch memory with no account and no service.
- The two questions that decide the choice are what unit the tool stores (a user, a subject, a document, a path) and whether knowledge arrives when queried or before the agent acts. A tool that only answers when asked cannot deliver a constraint the agent does not know exists.
- If what you need is conversational or user memory inside your own product, Pathrule is the wrong choice and a memory API is the right one.
- Claims are dated September 2026 and taken from each product's own documentation.
Comparison
| Tool | What it stores | How the agent gets it |
|---|---|---|
| Mem0 | Facts scoped to a user, session or agent | An explicit search call from your code |
| Zep | Facts about a subject as a temporal graph, each with a validity window | A graph search or context call, on request |
| Supermemory | Documents and context you write in, self-hostable | An API call from your application |
| Letta | Memory blocks pinned in an agent you build, plus archival memory | You build the agent; it edits its own blocks |
| ByteRover | Markdown in a domain and topic tree, local first | A query against the tree, ranked with BM25 |
| MCP reference server | Entities, relations and observations in a JSONL file | MCP tool calls the agent chooses to make |
| Pathrule | Memories, rules and skills attached to repository paths | Injected at hook time, before the first tool call |
Answer these before you compare features
- What is the unit? A user, a subject, a document, or a directory in your repository.
- Who writes it? Your application, the agent itself, or your team.
- When does it arrive? Only when something queries, or before the agent acts.
- Does anything enforce it, or does it all come back as text?
- Who else sees it? One machine, one account, or the whole team.
- What happens when you change agent next quarter?
Three different products share one name
Search for AI agent memory and you get a list that treats Mem0, Letta, ByteRover and a reference MCP server as alternatives to each other. They are not. They answer at least three different questions, and the reason the comparison feels slippery is that most articles compare feature checklists across products that were never trying to do the same job.
The first question is what a system should remember about a **person or a conversation**. That is the memory a chat product needs: preferences, recurring topics, who you are talking to. The second is memory as **infrastructure you call from your own code**, where you own the write and the read and you are building the product around it. The third is **project knowledge for a coding agent**: the decisions, gotchas and conventions that govern a repository, which are not about a user at all.
Pick a tool from the wrong group and it will work exactly as advertised and still not solve your problem. That failure is quiet, which is why it is worth ten minutes up front.
General purpose memory infrastructure
**Mem0** describes itself as drop-in memory infrastructure for AI agents and apps. It stores facts scoped to a user, session or agent, and your application retrieves them with an explicit search call carrying filters. Its published use cases run across healthcare, education, e-commerce and support rather than software development specifically. If you are building a product that needs to remember its users, this is the shape you want, and it is a good one.
**Zep** models memory as a temporal knowledge graph built on Graphiti, its open source engine. Entities, relationships and facts carry validity windows, so a contradiction closes the previous fact rather than overwriting it and the history stays queryable. That is a genuinely different capability, and if your problem is an agent that must track how a subject changed over time, nothing else on this list does it as directly.
**Supermemory** positions itself as context infrastructure for AI agents, with an API, team use, and self-hosting that runs locally. It names Claude and coding agents among its use cases rather than as its only target. If you want hosted ingestion from the places your team already writes things down, it is a reasonable fit.
**Letta** is the one most often miscategorised. It is not a memory layer you attach to an agent you already run; it is a platform for building a stateful agent. Memory blocks are pinned into the agent's context and the agent edits them itself with built-in tools, with archival memory it queries on demand. If you are building an agent, that is a real architecture. If you already run Claude Code and Codex and want them to know your codebase, Letta is answering a different question.
Memory built for a codebase
**ByteRover** keeps a project's knowledge as markdown under `.brv/context-tree/`, organised into domains, topics and optional subtopics, with generated `context.md` and `_index.md` files that summarise upward through the hierarchy. The files are human readable and git friendly, which is a real advantage: you can browse them in a file explorer and review changes in a diff. Retrieval is by query, ranked with BM25 and a compound score.
**Pathrule** keys knowledge to the repository's own paths rather than to a domain taxonomy, and splits it into three types: memories for what is true, rules for what must not happen, and skills for how a job is done. A rule carries a scope, a priority and an enforcement level, so a strict rule can block a matching change rather than only describing it. Delivery happens at the hook points the agent already exposes, before the first tool call, so the slice governing the current directory arrives whether or not the agent would have asked.
The two differ on both axes at once. ByteRover organises by subject and answers when queried; Pathrule organises by path and pushes. Neither is universally better, and which one fits depends on whether your knowledge is more naturally addressed by topic or by location in the tree.
The free option most comparisons skip
The Model Context Protocol ships a memory server of its own: a knowledge graph of entities, relations and observations persisted to a JSONL file on your machine. It has no account, no service and no team layer, and it is an honest reference implementation rather than a product.
For one developer who wants durable scratch memory on one machine, it is the smaller and better answer, and adopting a platform instead is overhead. It is worth trying before you evaluate anything on this list, if only to find out how much of your problem it solves.
The other baseline is the file you already have. A checked-in `CLAUDE.md` or `AGENTS.md` is genuinely the right answer for one person, one repository, one agent and conventions that fit on a page. Every tool here is solving a problem you may not have yet.
Why delivery timing decides more than feature count
Almost every tool above retrieves on request: something calls a search, and matching text comes back. That is correct when the caller knows what it is looking for, which is true when your own application makes the call.
It breaks in a specific way for a coding agent. The agent asks about things it knows to wonder about. It does not ask about a convention it has never heard of, because nothing in the prompt raises the question. So the knowledge most worth having, the constraint that would have prevented the mistake, is the knowledge least likely to be retrieved. There is no error and no empty result. The agent simply writes something plausible and wrong.
Pushing knowledge before the agent acts closes that gap, and it costs something: it requires a runtime on the machine that can see the working directory and take part in the agent's startup, which a hosted API cannot do. That is the actual trade, and it is worth stating plainly rather than scoring as a feature.
Where Pathrule is the wrong choice
If what you need is memory about a **user** rather than about a codebase, do not use Pathrule. A support agent that should remember a customer's history, a chat product that should remember preferences, an assistant that should track how a person's situation changed over months: those are Mem0, Zep or Supermemory problems, and Pathrule has no answer for them. Its unit is a repository path, which is precisely the wrong unit for a person.
If you are **building the agent itself** rather than feeding one, Letta is closer to what you want. Pathrule assumes the agent already exists and that you did not write it.
And if you are one person on one repository with one agent, the honest answer is that you do not need any of this yet. The break point is the second agent or the second person, whichever arrives first.
How to choose without reading six pricing pages
Start from the unit, not the feature list. If the thing you want remembered is best described as *about this person*, you want a memory API. If it is *about this subject over time*, Zep's temporal model is the one designed for it. If it is *about this part of this codebase*, you want project knowledge keyed to the code, which means ByteRover or Pathrule.
Then ask when it has to arrive. If your own code makes the call, request-time retrieval is fine and you have the widest choice. If an autonomous coding agent has to receive a constraint it would never think to ask for, you need delivery before it acts, and that narrows the list considerably.
The rest, semantic search quality, self-hosting, storage format, matters after those two answers, not before. Getting the unit and the timing right is most of the decision.