Your AI agents forget in three places. Only one of them is the model.

Ask your coding agent what you decided about the billing database last month. If it shrugs, the usual diagnosis is "LLMs don't have memory." That is true, and it explains very little. The model was never going to remember. The question worth asking is where the memory around the model went, and the answer is usually one of three places.

Place 1: the session

Every agent keeps a transcript of the current conversation, and most tools treat that transcript as a cache, not a record.

Claude Code is a good, well-documented example. Its documentation says it stores session transcripts locally under ~/.claude/projects/ for 30 days by default, so you can resume recent work, and deletes older ones when it starts up. The retention is set by cleanupPeriodDays (data usage, the .claude directory). That is a reasonable privacy default. It also means a conversation from three months ago, and the reasoning inside it, is gone unless something else captured it.

If you want to keep transcripts longer, the fix is one setting in ~/.claude/settings.json:

{ "cleanupPeriodDays": 365 }

The minimum is 1; a value of 0 is rejected. Other agents have their own retention rules, so check yours.

Place 2: the project

The second layer is the memory your tools do keep on purpose. Claude Code reads CLAUDE.md files and writes its own notes in auto memory; many agents read AGENTS.md. These are excellent for rules: how to run tests, which style to follow, what never to touch.

Their scope is the problem. Claude Code's docs describe auto memory as per repository, stored under ~/.claude/projects/<project>/memory/ (memory docs). Rules written for one repository don't follow you into the next one, and decisions made while working across several projects have no natural home. Project memory is a filing cabinet bolted to one desk.

Place 3: across agents and people

The third place hurts as a stack grows. If you use more than one agent, say Claude Code in the terminal, Codex for a second opinion, Cursor in the editor and a bot in Slack, each one keeps its own memory in its own format. A new agent added to the stack starts at day zero, and a teammate's agent knows nothing your agent learned.

The workaround is copying: paste the rules file into the new tool, re-explain the architecture, repeat the decision about the billing database. It works for two tools and one person. It does not scale to five tools or a team.

Five questions to ask any memory layer

A dedicated memory layer exists to close one or more of those three gaps. Before choosing one, these five questions separate them faster than any feature list:

1. Where does the memory live? On your machine, in the vendor's cloud, or in your own cloud account. This decides privacy, latency and who can be compelled to hand it over.
2. Who shares it? One user, one agent, every agent on a machine, or a whole organisation with access rules.
3. Does it track how facts change? "The budget is 40k" is only useful if you also know it was 32k last month and which one is current.
4. Can it show the source? A memory you can't trace back to the conversation, email or file it came from is a rumour.
5. Can it say "not in memory"? A memory layer that always returns something will feed your agent confident nonsense when the answer was never stored.

Six systems, one template

Here are six systems people reach for in 2026, in alphabetical order, each described with the same template: what it says it is, where its memory lives, what it suits, and one honest limitation.

Letta

• What it is: "Build stateful agents with memory that can learn and improve over time" (formerly MemGPT) (GitHub).
• Where memory lives: Letta Cloud, the desktop app, or self-hosted with letta server; local agents commit memory to a local git repo (MemFS docs).
• Sharing: Each agent has its own memory, shared across that agent's conversations; organisation-wide shared memory repositories need cloud-hosted agents (shared memory).
• Change tracking and sources: Memory is git-backed Markdown: edits stay local until committed and pushed, and committed changes keep a version history.
• Interfaces: Letta Code CLI, a JavaScript/TypeScript Agent SDK, REST, desktop app and chat channels.
• Suits: Building agents that manage and improve their own memory, such as coding agents and AI coworkers.
• Limitation: It is an agent runtime more than a drop-in memory API, so adopting it is a bigger shift, and an independent review notes costs are hard to forecast (Digital Applied).

Mem0

• What it is: "The Memory Layer for AI Agents… Drop-in memory infrastructure for AI agents and apps" (GitHub).
• Where memory lives: Mem0's cloud platform, self-hosted open source (library or Docker), or on-prem and air-gapped on Enterprise (platform vs open source).
• Sharing: Memories are scoped by user, agent, app and run; the platform adds organisations and projects with member roles (entity-scoped memory).
• Change tracking and sources: Retrieval is time-aware, and memories can be explicitly updated or deleted; I couldn't find documentation of how a memory links back to its source (how it works).
• Interfaces: Python and JS/TS SDKs, a CLI, REST, and a hosted MCP server documented for Claude Code, Cursor, Codex and others (Mem0 MCP).
• Suits: Teams that want a drop-in memory layer with the largest community of the six.
• Limitation: Graph memory, decay and temporal reasoning are platform features; the open-source version doesn't include them (platform vs open source).

past.dev

