Gentleman-Programming/engram

The problem

Every new agent session starts cold. You re-explain the architecture, the conventions, the decision you already made last Tuesday, and the agent still has no idea what it broke yesterday. Context windows are large now, but they are per-session, not per-project. Engram addresses this by storing observations in a local SQLite database with full-text search and exposing it to the agent over MCP, so what was learned in one session can be recalled in the next.

What's different

The usual approaches are memory inside one vendor's product (Claude Code's own project files, Cursor rules) or a general RAG stack you have to assemble yourself. Engram takes a third route: a single Go binary, no Node or Python or Docker, backed by SQLite + FTS5, and agent-agnostic through MCP, the CLI, an HTTP API and a TUI. Two things actually set it apart: the storage is one plain file you can inspect and back up yourself, which matters for anyone who does not want their project memory living in someone else's cloud; and scoping is project-aware by default, with an explicit opt-in for cross-project reads. Git Sync and an optional Cloud tier handle sharing across machines. Notably, the README spends more words on edge-case semantics (which Windows commands prepare which directory, which health capability gates Codex writes) than on how memory is written and recalled, so our picture of the core behaviour is thinner than the feature claims suggest.

Who it's for

Developers who run one or more MCP-capable coding agents on real, long-lived repositories and are tired of re-onboarding them. It fits people who want their memory local and file-based, and teams willing to sync that file through Git or a hosted tier. Look elsewhere if you work mostly in one short-lived scratch repo, if your agent has no MCP support, or if you need a memory layer shared by non-coding workloads — this is explicitly a coding-agent tool.

Cost of adoption

You need to run a binary and register it with each agent you use; the README has per-agent setup pages for 14 targets, and that is 14 places where configuration can drift. MIT license, negligible runtime footprint. The real costs are organisational: a growing SQLite memory file you should back up and occasionally prune, an optional Cloud tier with its own upgrade/repair/bootstrap sequence and troubleshooting docs, and a surface area large enough that release-to-release compatibility gates already exist (the Codex health-capability check is one). There are no benchmarks in the README, so nothing here tells you how recall quality compares to simpler alternatives.

Verdict

Engram is a young project — 250 days old under this identity — that is nonetheless moving: +833 Go stars in the tracked month and #10 on the monthly board, with 7.6k total stars. That is a real spike for a tool whose HN footprint is a single one-point thread, so interest is coming from somewhere other than technical discussion, and the docs' density of compatibility caveats suggests a fast-moving codebase. If you already run several MCP agents on a large codebase, it is worth a trial in one repo; if you want a stable, boring memory layer, wait for the churn to settle and confirm the recall behaviour yourself rather than trusting the badges.