Mnemon: LLM-supervised persistent memory for AI agents, reviewed from the README

The problem Mnemon targets: agents that forget between sessions

The README opens with a plain statement of the failure it addresses: LLM agents forget everything between sessions, context compaction drops critical decisions, and long conversations push early information out of the window. That is a real class of problem for anyone running an agent across days rather than minutes. The compaction case is the sharpest one, because it happens inside a single session and is invisible until you notice the agent contradicting a decision it made an hour earlier.

Mnemon's answer is a persistent store the agent writes to and reads from, described as a four-graph knowledge store with intent-aware recall, importance decay and automatic deduplication. The intended audience is narrow and identifiable: people already running a coding agent with a hook mechanism, who want memory to survive session boundaries without wiring up a vector database and an embedding service themselves. The README frames memory as the component worth investing in, arguing that LLM engines iterate constantly and skill files cost almost nothing to write, while memory accumulates. That is an argument, not a measurement, and it should be read as positioning rather than evidence.

Why the host LLM does the judging instead of an embedded model

The architectural choice that separates Mnemon from most memory tools is stated directly in the README: the binary handles deterministic computation such as storage, graph indexing, search and decay, and the host LLM makes the judgment calls about what to remember, how to link and when to forget. The project calls this the LLM-supervised pattern and contrasts it with three others in a table: LLM-embedded tools where the model executes inside the pipeline (Mem0, Letta), file injection where a file is read at session start with no model involvement (Claude Code Memory), and MCP servers that expose tools over the protocol (claude-mem).

The practical consequence is that Mnemon adds no inference cost of its own. If you already pay for a Claude subscription, the README states the tool runs entirely through it with no separate API key. The trade-off is that memory quality now depends on the supervising model's judgment and on the hooks firing reliably. An embedded pipeline can be tuned and benchmarked in isolation; a supervised one inherits whatever the host model does on a given day. The README does not describe any evaluation of recall quality, so how well the supervision works in practice is not something this material can tell you.

The remember, link and recall protocol and what it replaces

Mnemon exposes three primitives: remember, link and recall. The README's argument for them is that command names map to the model's cognitive vocabulary rather than to database operations, so the LLM calls remember instead of INSERT and recall instead of SELECT, and receives structured JSON with signal transparency instead of raw rows. The stated motivation is a gap in the protocol stack: MCP standardizes how LLMs discover and invoke tools, and ODBC and JDBC standardize how applications reach databases, but the layer where an LLM interacts with a database using memory semantics has no protocol. Mnemon proposes its three primitives as that layer.

Whether a three-verb vocabulary constitutes a protocol is a fair thing to question. The README does not publish a wire format, a versioning scheme, or a conformance description, so at present these read as a CLI surface with a design rationale attached, not a specification other implementations could target. What the material does support is the graph model: the README shows a diagram captioned as a real knowledge graph with 87 insights and 2150 edges across four graph types, with edges described as temporal, entity, semantic and causal. Those four edge categories are the concrete part. The recall path is described as intent-aware and the store applies importance decay and deduplication, but the README does not give the decay function, the deduplication threshold, or the storage format, so those remain unverified from this material.

Installing Mnemon and wiring it into an agent runtime

The recommended install is npm, and the README states it works on macOS, Linux and Windows with Node.js 22 or newer. The npm package installs the matching native Go executable for the host OS and CPU; the engine remains a single native binary and Node is used only by the launcher and package manager. The command is npm install --global @mnemon-dev/mnemon, and upgrades afterwards go through mnemon update.

Alternatives are listed: brew install --cask mnemon-dev/tap/mnemon, go install github.com/mnemon-dev/mnemon@latest, and a source build via git clone followed by make install on macOS or Linux. The README is explicit that Homebrew, go install and source builds must keep using their original installation method, and that migrating one of them means running the npm install once and ensuring the npm global bin directory precedes the old executable on PATH, after which mnemon update is npm-managed. That PATH ordering requirement is the kind of detail that causes silent version confusion if skipped.

Runtime integration is where the commands get specific. For Claude Code, mnemon setup auto-detects the tool and interactively deploys skill, hooks and a behavioral guide. For Codex, mnemon setup --target codex --yes deploys the skill, prompt files and lifecycle hooks into .codex/hooks.json, with the README naming SessionStart, UserPromptSubmit and Stop as the hook events. For Cursor, mnemon setup --target cursor --yes writes to .cursor/ and the README says the integration primes new sessions with Mnemon guidance and memory status, then nudges for writeback after responses. For ZCode, the command is mnemon setup --target zcode --global --yes. Verification is two commands: mnemon --version and mnemon agency --version. Note that the README excerpt ends mid-sentence in the ZCode section, so anything beyond that point is not available here.

Agency is a second product sharing one binary

Mnemon ships one executable with two surfaces. Memory lives at the mnemon root; Agency lives at mnemon agency and is described as adding durable, project-local responsibility and effect admission to an existing Pi agent. The README states plainly that Agency does not replace Memory or the Agent Runtime, and that it is Preview software.

Setup is per project: mnemon agency setup --runtime pi --project-root . The README notes that Agency is independent from Memory, so enabling one does not enable the other. mnemon setup --target pi --yes enables Memory, while the agency setup command enables Agency. This is a distinction worth reading twice, because a user who runs the first command and expects the second capability will be confused.

