AI Agent Memory, Rebuilt: The SuperLocalMemory Relaunch
SuperLocalMemory is relaunched: one governed, local-first memory brain for Claude Code, Codex, Cursor, ChatGPT and every agent that speaks MCP or runs a command.

A coding agent tells you it remembers how your deployment works.
You ask it how to roll back the API. It searches the memory available to it, finds the nearest-looking note, and confidently gives you an answer.
There is one problem: the note is related to deployment, but it does not actually answer the rollback question.
That failure mode is easy to miss because the retrieval layer did exactly what it was designed to do. It returned the closest match. The model did what models are trained to do. It completed the answer.
The system still failed.
That is the problem I have been trying to solve with SuperLocalMemory. Not simply how to make an AI agent remember more, but how to make persistent memory safe enough to build on: local-first where that boundary matters, shared across the agents you actually use, explicit about time and scope, governable like durable company state, and honest when the stored evidence does not answer the question.
This relaunch is the clearest expression of that idea so far.
SuperLocalMemory is one governed memory brain for Claude Code, Codex, Cursor, GitHub Copilot, Antigravity, Hermes, ChatGPT, Claude on the web, Grok Bot, Muse, and any harness that can speak MCP or run a command. It stores decisions, facts, documents, screenshots and project context on infrastructure you control; several agents can use the same memory; and recall can say, plainly, “That isn’t in SuperLocalMemory.”
That last sentence matters more than it sounds.

Memory is becoming infrastructure
A year ago, persistent memory still looked like an optional convenience around an AI product. In 2026 it looks much more like infrastructure.
The reason is not that models suddenly became forgetful. Models have always operated inside bounded context. The difference is that agents now work across repositories, terminals, browsers, background jobs and other agents. They act over longer periods and through more tools. State that was once safely trapped inside one chat is now operational input to later work.
The surrounding ecosystem has also standardized. Anthropic reported in December 2025 that there were more than 10,000 active public MCP servers, that MCP had been adopted by ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code, and that the Python and TypeScript SDKs together were seeing 97 million-plus monthly downloads. MCP has since been donated to the Linux Foundation’s Agentic AI Foundation, co-founded by Anthropic, Block and OpenAI. Source
That changes the memory problem. Once tools and agents can connect through a common protocol, memory should not have to be rebuilt separately for every host.
At the same time, governance expectations are getting less theoretical. Most EU AI Act rules apply from August 2026, and from 2 August 2026 the EU AI Office and national authorities supervise and enforce the Act, including the general-purpose AI obligations that took effect in August 2025. That does not mean installing a memory product makes a deployment compliant; it means technical documentation, risk boundaries, data handling and traceability are moving from “nice to have” language into the operating environment around AI systems. European Commission
So I no longer think the useful question is:
How do I give my agent a vector database?
The useful question is:
What should a durable memory layer be allowed to remember, retrieve, share, change and claim?
That is a much harder system.
What changed in SuperLocalMemory
The best way to explain the relaunch is through twelve concrete capabilities. I call them superpowers internally, but they are really twelve places where “persistent storage” stops being enough.
1. It knows when it does not know
A nearest neighbour is not automatically evidence.
SuperLocalMemory recall has three result tiers: supported, related, and none. A supported result has enough evidence to be served as an answer candidate. A related result is shown as the closest material without pretending it answered the question. When nothing is close enough, recall returns no result and says: “That isn’t in SuperLocalMemory.”
That distinction exists in the retrieval layer itself. It is not a prompt asking the final LLM to “be careful.”

The current recall documentation also distinguishes a warming system from an empty memory. While models or the graph are still loading, SLM says results may be incomplete instead of falsely concluding that nothing exists. Recall documentation
2. It can ask a second question: does this actually answer the user?
Relevance and answerability are different.
Answer Check reads the question and the strongest retrieved memories together, then judges whether those memories answer the question rather than merely resemble it. On Apple Silicon, the Laya checker can run on-device. An online Jev option exists for users who explicitly choose it and accept the documented data boundary.
The important design choice is that the check is a second layer, not a replacement for retrieval. The first layer retrieves and gates evidence. The second layer handles the harder case: a realistic, on-topic question for which memory contains something related but not sufficient.

This is the memory equivalent of a type check after parsing: finding something syntactically plausible is not enough. The system needs a separate decision about whether it satisfies the contract. Answer Check documentation
3. Pictures and PDFs become queryable memory
A lot of durable project knowledge never arrives as clean text. It arrives as a screenshot, a slide, a diagram, a PDF page or an image pasted into a chat.
SuperLocalMemory can optionally index pictures and PDF pages using Google’s EmbeddingGemma 2 on the local machine, with local OCR alongside visual embeddings. Each PDF page can be retrieved by what it says and by what it looks like. The media path is opt-in and documented with explicit RAM, disk and file-size limits.

