Engram: A Single Go Binary That Gives Any AI Coding Agent Persistent Memory

By Prahlad Menon 6 min read

AI coding agents have a goldfish problem. Every new session starts from zero. The architectural decision you made last Tuesday, the subtle bug you already fixed, the naming convention the team agreed on — all gone the moment the context window resets or compaction kicks in. You end up re-explaining the same things, or worse, the agent re-introduces a bug you already killed.

Engram, from Alan Buscaglia (Gentleman Programming), is a clean answer to that problem — and it does it without the usual infrastructure tax.

One Binary, No Runtime Baggage

Most memory layers come wrapped in a stack: a Node service here, a Python embedding server there, maybe a Docker container to tie it together. Engram throws all of that out.

It’s a single Go binary backed by SQLite with FTS5 full-text search. One file, one database at ~/.engram/engram.db. No Node.js, no Python, no Docker.

brew install gentleman-programming/tap/engram

That self-contained design is the whole point. Memory you have to babysit is memory you stop using.

Agent-Agnostic by Design

The other smart bet Engram makes: it doesn’t pick sides in the agent wars. It speaks MCP (Model Context Protocol), so it plugs into essentially any MCP-compatible client. Setup is one command per agent:

engram setup claude-code
engram setup codex
engram setup gemini-cli
engram setup cursor
engram setup vscode-copilot

The supported list also includes OpenCode, Antigravity, Windsurf, Qwen Code, Kiro, Kilo Code, and more. Switch tools, keep your memory. That portability is rare — most memory solutions are welded to a single client.

Four Ways In

The same memory store is reachable through four interfaces:

  • MCP tools — 26 tools for saving, searching, timelines, sessions, review, and diagnosis, called directly by your agent.
  • HTTP API — the same memory over local endpoints, for compound/multi-agent workflows.
  • CLI — scriptable access from the shell.
  • TUI — an interactive terminal dashboard (Catppuccin Mocha theme) to browse, search, and copy memories by hand.

Curated Memory, Not a Transcript Dump

The part I appreciate most is the philosophy. Engram’s operating contract is explicit: treat memory as curated project knowledge, not a transcript sink. Don’t save every conversational turn or raw tool output. Save the things that stay true — completed bug fixes, decisions, discoveries, config changes, patterns, and durable user constraints.

The recommended loop looks like:

  1. Orient before writing — confirm the current project, recover recent history.
  2. Search before repeating — check whether a decision or bug is already known.
  3. Retrieve progressively — previews first, full observations only when you lean on them.
  4. Save deliberately — with stable topic keys like architecture/auth-model so a topic evolves instead of spawning competing duplicates.
  5. Leave a handoff — a session summary with goal, discoveries, next steps, and relevant files, so the next session (or the next agent) picks up cleanly.

It even handles the ugly edge cases: a conflict-surfacing mechanism flags related or contradicting memories so the agent can judge them, and there’s a compaction-recovery path for persisting a handoff before context is lost and reloading it afterward.

A saved memory is meant to be small and searchable:

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.

Local First, Shareable When You Want

Engram keeps memory local by default — the SQLite database is the source of truth. When you need to share across machines, Git Sync exports portable, compressed chunks you can commit. And Engram Cloud is an optional, project-scoped replication layer with browser visibility and shared access for teams. Nothing leaves your machine unless you decide it should.

How Engram Compares to the Rest of the Memory Field

We’ve covered a lot of agent-memory systems on this blog, and Engram lands in a crowded but well-mapped space. Here’s where it sits:

vs. soul.py (file-based memory). soul.py is the opposite design philosophy: memory lives in plain Markdown files you can read, diff, and commit — no database at all, zero dependencies, and a LoCoMo score of ~70% to back it. Engram instead keeps a single SQLite+FTS5 store and leans on structured tools (26 MCP calls, topic keys, session summaries). soul.py wins on radical transparency and “just files” portability; Engram wins on structured full-text retrieval and a richer tool surface. If you believe memory should be files, not a system, soul.py is your pick — Engram is the “disciplined local database” counterpoint.

vs. Stash. Both target coding agents, but Stash is built around a shared hub so multiple agents converge on one brain. Engram is local-first-per-developer with optional Git Sync and Cloud replication bolted on top. Engram’s edge is the single-binary, no-runtime install.

vs. codebase-memory and Obsidian Mind. codebase-memory is graph-first (stop grepping, start traversing); Obsidian Mind rides on your Obsidian vault. Engram is deliberately simpler — flat, searchable observations with conflict surfacing, not a knowledge graph. Notably, Engram does offer an Obsidian export in beta, so it can feed that graph workflow rather than compete with it head-on.

vs. Beacon. Beacon’s whole thesis is cross-harness lessons that survive the session. Engram shares the “don’t let the lesson die” goal but solves it with explicit session summaries and compaction-recovery steps rather than a native-skills approach.

vs. TencentDB Agent Memory and memory-lancedb-pro. These are the other “local long-term memory without a heavyweight vector DB” entrants. Engram’s differentiator remains portability — one Go binary, FTS5 instead of embeddings, agent-agnostic via MCP.

vs. the cloud/framework crowd (mem0, Zep, Letta). Those are services or Python frameworks with hosted components and embedding pipelines. Engram is the anti-service: no Python, no embeddings, no account required to start. It only reaches for the network if you opt into Engram Cloud.

The short version: soul.py and Engram are the two “keep it local, keep it simple” poles — soul.py via files, Engram via one SQLite binary. Almost everything else either adds a graph, a hosted service, or an embedding stack. Which you want comes down to whether you’d rather cat your memory or query it.

Why This One’s Worth Watching

The agent-memory space is getting crowded, but most entrants either lock you into one client or drag along a heavy runtime. Engram’s combination — single Go binary, SQLite+FTS5, MCP-native, agent-agnostic, local-first, with a disciplined “curate, don’t hoard” protocol — is a genuinely practical take on a problem every heavy agent user feels daily.

It’s MIT-licensed (with a trademark notice on the Engram name and logos), inspired by claude-mem but deliberately simpler and tool-independent, and it doubles as the memory layer for Buscaglia’s Gentle-AI while staying usable standalone.

If your agents keep forgetting what they learned yesterday, Engram is worth an afternoon.

Repo: github.com/Gentleman-Programming/engram