The platform boundary is stated: Agency is available on macOS and Linux, and Windows supports only the core Memory commands. The README gives the reason, saying Agency remains unavailable on Windows until its local authority boundary has native Windows security. That is a specific and defensible constraint rather than a vague compatibility note, and it tells you the project treats the authority boundary as a security surface. The README points to docs/AGENCY.md for the operating model and the Preview compatibility boundary, which is where anyone evaluating Agency should start.

Where Mnemon is the wrong tool

The clearest limitation is that Mnemon is not self-contained. It depends on the host agent's hook lifecycle to function. If your runtime has no hook mechanism, or you run the agent in an environment where hooks cannot execute, the memory loop does not close and the binary has nothing to supervise. The README's supported list is Claude Code, Codex, Cursor, ZCode, Pi and the DeepSeek Harness, plus the claim of working with any agent runtime, but the setup commands shown are all hook deployments into vendor-specific directories, so the generic claim is not demonstrated in the material available.

Second, the storage layer is undocumented here. The README describes four graph types and importance decay but does not state where data lives, in what format, or how to export it. Anyone who needs to inspect memory outside the tool, or move it between machines, has no documented path in this material. Third, the release cadence visible in the metadata is tight: v0.2.6, v0.2.7 and v0.2.8 landed within roughly a week in late August and early September 2026. Frequent point releases at a 0.x version number are normal for active development, but they also mean the memory schema may still be moving, and the README does not describe a migration story for existing stores. If you are storing months of accumulated context, that is the risk to weigh. Fourth, Agency on Windows is simply not available, and the README gives no timeline.

How it differs from Mem0, Letta and claude-mem

The README's own comparison table is the most useful alternative analysis available. Mem0 and Letta are classified as LLM-embedded: the model executes inside the memory pipeline. That means the tool owns the inference, which makes behaviour more predictable and self-contained but adds a second model call path and its cost to every memory operation. Mnemon moves that inference to the host, so the binary stays deterministic and free of API keys, at the price of depending on the host's cooperation.

Claude Code Memory is classified as file injection: a file is read at session start with no LLM role at all. That approach is trivially transparent and debuggable, since the memory is a file you can open, and it costs nothing to run. Its ceiling is that nothing decides what deserves to be written or when an old entry has gone stale; the file grows and the session pays for all of it. claude-mem is classified as an MCP server, exposing memory as tools over the MCP protocol. That fits any MCP-capable client without vendor-specific hook files, which is a real portability advantage, but it puts memory retrieval in the model's tool-calling path rather than in the session lifecycle, so recall depends on the model choosing to call the tool.

Mnemon's position is that lifecycle hooks plus a supervising LLM plus a deterministic engine gets you automatic capture without an embedded model. The difference is not capability but where the judgment lives. If you want memory that works without the model deciding to use it, hooks are the stronger mechanism. If you want memory that works across any MCP client without per-vendor setup, an MCP server is the stronger mechanism.

Licence, maintenance and what to check before adopting

Mnemon is Apache-2.0 licensed, which permits commercial use, modification and redistribution with the usual conditions around notices and patent grants. This is a permissive licence and it is the same one used by most of the Go ecosystem, so there is no copyleft obligation to reason about here. That is a statement about the licence text, not legal advice; if you are embedding the binary in a product, have your own counsel read the NOTICE and patent clauses.

Maintenance cost is mostly the upgrade path. If you installed via npm, mnemon update handles it. If you installed via Homebrew, go install or a source build, the README says you must keep using that method, and switching to npm means running the npm install once and fixing PATH ordering so the npm global bin directory comes first. Teams with mixed install methods on the same machine should standardize before that becomes a support problem.

A second cost is the hook surface. Each mnemon setup --target ... command writes files into a vendor directory: .codex/hooks.json for Codex, .cursor/ for Cursor, and skill and prompt files elsewhere. Those files are now part of your repository or home directory and will need review when the tool changes them. The README does not describe an uninstall or rollback command, so before running setup on a shared project, check what it writes. Running mnemon setup --target codex --yes on a scratch repository first, then reading the generated .codex/hooks.json, is a cheap way to see the full footprint. The README excerpt supplied here is truncated inside the ZCode section, so consult the upstream README and docs/DESIGN.md for the parts beyond it.

Editorial conclusion

Adopt Mnemon if you already run Claude Code, Codex, Cursor, ZCode or Pi and want cross-session memory without adding an inference bill, since the README states the host LLM acts as supervisor and no separate API key is required. Do not adopt it if you need a documented storage format, a tested migration path between versions, or Agency on Windows, which the README says is unavailable until its local authority boundary has native Windows security. Before committing, verify three things yourself: run mnemon --version and mnemon agency --version after install to confirm both surfaces resolve on your PATH, inspect the hooks that mnemon setup --target codex --yes writes into .codex/hooks.json so you know what runs at SessionStart, UserPromptSubmit and Stop, and read docs/DESIGN.md to find out what the four graph types actually store, because the README does not specify the on-disk format.

Official sources

1. License: Apache-2.0
2. mnemon-dev/mnemon on GitHub
3. Project website
4. README
5. Releases