Engram: Persistent Memory for AI Coding Agents

What Engram is

Engram is a persistent memory layer for AI coding agents. The README states the problem in one line: your AI coding agent forgets everything when the session ends. Engram gives it somewhere to write down what it learned (bug fixes, architecture decisions, conventions, user constraints) and a way to search that history in the next session.

It ships as a single Go binary backed by SQLite with FTS5 full-text search, and it is exposed through a CLI, an HTTP API, an MCP server and an interactive terminal UI. No Node.js, Python or Docker is required; the README's summary is "one binary, one SQLite file". It works with any MCP-compatible agent, and the README names Claude Code, OpenCode, Gemini CLI, Codex, VS Code (Copilot), Antigravity, Cursor and Windsurf among them. The project lives under the Gentleman Programming GitHub organization and is MIT-licensed; the Engram name and logos are trademarks of Alan Buscaglia.

How it works

The data path is short: the agent talks to Engram over MCP stdio, and Engram writes to a SQLite database at ~/.engram/engram.db with FTS5 indexing.

Agent (Claude Code / OpenCode / Gemini CLI / Codex / VS Code / Antigravity / ...)
    ↓ MCP stdio
Engram (single Go binary)
    ↓
SQLite + FTS5 (~/.engram/engram.db)

The key design choice, spelled out in the architecture docs, is that Engram trusts the agent to decide what is worth remembering rather than capturing every tool call. After significant work, the agent calls mem_save with a structured summary (title, type, and What/Why/Where/Learned content). At the end of a session it writes a mem_session_summary covering goal, discoveries, accomplished work, next steps and relevant files. Next session, it searches memory to recover context, or a host plugin can inject it.

Retrieval is progressive: mem_search returns previews, mem_timeline adds surrounding session context, and mem_get_observation fetches the full record. Evolving topics get a stable topic_key (for example architecture/auth-model) so updates refine one memory instead of creating competing ones. Memory is scoped per project, resolved from an explicit project, the ENGRAM_PROJECT variable, or the working directory; Engram even stops with a project_transition_conflict rather than silently switching scope when initializing Git changes which project a directory maps to.

The README is explicit that Engram should be treated as curated project memory, not a transcript sink. Its example of a useful memory is four short fields: What changed, Why it mattered, Where in the code it lives, and what was Learned, paired with a short, searchable title and a fitting type. Raw tool output and every conversational turn are deliberately left out.

Key features

• Single static binary: no runtime dependencies or background services for the usual stdio setup.
• SQLite + FTS5 search: full-text search over memories with no separate vector database.
• Agent-agnostic MCP tools: mem_current_project, mem_context, mem_search, mem_save, mem_update, mem_session_summary, plus review tools such as mem_review, mem_judge and mem_compare, and mem_doctor for diagnostics.
• One-command agent setup: engram setup <agent> writes MCP and integration config for OpenCode, Gemini CLI, Codex, Cursor, Windsurf, VS Code Copilot, Kiro, Qwen Code and others; Claude Code installs it as a plugin.
• Compaction resilience: the documented protocol saves a handoff before context compaction and recovers it afterward.
• Privacy tags: per the comparison doc, content in <private> tags is stripped at two layers.
• Terminal UI: engram tui browses memories with vim-style navigation and search.
• Git Sync: exports portable compressed chunks so memory can be shared across machines through a repository.
• Optional Engram Cloud: project-scoped replication and shared access with browser visibility, layered on top of the authoritative local database.
• Obsidian export (beta): export memories as an Obsidian knowledge graph.

Getting started

The README points to GitHub Releases for the latest stable build and notes that Homebrew remains on the stable v1.20.0 line:

brew install gentleman-programming/tap/engram

The installation guide also documents go install for the current v3 line:

go install github.com/Gentleman-Programming/engram/v3/cmd/engram@latest

Then wire up your agent and restart it. For example:

engram setup codex
engram setup cursor
engram setup gemini-cli

For Claude Code the README uses the plugin marketplace instead:

claude plugin marketplace add Gentleman-Programming/engram && claude plugin install engram

To browse what has been stored:

engram tui

Use cases

• Cross-session continuity: an agent picks up yesterday's half-finished refactor from a session summary instead of re-reading the codebase.
• Not re-solving solved bugs: search before revisiting a bug or decision that is already recorded with its cause and fix.
• Switching agents: because memory sits behind MCP, the same project memory is available whether you are in Claude Code, Codex or Cursor that day.
• Team conventions: share memory through Git Sync or Engram Cloud so several developers' agents learn the same project rules; the docs include a team-usage guide.
• Long sessions with compaction: persist a handoff before the context window is compacted and recover it afterward.

How it compares

The README says Engram was inspired by claude-mem, and the project's comparison doc lays out the differences from the maintainers' perspective. claude-mem is described as TypeScript plus Python with a ChromaDB vector store and a worker process, tied to Claude Code's plugin hooks, capturing raw tool calls and compressing them with separate Claude API calls, and licensed AGPL-3.0. Engram instead is a single Go binary, uses SQLite FTS5 rather than vectors, stores only agent-curated summaries with no extra API calls, works with any MCP agent, and is MIT-licensed. The trade-off is that Engram has no automatic capture: memory quality depends on the agent following the save protocol, and keyword search will not match paraphrases the way semantic search can.

Things to know before adopting

• Release channels: stable releases are the production and security-supported line; release candidates are prerelease builds. Read the release policy before upgrading, especially across major versions.
• Windows antivirus: the install guide notes some unsigned prebuilt Windows binaries have been flagged as false positives, and recommends go install or building from source as an alternative.
• Agent discipline matters: the README includes an explicit operating contract for agents (orient, search before repeating, save deliberately, leave a handoff). Expect to reinforce it in your agent instructions.
• Local-first: the local SQLite file is authoritative; Cloud is optional replication, not a requirement.
• Trademark: the MIT license covers the code, but the Engram name and logos are trademarks and the license does not permit implying endorsement.
• Contribution model: every change starts with an approved issue under an issue-first workflow.
• Age: the repository was created in February 2026, so it is young, though already on its third major version line.

Project activity

As of October 2026 the repository has about 7,000 stars on GitHub. It was created on 2026-02-16, is written in Go, and is released under the MIT license. Source code is at github.com/Gentleman-Programming/engram and the project site is engram.gentlemanprogramming.com.