MemMesh: a local Rust memory engine for AI agents, wired in through MCP

The problem MemMesh targets: memory that survives the session boundary

Agent frameworks usually treat memory as an integration problem. A hosted vector store holds the embeddings, an extraction call runs per message to decide what is worth keeping, and the bill scales with how much the agent remembers. The README frames MemMesh as the opposite path: one binary, one file, everything local. The claim is that the runtime is a single Rust binary backed by SQLite or Postgres, that retrieval is semantic plus keyword hybrid using local embeddings, and that no API calls leave the box. The audience is narrow and specific. It is engineers running MCP-capable coding tools (Claude Code, Cursor, Windsurf, Codex CLI) who want the assistant to remember preferences and decisions across sessions without shipping those preferences to a third party. If you are building a multi-tenant SaaS agent where memory must be shared across users and audited centrally, the local-first design is working against you rather than for you.

How capture works: heuristics on the write path, embeddings on the read path

The core mechanism is a split between how memories enter the store and how they come back out. On the write side, memmesh observe accepts raw text and runs what the README calls a heuristic filter, keeping preferences, decisions and facts while dropping conversational filler. No LLM is involved in that step. On the read side, search runs semantic plus keyword matching, which is why the quickstart example stores the sentence "Ryan prefers pnpm over npm for all projects." and then retrieves it with the query "which package manager", a query that shares no words with the stored sentence. Two details in the design are worth naming. First, the time model is bi-temporal: the engine distinguishes when something happened from when you learned it. Second, recall reinforces: memory_recall fetches by id and, per the MCP tool table, reinforces the item on access. Corrections are handled by memory_supersede, which keeps the old item for provenance rather than overwriting it, and memory_consolidate collapses near-duplicates into a survivor as a non-destructive supersede with dry-run support. That is a provenance-first design. It costs storage and it means your store grows monotonically unless you delete, but it also means a wrong correction is recoverable.

The local embedding model and the egress boundary

Semantic search depends on a local embedding model. The README states that the first observe or search downloads bge-small, roughly 130 MB, into the MemMesh cache, once, with no API key. That download is the real setup cost, and it is the kind of thing that fails quietly on an air-gapped machine or a locked-down CI runner. There is an escape hatch: setting [embeddings] provider = "none" switches the engine to pure keyword plus recency. That is a genuine trade-off, not a footnote. With embeddings disabled, the pnpm example above stops working, because keyword matching cannot bridge "which package manager" and "pnpm over npm". You get a smaller, fully offline binary and a strictly worse recall path. The README also notes that knowledge-graph extraction exists as a client-side operation: memory_extract_pending and memory_commit_extraction let your own model, your key, your rate limit do the extraction, with the stated position that the engine never calls an LLM. That is consistent with the local-first claim, and it also means extraction quality is your problem, not the project's.

Installing it: one command, several config files, and hooks you can decline

The install path is a shell script or a PowerShell one-liner, or cargo build --release --bin memmesh from source. The interesting command is memmesh install, which detects each supported tool, merges an MCP server block into its config without touching your other MCP servers, and places a teaching skill. The README lists the exact targets: ~/.claude.json and ~/.claude/skills/memmesh/SKILL.md for Claude Code, ~/.cursor/mcp.json and ~/.cursor/rules/memmesh/SKILL.md for Cursor, ~/.codeium/windsurf/mcp_config.json for Windsurf, and ~/.codex/config.toml for Codex CLI. Windsurf and Codex get MCP tool descriptions rather than a skill file. Flags matter here: --dry-run previews the merge, --tool <id> is repeatable and limits which tools are touched, --mcp-only skips the skill, --no-hooks skips the Claude Code auto-observe hook, and --force overrides. The CLI itself defaults to ~/.memmesh/memory.db, overridable with --db <path>. Other commands in the README include memmesh migrate (idempotent), memmesh save with --platform, --project, --type and --content, memmesh get <id>, memmesh search with --query, --project and --limit, and memmesh consolidate --dry-run. Restart the host tool afterward so it reloads its config.

The hook pattern is the part worth copying, and the part worth scrutinising