The useful interaction is not “open file 8F4A2.pdf.” It is “find the slide with the quarterly numbers” or “show me the architecture diagram we discussed last month.” Pictures and documents documentation
4. Documents can become an organised knowledge layer without giving up search
Andrej Karpathy’s LLM-wiki pattern is compelling because raw documents are often more useful after they have been organised into an index that an agent can navigate.
SLM applies the same idea to the material already in memory. Documents can be represented through people, projects, dates and other entities while hybrid recall remains available for direct search. This is not a choice between “wiki” and “RAG.” The index helps an agent understand the collection; retrieval still helps it find the exact evidence.

5. Memory has a health system
Memory degrades even when the database is healthy.
Old entries may be missing dates, tags, entities, kinds or other structure. The Memory Health worker fills safe gaps while the computer is idle. Its core rule is intentionally narrow: background maintenance only adds. It does not silently rewrite what you saved, replace user-set values, or delete material.
Repairs that move or remove anything wait for an explicit Fix action, and reversible repairs can be undone.

That makes maintenance a governed operation instead of a hidden cleanup job. Memory Health documentation
6. It is governed, not merely stored
Persistent state needs access rules.
SuperLocalMemory supports personal, shared and global scopes, profiles, role-based controls, write admission, provenance and a hash-chained audit trail. Erasure operations are designed to propagate through the places a memory can leave copies: relational rows, full-text search, vector indexes, graph state, queues, caches, media and other derived projections.

There is an important boundary here: these are technical controls that can support a compliance program. They are not a certification and not legal advice. Whether a deployment satisfies GDPR, the EU AI Act, HIPAA, SOC 2 or another regime depends on the surrounding system, operator, configuration and procedures. The project’s compliance documentation states that explicitly. Compliance controls and limits
7. Memory has a sense of time
A fact can be true and later become stale without becoming false historically.
SuperLocalMemory records when a fact was valid and when the system learned it. Recall can ask what was true at a point in time or what SLM knew as of a date. Corrections can replace old facts without erasing their history.
That means these are different questions:
- What database do we use now?
- What database did we use during the April incident?
- What did the agent know before the migration decision was recorded?
A vector similarity score cannot answer those distinctions by itself.

8. It controls how much memory enters the context window
Long-term memory can solve one context problem and create another.
SLM’s layered recall lets a caller request a cheap glance, the facts, or deeper surrounding context. A hard token budget can cap the returned material, and an agent can expand a particular result only when it needs more.
The design goal is simple: persistent memory should not become a mechanism for flooding every new prompt with everything the system has ever learned.

9. Many agents can use one brain
The human should not have to be the message bus between Claude Code, Codex, Cursor and a background agent.
Each SLM write records provenance about the agent that produced it. Multiple hosts can recall from the same scoped memory instead of building isolated, conflicting histories.

The practical benefit is boring and enormous: a decision discovered by one agent can survive long enough for another agent to use it later without the human re-explaining the project.
10. Agents can coordinate through the mesh
Shared memory is not the same as communication.
SLM-Mesh lets trusted agents exchange messages, waits, locks and shared state across a machine or between configured peers. Connected web apps can also participate when the owner explicitly enables access.

Messages from another bot are treated as data rather than privileged instructions. That sounds like a small implementation rule; it is the difference between “another agent said this” and “the system told me to execute this.”

11. It can learn without quietly making itself worse
A memory system that never learns will eventually feel static. A memory system that learns without a rollback discipline can degrade invisibly.
SuperLocalMemory can learn from reported outcomes, adjust ranking, carry stable working habits into future sessions, and measure skill evolution. New ranking behaviour is evaluated before promotion and watched after promotion; regressions can trigger rollback.

This is the pattern I care about across AI Reliability Engineering: improvement is allowed inside a bounded system that can prove when the change was beneficial and reverse it when it was not.
12. Long-running work can be bounded by evidence, not by the agent saying “done”
Persistent memory becomes especially useful when an agent works through several attempts.
SuperLocalMemory integrates with Bounded Loops so repeated agent work can end on an independently checked gate rather than the model’s own confidence. Finished loop evidence can be retained as read-only memory.

