Engram Review: Persistent Memory for Claude Code (2026)

Every coding agent forgets everything when the session ends. You re-explain the architecture, re-state the conventions, re-paste the same three decisions you already made last week. Engram is one of the more serious attempts to fix that, and it picked up 84 GitHub stars in the past seven days, about 1.4% growth on a base of 6,021.

I've been through enough "AI memory" projects that die at the demo stage to be skeptical by default. This one is built differently, and the difference is boring in a good way.

What it is

Engram is a persistent memory system for coding agents, shipped as a single Go binary. Storage is SQLite with FTS5 full-text search. It exposes itself four ways: an MCP server, an HTTP API, a CLI, and a TUI.

Install:

claude mcp add engram -- npx -y Gentleman-Programming/engram

Source: github.com/Gentleman-Programming/engram.

The design decisions that matter

A Go binary, not a Python service. No virtualenv, no dependency resolution at install time, no version conflict with whatever else you have running. It starts, it runs. For a background process you want alive across every coding session, this is the correct call and a surprising number of competing projects get it wrong.

SQLite with FTS5, not a vector database. This is the choice people will argue about, so it's worth being clear about the tradeoff. FTS5 is full-text search. It matches on terms, not on semantic similarity. You will not get the "I asked about authentication and it surfaced a note about session handling" behavior that embeddings give you.

What you get instead: no embedding API calls, no cost per write, no model dependency, no re-indexing when you change embedding providers, and a database file you can open with any SQLite client and read yourself. Queries return in single-digit milliseconds on a local file.

For remembering project decisions and conventions, which is what people actually use agent memory for, term matching covers most of it. You remember roughly what you called something. My honest read is that vector search is the better technology for this problem and the worse engineering choice for a tool that has to run reliably on every developer's machine for months.

Agent-agnostic. It works with Claude Code, Cursor, and VS Code Copilot. Memory that only lives inside one vendor's tool is memory you lose when you switch, and people switch coding agents more often now than they did a year ago.

Four interfaces. The MCP server is what your agent talks to. The CLI is what you use to script things. The TUI is what you use when you want to see what the thing has actually stored, which is the feature most memory projects skip and the one that determines whether you trust it after month two.

Where it falls short

The absence of semantic search is a real limitation, not just a tradeoff you can hand-wave. If your memories are long prose notes rather than short factual entries, FTS5 will miss things a vector store would find. Write short and specific entries and this mostly goes away, but that puts discipline on you rather than the tool.

install_count reads zero in our database, which reflects a gap in our own telemetry rather than anything about the project. Star growth is the better adoption signal here, and it is healthy.

The features list on the project is thin in places, and I'd treat the four interfaces as the real feature set rather than any marketing enumeration.

There's also the general problem with agent memory that no tool has solved: deciding what deserves remembering. Engram gives you storage and retrieval. It does not decide that a given architectural decision matters and a given debugging detour doesn't. That judgment stays with you or with whatever prompting you set up around it, and if you're careless the store fills with noise that makes retrieval worse.

Is it worth installing?

Yes, with a condition.

Install it if you work on the same codebase across many sessions and you're tired of re-establishing context. That's the case it's built for and it handles it well. The Go binary means it won't rot in your environment, MIT means you're not exposed to a license change, and verified tier with a community-reviewed security status puts it in better standing than most of the memory projects competing with it.

Skip it if you mostly do short one-off tasks across unrelated repos. There's nothing for it to remember and you'll get a background process for no benefit.

The condition: set a convention for what goes in before you start using it. A memory store you never prune becomes a memory store you stop trusting, and at that point it's worse than no memory at all because you're paying context for retrievals you ignore.

Writing entries that FTS5 can find

Because retrieval is term-based, the way you phrase an entry decides whether it comes back. This is the one skill the tool asks you to develop, and it takes about a week.

Include the identifiers you'd search for later. A note that says "we decided against the queue approach" is nearly unfindable. The same note with the service name, the library considered, and the word "queue" in it will surface on any of those terms.

Keep entries short and single-topic. One decision per entry beats a long session summary, because a long entry matches many queries weakly and crowds out the precise entry you wanted.

Record the reasoning, not just the conclusion. Six weeks later, "we use Postgres advisory locks here" is less useful than the same line plus why the obvious alternative was rejected. The conclusion you can rediscover from the code; the rejected alternatives you cannot.

Prefer the vocabulary your codebase uses over the vocabulary you'd use to explain it to an outsider. You will search in the codebase's language.

Multiple machines and shared teams

The store is a local SQLite file, which is clean for a single developer and awkward the moment you want it in two places.

There's no built-in sync. Putting the file in a synced folder mostly works but invites the usual SQLite-over-network-filesystem problems if two machines write at once, so treat it as a single-writer arrangement rather than a shared database.

For teams, my read is that you don't want a shared store anyway. Most of what gets remembered is personal working context: what you were mid-way through, what you already ruled out. Team-level knowledge belongs in the repo where it gets reviewed, versioned, and read by people who never installed Engram. Use the agent memory for the things that would otherwise live in your head between sessions.

Security notes

Engram is community-reviewed with a note describing it as a popular community repository with significant adoption. That's a reasonable posture for a tool with 6,021 stars and 637 forks, and better than the unreviewed status most MCP servers carry.

Still worth doing before you install:

• Read what the MCP server exposes. It has an HTTP API — know what binds to what before you run it on a shared machine.
• The store is a plain SQLite file. That's a feature for auditability and a consideration if you put anything sensitive in it, because it isn't encrypted at rest by default.
• npx -y in the install command fetches and executes. Check the repo first.

Our longer writeups on this: how I vet every new skill before running it and what can go wrong with untrusted AI skills.

If you're building your own MCP tooling around it, the skills for building MCP servers covers the server side. Developers assembling a wider setup should see our full list for developers.

FAQ

Does Engram use embeddings or vector search? No. Storage is SQLite with FTS5 full-text search, so retrieval matches on terms rather than semantic similarity. That's a deliberate tradeoff: no embedding costs and no model dependency, at the price of missing conceptually related entries that don't share vocabulary.

Does it work with agents other than Claude Code? Yes. It lists Claude Code, Cursor, and VS Code Copilot as compatible, and the MCP server plus HTTP API means anything that speaks either protocol can use it.

Where does it store data? In a local SQLite database. You can open that file with any SQLite client and inspect or edit it, which is useful for auditing what your agent has been remembering.

Is it free? Yes, MIT licensed and free. There's no hosted tier and no account to create.

How is it different from putting notes in a project file? A markdown file works fine until it's long, at which point you're loading the whole thing into context every session. Engram retrieves only matching entries, so the cost scales with what's relevant rather than with everything you've ever written down.