Engram: persistent memory for coding agents

Your coding agent starts every session knowing nothing. The bug you fixed yesterday, last week’s architecture decision, the convention the team agreed a month ago: none of it survives the end of the session. Engram^[1] offers a deliberately simple answer to that problem, and this article covers what it does, what it does not, and when the right answer is not to install it.

Key takeaways

• Engram is a Go binary under the MIT licence that stores agent memory in SQLite with FTS5 and connects over MCP.
• Its pitch is the absence of dependencies: no Node, no Python, no Docker. One binary and one file.
• Search is lexical, not semantic. It retrieves what you wrote using the words you wrote. That changes what is worth saving.
• Machine-to-machine sync runs through git, so memory ends up as a versioned artefact of the repository.
• The project is seven months old and its version 2 is still a release candidate. Adopting it today means adopting something in motion.

The problem it actually solves

Two things get conflated here. One is where the code is: which file defines this function, where that constant is used. Current agents handle that on their own by reading the repository, and they need no persistent memory for it.

The other is why we decided this. Why the obvious library was rejected, what was tried before and failed, which naming convention was agreed and on what grounds. That is not in the code, or it is scattered across commit messages and conversations nobody rereads. It is information that gets lost and costs money to regenerate, because the agent proposes again what you already turned down.

Engram targets the second kind. The project frames it as a three-step protocol it imposes on the model: save important knowledge, search before repeating work, and fetch full detail only when needed.

How it works underneath

The agent talks to Engram over MCP^[2], the protocol that standardises how a model uses external tools. Engram exposes four: mem_save to store an observation, mem_search to search, mem_context to pull project context at the start, and mem_current_project to know which one it is in.

Underneath sits SQLite with the FTS5 extension. Here is the technical detail almost no review mentions, and it determines how you should use the thing. SQLite’s own documentation defines it without ambiguity:

FTS5 is an SQLite virtual table module that provides full-text search functionality to database applications.

Full-text search, lexical, with BM25 ranking, phrase queries, prefix queries and proximity queries. There are no embeddings and no vector similarity. If you saved a note reading "the connection pool saturates past 40 workers" and later ask about "concurrency limit", FTS5 will not make that connection for you.

That is not a flaw, it is a design choice with a practical consequence: write notes using the terms you will type again. Function names, literal error strings, service names. No elegant prose. Lexical memory rewards consistent vocabulary, exactly as grep does.

Installing and trying it

On macOS the recommended route is Homebrew:

brew install gentleman-programming/tap/engram
engram setup claude-code

The setup subcommand writes the configuration for whichever agent you name. The supported list is long: Claude Code, OpenCode, Gemini CLI, Codex, VS Code with Copilot, Cursor, Windsurf, Antigravity and anything else that speaks MCP.

To see what it is storing there is a terminal interface:

engram tui

It navigates with vim keys: j and k to move, Enter to open an observation, / to search and Esc to go back. It is the quick way to audit what the agent decided to remember, which in practice is the part most worth watching.

The awkward question: do you need it?

If you follow the argument that coding agents work well searching the repository directly, the doubt is fair: if the agent already finds what it needs, why add another layer?

The honest answer depends on team size and on how much undocumented decision-making you carry. On a personal project with a well-kept CLAUDE.md, Engram adds a moving part in exchange for little. On a repository with more than one person, months of history and decisions taken in meetings, the difference shows.

And there is an alternative almost no comparison includes: installing nothing. A CLAUDE.md or AGENTS.md file versioned in the repository is persistent memory, it gets reviewed by pull request, and it needs no extra process. It is less automatic and it does not scale the same way, but it has a property no local database offers: somebody reads it before it goes in.

Alternatives and when to pick each

Zep deserves one note of honesty. Its paper reports accuracy improvements of up to 18.5% and a 90% latency reduction against baseline implementations on LongMemEval. Those are figures published by the authors of the system under evaluation, not an independent arbitration, and they should be read that way.

Git sync, and what it implies

Engram exports the database to git in compressed chunks. The project claims this avoids merge conflicts and huge files; we have not measured that ourselves.

The important nuance is editorial rather than technical. If memory syncs through git, memory is part of the repository. Everything the agent decides to save ends up in the history, with the persistence and visibility that implies. Decide what goes in before it goes in, and audit the database with engram tui occasionally instead of trusting that the model’s judgement matches yours.

There is also Engram Cloud, presented as an optional self-hosted replication layer for deployment on Dokploy, Coolify, Portainer or a bare VPS. The project’s site publishes no price.

The project’s real state

Here are the numbers, read from the GitHub API on 3 September 2026 rather than from the rendered page:

• 6,286 stars and 670 forks.
• Repository created on 16 February 2026: about seven months old.
• 60 published releases, of which 55 are stable.
• The latest stable is v1.20.0, from 20 July 2026.
• The most recent, v2.0.0-rc.4, was published on 2 September 2026 and is a release candidate.

In other words: the major version in progress has not left candidate status, and the repository takes changes daily. That is not a reason to dismiss it, but it is a reason to pin the version you install and not assume today’s interface will be the one you get in three months.

Frequently asked questions

Does it work with agents other than Claude Code?

Yes. Engram communicates over MCP, so it serves any agent supporting the protocol. The project lists explicit support for OpenCode, Gemini CLI, Codex, Cursor, Windsurf and VS Code with Copilot, among others.

Do I need a vector database?

No, and that is exactly the point. Engram uses FTS5, which is lexical search over SQLite. You gain deployment simplicity and lose retrieval by meaning: two notes saying the same thing in different words will not find each other.

Can I share memory with my team?

Yes, through git or with the self-hosted Cloud layer. Before doing so, bear in mind you will be publishing into the repository everything the agent considered worth keeping.

Conclusion

Engram gets both the diagnosis and the shape right. The problem is real (agents forget decisions, not code) and the chosen solution is a dependency-free binary rather than a platform. For anyone already self-hosting, that ratio between what it gives and what it costs to maintain is comfortable.

The two things worth being clear on before installing are that search is lexical, which forces consistent vocabulary in your notes, and that version 2 is still a candidate. If your project is small, try a well-kept conventions file first: it may already be enough.

This article is also available in Spanish.

Sources

1. Engram
2. MCP
3. Zep / Graphiti
4. Engram, project site
5. SQLite: FTS5 Extension

Route: AI Coding Agents