Memory answers used by those loops respect the same answerability rules. If a recall is judged insufficient, it cannot silently pass the loop’s memory gate.
This is the architecture underneath it
The important part of the relaunch is that these capabilities are not twelve isolated buttons.
They sit on one local-first control plane: canonical local storage, several retrieval channels, provenance, temporal state, governance, optional media memory, learning and mesh coordination exposed through CLI, MCP, the dashboard, plugins and framework adapters.

The project’s current architecture keeps SQLite plus its vector extension as canonical state and treats other engines as projections rather than pretending a peer mesh is a magically consistent distributed database. That distinction matters. Reliability usually comes from being explicit about which copy is authoritative.
The AI memory market changed too
SuperLocalMemory is not the only serious memory system. The category improved quickly during 2026, and a useful comparison has to reflect that.
Mem0’s OpenMemory provides local-first memory across MCP clients and a dashboard. Mem0’s managed platform added a new token-efficient algorithm in 2026 and reports 92.5 on its LoCoMo protocol, while explicitly noting that the managed results include proprietary optimisations and that benchmark comparisons depend on protocol. Zep’s Graphiti is a strong temporal knowledge graph with vector, full-text and graph retrieval; Zep reports 94.7 on its LoCoMo methodology. Supermemory combines memory and multimodal context infrastructure with local/self-hosted options and strong managed-service features. Basic Memory is an excellent local-first, Markdown-based MCP knowledge system. Cognee builds agent memory around semantic graphs. Letta focuses on stateful agents and structured memory blocks. LangMem gives developers composable memory-management primitives inside LangGraph-style applications.
Those products are not interchangeable, and their benchmark numbers are not a leaderboard unless the datasets, subsets, answer models, judges and token budgets match.