• What it is: "Long-term memory for AI agents": a managed API where you send text with its original timestamp (emails, meetings, chats, documents) and recall ranked evidence with dates and sources (past.dev).
• Where memory lives: Managed cloud, or your own AWS, Google Cloud or Azure account on an Enterprise agreement.
• Sharing: Built for "multiplayer" agents: audience filtering means each identity recalls only what it is allowed to see.
• Change tracking and sources: Tracks the current and previous value of a fact, with the date and source of each.
• Interfaces: REST, plus remote MCP servers that work with clients such as Claude Code, Cursor and VS Code (MCP docs).
• Suits: Teams building agents over large volumes of company email, meetings and documents, where who-can-see-what matters.
• Limitation: The newest of the six, with no public source code for the product and no independent benchmark reproduction yet; its methodology page also notes recall lags until ingestion completes (methodology).

SuperLocalMemory

• What it is: "The governed memory brain for every AI agent. It lives on your machine. It never bluffs" (GitHub).
• Where memory lives: Your machine; the basic mode needs no LLM or API key.
• Sharing: Every agent connected over MCP or CLI shares one memory, with scopes and roles. Through SLM-Mesh, local agents and the web bots you allow (ChatGPT, Claude on the web) message each other, while the memory itself stays on your machine.
• Change tracking and sources: Bi-temporal facts, the writing agent on every memory, and a hash-chained audit trail (V4 paper). Recall can answer "That isn't in SuperLocalMemory", and an answer check (Laya on-device, or Jev online) judges whether results answer the question.
• Interfaces: MCP, CLI, REST, dashboard; screenshots and PDFs searchable through Google's EmbeddingGemma 2 running locally.
• Suits: Developers running several agents who want one memory on their own machine.
• Limitation: Smallest community of the six, no hosted service, and published LoCoMo scores from an earlier version that sit below other vendors' numbers.

Supermemory

• What it is: "The default engine for memory and continual learning for agents" (supermemory.ai).
• Where memory lives: Hosted API, your VPC or on-prem on higher tiers, or a local server (npx supermemory local) (self-hosting).
• Sharing: Every call is scoped to a namespace, typically one per end user or project; the Scale plan adds team seats with per-tag access (pricing).
• Change tracking and sources: A memory graph marks when a new fact updates an old one (isLatest), while derived memories keep their source chunks (graph memory).
• Interfaces: TypeScript and Python SDKs, REST, a hosted MCP server, plugins for Claude Code, Cursor and Codex, and connectors for Drive, Gmail, Notion and GitHub (GitHub).
• Suits: Memory and document retrieval in one system, fed by connectors.
• Limitation: The local server binary is not open source and lacks the connectors and MCP server of the hosted version (self-hosting).

Zep

• What it is: "The unified context layer for enterprise data", built on the open-source Graphiti temporal graph framework (getzep.com, Graphiti).
• Where memory lives: Zep Cloud, cloud with your own keys, or your own VPC on Enterprise; the open-source path is Graphiti plus your own graph database (pricing).
• Sharing: A graph per user plus shared graphs for team or domain context, with user groups and policy-based access control (concepts).
• Change tracking and sources: The most explicit of the six: every fact carries four timestamps, newer facts can invalidate older ones, and each fact traces back to the raw data that produced it (facts).
• Interfaces: Python, TypeScript and Go SDKs, REST, and an MCP server in Graphiti.
• Suits: Enterprise agents that need point-in-time facts and governance.
• Limitation: No turnkey free self-hosted version of the full platform anymore; with Graphiti you build users, threads and governance yourself (Zep vs Graphiti).

The comparison table

"Not documented" means I couldn't find it in the system's public docs when I checked in October 2026, not that the feature is impossible.

A note on benchmarks

You will notice there is no ranking here. That is deliberate. These systems publish results on different benchmarks (LoCoMo, LongMemEval, BEAM), usually run by the vendor, with different underlying models and different judges. A higher number on one benchmark under one setup tells you little about the next. What each one publishes, all self-reported:

Independent reproductions are scarce, and the few I found, mostly published by competing vendors, report lower numbers than the vendors' own. Read every figure above as a claim made under specific conditions, and test on your own data before you trust any of them, including mine.

How to choose

Start from the gap that hurts. If it is the session, change the retention setting and you may not need anything else. If it is the project, a well-kept CLAUDE.md or AGENTS.md goes a long way. If it is across agents, decide where the memory should live first: on your own machine, in a vendor's cloud, or in your own cloud account. That one answer removes half the options. Then decide who shares it, and only then compare features.

Disclosure: I built SuperLocalMemory, one of the six systems above. I gave every system the same template and linked each to its own documentation. If I have described any of them wrongly, tell me in the comments and I'll correct it.