Engram: persistent memory for AI coding agents, as one Go binary

The gap Engram fills between agent sessions

An AI coding agent starts each session with nothing. The decisions you argued through yesterday, the bug you already diagnosed, the convention your team settled on: gone unless you paste it back in. Engram exists to hold that material outside the session and hand it back on demand. It is aimed at people who run an MCP-compatible agent all day on the same codebase, and who are tired of re-explaining context that was already established. The README frames the target plainly: it works with Claude Code, OpenCode, Gemini CLI, Codex, VS Code (Copilot), Antigravity, Cursor and Windsurf. The unit of value is not the conversation. It is the decision, the fix, the constraint and the discovery, saved deliberately and retrieved by search.

One binary, one SQLite file, four front doors

The architecture is flat, and that is the point. The README shows the data flow as an agent talking to Engram over MCP stdio, with Engram writing to SQLite plus FTS5 at ~/.engram/engram.db. The same store is reachable through a CLI, an HTTP API and an interactive TUI, so the memory is not trapped inside one client. Full-text search is handled by FTS5 inside SQLite rather than a separate index process, which is why the project can claim no Node.js, Python or Docker requirement. The module path in go.mod is github.com/Gentleman-Programming/engram/v2 and the dependencies listed there are ordinary Go libraries: modernc.org/sqlite for the database driver, mark3labs/mcp-go for the protocol layer, Bubble Tea and Lip Gloss for the TUI. There is also a pgx dependency and docker-compose.cloud.yml plus docker-compose.beta.yml at the repository root, so a cloud variant exists alongside the local one; the README links to docs/engram-cloud/README.md for that. The local path is the one the README leads with.

Installing Engram and saving a first memory

The README directs production users to the latest stable release from GitHub Releases and points at docs/INSTALLATION.md for Windows, Linux, source builds and the remaining installation methods. Homebrew is documented as a tap, with a caveat worth reading twice: Homebrew remains on the stable v1.20.0 line, while the most recent GitHub release is v2.0.0. If you install through the tap you are not getting the v2 line.

brew install gentleman-programming/tap/engram

After installation, the agent-side contract is what matters. The README tells agents to orient first with mem_current_project, which confirms the resolved project and where that resolution came from. Then mem_context and mem_search recover relevant history before new work starts. The README is explicit that search results are previews rather than the complete record, so mem_get_observation is the tool to call before relying on a full observation, with mem_timeline available when the surrounding session context matters.

Saving is deliberately manual. The README instructs agents to save completed bug fixes, decisions, discoveries, configuration changes, patterns and durable user constraints with mem_save, and to avoid capturing raw tool output or every conversational turn. The memory format it recommends is short and structured:

**What**: Added retry-safe upload handling.
**Why**: Retries could create duplicate records.
**Where**: internal/upload/handler.go
**Learned**: Reuse the request id as the idempotency key.

For topics that keep evolving, the README recommends a stable topic_key such as architecture/auth-model, reused to update that topic rather than creating competing memories, with mem_suggest_topic_key when the key is unclear. Before a session ends, the agent is told to leave a handoff via mem_session_summary covering the goal, instructions, discoveries, accomplished work, next steps and relevant files. After a context compaction, the order given is to persist the compacted handoff with mem_session_summary first, then call mem_context to recover recent session history.

The tool surface is wider than the quick start suggests

The README's intent table lists more than the save-and-search pair. mem_save_prompt preserves the user's request. mem_session_start and mem_session_end bracket a session alongside the summary tool. mem_review, mem_judge and mem_compare are grouped under reviewing stale knowledge or memory relationships, which implies the store is expected to age and to contain claims that need adjudicating. mem_doctor diagnoses project or store state. The README warns that tool availability can vary by MCP profile and suggests using the client's tool discovery mechanism, such as ToolSearch, when a deferred tool is needed. That warning is the honest part of the design: the documented contract is broader than what any given client session may expose, so an agent following the README literally can find a named tool missing. The README does not document which profiles expose which subset.

Where Engram is the wrong tool

Engram is not a transcript sink, and the README says so directly: treat it as curated project memory, not a transcript sink. If you want a searchable log of everything an agent did, this is the wrong shape, because the save rules exclude raw tool output and every conversational turn. It is also not a knowledge base you can hand to a human reader without curation. The heavier constraint is that quality depends on the agent's judgement. Nothing in the documented flow forces a save at the right moment or rejects a badly written one; the operating contract is instructions to the agent, and an agent that ignores step four leaves you with an empty or noisy store. The README does not document rollback, so there is no described way to undo a bad memory beyond the update and review tools. And because the default store is a single SQLite file, anyone who needs concurrent multi-writer access across machines should look at the cloud path in docs/engram-cloud/README.md rather than assume the local file scales sideways.

How this differs from memory built into a single agent

Several agent clients ship their own memory feature, and the practical difference is scope. A client-native memory belongs to that client: switch from Claude Code to Gemini CLI and the accumulated context does not follow. Engram's README positions itself as agent-agnostic for exactly this reason, with the same store reachable over MCP, an HTTP API, a CLI and a TUI. The second difference is where the data lives. A local Engram install keeps it in ~/.engram/engram.db, a file you can inspect, copy or delete without asking a vendor. The trade-off is that you now operate a second process and a second schema. A client-native feature costs nothing to run and knows nothing about your other tools; Engram costs a binary and a memory protocol, and in exchange the knowledge survives a change of editor.

Maintenance, releases and the MIT licence

The last push to the repository was on 2026-09-20, two days before this writing, and the repository is not archived. The release history is recent and dense: v2.0.0 on 2026-09-18, preceded by v2.0.0-rc.12 on 2026-09-16 and v2.0.0-rc.11 on 2026-09-12. That cadence has a cost. The README tells readers to check docs/RELEASE-POLICY.md before upgrading, and it distinguishes release candidates as prerelease validation and feedback builds to be chosen only when you accept prerelease risk. The Homebrew tap lagging on v1.20.0 is the concrete consequence: your upgrade path depends on which channel you installed from. The Makefile shows what contributors are held to, including a pinned golangci-lint version of 2.13.2, a templ generation step, and perf and deadcode ratchet scripts that compare against a baseline. Those gates are a maintenance signal, not a guarantee. The licence is MIT, which permits commercial and closed-source use; the repository also carries a TRADEMARKS.md file, so the name and branding are governed separately from the code. This is a description of the terms, not legal advice.

Editorial conclusion

Adopt Engram if you already run an MCP-compatible agent and want memory that lives in one SQLite file under ~/.engram/engram.db with no Node.js, Python or Docker in the loop. Skip it if you need a transcript archive, or if you expect the tool to decide what is worth remembering: the README puts that judgement on the agent. Before trusting it with a long-running project, verify two things yourself: which release line you are on, because Homebrew remains on the stable v1.20.0 line while the newest GitHub release is v2.0.0, and whether your client exposes the tools the operating contract names, since the README states tool availability can vary by MCP profile.

Frequently asked questions

Official sources

1. Gentleman-Programming/engram on GitHub
2. License: MIT
3. Project website
4. README
5. Releases