| System | Local / self-host | Shared across AI clients | MCP | Temporal / graph | Multimodal memory | Governance | Explicit answerability / abstention |
|---|---|---|---|---|---|---|---|
| SuperLocalMemory | Local-first; Mode A core recall/remember has no model-provider call | Yes | Yes | Bi-temporal + graph + multi-channel recall | Pictures + PDFs, opt-in | Profiles, scopes, roles, provenance, audit, verified erasure controls | Yes: supported / related / none + optional Answer Check |
| Mem0 / OpenMemory | OpenMemory runs locally; current setup docs use an OpenAI key | Yes across MCP clients | Yes | Mem0 platform documents entity and temporal retrieval | Not documented as an OpenMemory-local feature in the sources reviewed | Dashboard client controls; managed Enterprise adds on-prem and audit logs | Benchmark includes abstention; explicit user-facing answer gate not documented in sources reviewed |
| Zep / Graphiti | Graphiti is open source; Zep managed/BYOC options vary by plan | Memory MCP Server seats on managed plans | Yes | Strong temporal Context Graph | Not documented in reviewed memory docs | Enterprise audit/API logs, SOC 2, HIPAA BAA | Not documented as a separate abstention gate |
| Letta | Cloud or self-hosted server | Memory blocks can be shared across agents | MCP tooling exists, but cross-client memory-server parity was not documented in reviewed sources | Structured blocks + archival memory; not a temporal graph in reviewed docs | Not documented as a memory primitive | Attach/detach shared blocks; broader enterprise controls depend on deployment | Not documented |
| Supermemory | OSS can run locally; managed plans add hosted/self-host options | Plugins and MCP | Yes | Memory graph / hierarchy | Yes: text, images, PDFs, audio, video in managed SuperRAG | Scale/Enterprise adds per-tag access, GDPR, SOC 2, HIPAA, enterprise MCP | Not documented |
| Cognee | Local open source supported; model/provider configuration varies | Yes through integrations/MCP | Yes | Knowledge graph / semantic layer | Documents supported; image-memory parity not established in reviewed sources | Fine-grained governed memory not documented in reviewed OSS material | Not documented |
| Basic Memory | Yes; plain Markdown, air-gapped friendly | Yes | Yes | Knowledge graph + semantic/hybrid search | Text/Markdown centred | Team/cloud sharing exists; fine-grained audit/erasure layer not documented in README | Not documented |
| LangMem | A library inside your application | Application-defined | No native memory server | Application/storage-defined | Application-defined | Application-defined | Application-defined |
| Claude / Claude Code built-ins | Claude Code uses local CLAUDE.md; Claude app memory is provider-side |
No cross-vendor memory layer | Claude can consume MCP, but built-in memory is not a portable MCP server | Project/chat memory, not a documented temporal knowledge graph | Files can be context; not a local multimodal memory engine | Provider/workspace controls | No documented retrieval abstention layer |
| ChatGPT built-in memory | Provider-side | Shared projects inside ChatGPT, not cross-vendor | ChatGPT supports MCP apps, but personal memory is not exposed as a portable memory server | Improved memory updates over time; no user-hosted temporal graph | Files can contribute to context and memory sources | Workspace/project controls and source management | No documented retrieval-specific abstention gate |
The longer source-by-source competitor research is included in the launch package as research/competitor-analysis.md.
Where I would not use SuperLocalMemory
A comparison is not useful unless it also tells you where the product is the wrong fit.
I would not choose SLM if the primary requirement were “give me a fully managed memory API and I do not want to operate anything locally.” Mem0, Zep or Supermemory may be a cleaner fit depending on the workload.
I would not choose it if the desired source of truth is human-readable Markdown edited directly by people all day. Basic Memory is deliberately built around that model.
I would not choose it if I were already committed to a stateful-agent architecture in which the agent itself actively manages structured memory blocks as part of its runtime. Letta is designed around that idea.
And I would not deploy any persistent memory layer merely because a benchmark number looked higher. Memory quality is only one axis. The trust boundary, deletion behaviour, observability, model dependency, cost, latency, portability and failure semantics all matter once an agent is allowed to act.
Four research papers, with the benchmark boundary left intact
SuperLocalMemory is backed by four public arXiv preprints covering multi-agent trust, information-geometric retrieval, biologically inspired memory lifecycle and governed memory operations.
The public V3 LoCoMo evidence reports:
- 74.8%: SuperLocalMemory local retrieval across 10 conversations / 1,276 questions with GPT-4.1-mini constructing the final answers.
- 60.4%: SuperLocalMemory in a zero-LLM raw-answer configuration across the same 10 conversations / 1,276 questions.
- 87.7%: SuperLocalMemory in a cloud-assisted configuration on one disclosed conversation (81 questions).
Those scopes matter. The 87.7 number is not a full-dataset result, and the project documentation explicitly says a LoCoMo score is comparable only when subset, answer model and judge match. Benchmark notes
The papers are:
- SuperLocalMemory 4.0: The Governed Memory Operating System for AI Agents
- SuperLocalMemory V3.3: The Living Brain
- SuperLocalMemory V3: Information-Geometric Foundations for Zero-LLM Enterprise Agent Memory
- SuperLocalMemory: Privacy-Preserving Multi-Agent Memory with Bayesian Trust Defense Against Memory Poisoning
I care about the papers because they force us to state the mechanism and the measurement. They are not a substitute for using the product and inspecting the code.
Install it in minutes
The primary install route is npm, with pipx also supported:
npm install -g superlocalmemory
slm setup
slm connect cursor
Mode A is the simplest trust boundary: core remember and recall can run without a model-provider call. You can then connect other hosts such as Codex, Claude Code, Windsurf, Zed, JetBrains and others through the documented connector flow.
For an agent performing the installation, the repository also includes a numbered, non-interactive SETUP_FOR_AGENTS.md that describes initialization, daemon startup, warmup, host connection and the expected session discipline.
The repository is AGPL-3.0-or-later with a commercial-license option. GitHub
Watch Claude Code and Codex share one memory
The full product demo is already live:
Claude Code + Codex, One Shared Memory — Local MCP Demo | SuperLocalMemory Demo
The point of the demo is intentionally mundane: two different coding agents should not require two different truths about the same project.
The larger idea: AI Reliability Engineering
I use the phrase AI Reliability Engineering for a specific reason.
Prompt engineering asks how to elicit a better response from a model.
Reliability engineering asks what happens when the response is wrong, incomplete, stale, unauthorized, unverified or produced by a component that is not ready yet.
SuperLocalMemory applies that discipline to state. Jev applies it to independent answer checking. Bounded Loops applies it to long-running work. The common pattern is not “use more AI.” It is put explicit contracts around AI behaviour, measure the contracts, and fail safely when the evidence is not there.

The goal is not perfect memory.
Perfect memory would be a liability. It would preserve noise, stale state and bad instructions forever.
The goal is memory that can answer four questions before an agent acts on it:
What do we know?
When was it true?
Who is allowed to use it?
Does it actually answer the question?
That is the SuperLocalMemory relaunch.
Star SuperLocalMemory on GitHub · Watch the demo · Read how AI memory actually works · Read the memory governance paper explainer
About the author: Varun Pratap Bhardwaj builds AI Reliability Engineering tools at Qualixar.
This post is about superlocalmemory →
Varun Pratap Bhardwaj builds AI Reliability Engineering tools at Qualixar. ORCID 0009-0002-8726-4289