← All projects
BetaStarted June 2026

mem-local

A memory for AI assistants that lives on my own server, where I can see and approve everything it keeps.

  • SQLite
  • sqlite-vec
  • FTS5
  • MCP
An illustrative infographic titled "AI Memory, Built for Reality". Stacked versions of a customer record sit on a timeline on the left, a glowing brain labelled AI Memory is in the middle, and a proposed update with Approve and Reject buttons is on the right.

The problem

AI assistants forget everything between chats, and the memory they do offer is a black box I can't inspect or correct.

What I did

Built a local store with linked facts, keyword and semantic search, and history that's superseded rather than overwritten, served over MCP from a home server.

Where it is

In beta and in daily use across my own Claude projects. Nothing gets written without my approval.

A local, portable memory layer for AI conversations: SQLite underneath; sqlite-vec and FTS5 for retrieval (semantic search and keyword search, fused together); bi-temporal supersession, so nothing is ever overwritten; a human-approval write gate; and a six-tool MCP (Model Context Protocol — the standard Claude uses to call external tools) server running on a repurposed HP MicroServer. Built from June 2026 onward. Still evolving.

This is the reconstructed build history: what got decided, why, what got rejected along the way, and what’s still open. It draws on the full conversation record, the project’s own settled documentation (the decisions register, the as-built record, the gaps log), and the live mem-local store itself — checked against each other rather than any one of them taken as automatically right.

New to this project, or landing on one of these pages from somewhere else? Start with the glossary — it defines the jargon (FTS5, RRF, sqlite-vec, “the register”) and the one naming collision worth knowing about before Stage 2.

The timeline

  1. Origin & requirements — asking Claude what it lacked, before deciding anything
  2. Architecture decisions — eight decisions, four reversals, and two more that followed within the fortnight
  3. Research deep-dives — embeddings, entity resolution, and a fork base that failed inspection
  4. Build & setup — the practical, occasionally messy deployment
  5. Conventions & discipline — the small rules that keep the store honest
  6. Open questions / evolving edges — what’s still unresolved

Why X, not Y

Four standalone pieces on the decisions that most set this apart from other approaches — pulled together from across the timeline rather than repeated there.

Roadmap & how it works

  • Build roadmap — every stage the project has gone through, what’s live right now, and what’s still ahead, in one scannable list.
  • How it works, as a diagram — the write/read cycle and what it runs on, in one picture.
  • The graph shape — what a node and an edge actually carry, and a real corner of the graph pulled live from the store.
  • A bi-temporal fact, traced — one real decision, reversed twice in a day, followed through the log to show why neither version gets deleted.

Reconstructed from the claude.ai conversation export, the project’s own artefacts, and live queries against mem-local itself.