On Claude Code, install wires two hooks. UserPromptSubmit pipes every prompt to memmesh observe, and SessionStart runs memmesh search --format claude-context to inject relevant memories when a new session opens. The README's framing is to fire the whole conversation at memory and let the engine curate it, so the agent does not have to decide what is worth remembering. This is the most opinionated decision in the project. It means every prompt you type is written to a local database by default, filtered by heuristics you cannot inspect from the README alone. The filter is described only as keeping substantive bits and dropping filler, with no detail on its rules or its false-positive behaviour. If you work with client data, regulated material, or secrets that occasionally end up pasted into a prompt, that default deserves a deliberate decision rather than an inherited one. --no-hooks exists for exactly this reason, and the README notes the same pattern can be wired manually elsewhere by piping raw text to memmesh observe --json and reading memmesh search --format claude-context.

What is not in the open-source engine

The MCP tool table is split into two groups, and the split is the most important thing to read before adopting. The open-source engine covers the full local lifecycle: observe, save, recall, search, list, delete, supersede, consolidate, stats, and the two client-LLM extraction tools. The hosted group at memmesh.ai is labelled the intelligence layer and contains memory_graph_reason for multi-hop reasoning over the knowledge graph, memory_query_graph for point-in-time bi-temporal edge queries, memory_prefetch_related for anticipatory retrieval via spreading activation, and memory_build_context, whose description is truncated in the supplied README. So the bi-temporal storage model is in the local engine, but querying it as a graph at a point in time is not. If your use case is "remember my package manager preference and my project decisions", the local engine is sufficient. If your use case is "reason across a chain of related facts from last quarter", you are looking at the hosted tier, and the local-first privacy argument stops applying at that boundary. The README does not state what the hosted tier costs or what data it receives, and that is a gap, not a detail.

Alternatives and the actual difference in approach

The obvious comparison is a hosted vector store wired into an agent framework: Pinecone, Weaviate, Qdrant Cloud, or whichever managed option your stack already uses. The difference is not speed or recall quality, neither of which the README quantifies. The difference is where the extraction decision happens and where the bytes live. A hosted stack typically runs an LLM extraction call per message to decide what to store, which means a per-message cost and a network round trip on the write path. MemMesh replaces that with a local heuristic filter, which is cheaper and private but also dumber: a heuristic cannot resolve an ambiguous statement the way a model can, and the README gives no way to audit or tune it. The second comparison is a plain SQLite table with a hand-rolled search query. That gets you durability and zero dependencies. What it does not get you is hybrid retrieval, the bi-temporal columns, supersede-with-provenance, or the MCP surface that makes Claude Code and Cursor treat memory as a tool rather than a script you invoke yourself. The third comparison is an agent framework's built-in memory module, which is convenient but ties the store to that framework. MemMesh's bet is that MCP is the durable interface, so the same store serves four different hosts.

Version maturity, upgrade cost and licence

The release history is short: v0.1.0 and v0.1.1 on 2026-07-22, then v0.1.2 on 2026-08-06, with the last push to main on 2026-08-25. This is pre-1.0 software with three releases, and the README does not describe a migration or compatibility policy across versions. The one relevant signal is that memmesh migrate is documented as safe to repeat, which suggests schema changes are expected and handled through re-applied migrations rather than manual steps. That is a reasonable posture, but it is not the same as a stability guarantee, and anyone storing months of agent memory in ~/.memmesh/memory.db should back that file up before upgrading. The licence is Apache-2.0, which permits commercial use, modification and redistribution with the usual notice and attribution conditions; the README describes it as having no limits, which is a marketing phrase rather than a legal one. If you embed the binary in a product you ship, read the licence text itself. Nothing in the supplied material indicates a separate licence for the hosted tier, and that is worth confirming before you build on it.

Editorial conclusion

Adopt MemMesh if you run Claude Code, Cursor, Windsurf or Codex CLI on a machine where prompts must stay on disk, and you want capture to happen without an extraction call per message. Do not adopt it if you need multi-hop graph reasoning today: memory_graph_reason, memory_query_graph and memory_prefetch_related are listed under hosted mode at memmesh.ai, not in the open-source engine. Before committing, run memmesh install --dry-run to see exactly which config files it will touch, then confirm that the ~130 MB bge-small download is acceptable on your network and that the Apache-2.0 terms fit how you redistribute the binary.

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. ThinkfleetAI/memmesh on GitHub