Engrim offers a shared local SQLite memory store for AI coding agents

An open-source memory layer for AI coding agents

A project called Engrim, published on GitHub under the account timgordontg and currently on Hacker News's front page, pitches itself as a universal, local-first SQLite memory engine for AI coding CLIs. Its goal is narrow but practical: let developers move between Google Antigravity, Claude Code, Cursor and Windsurf on the same codebase without losing architectural decisions, user constraints or project state.

According to the project's README, the underlying problem is that agent context lives inside each vendor's environment. Clear a session or switch tools, and the accumulated project knowledge disappears, while ever-larger context windows dilute attention and multiply cost with every turn. Engrim's answer is to externalize that knowledge into a project-scoped SQLite database at ~/.engrim/memory.db that any supported agent can read and write.

How it works

Adapters connect the engine to each environment. Antigravity and Claude Code use lifecycle hooks such as SessionStart and Stop, while Cursor and Windsurf attach through Model Context Protocol servers over stdio. Running engrim setup with no arguments auto-detects installed environments and configures all of them at once, and a --dry-run flag previews the changes before anything is written to disk.

Retrieval is hybrid: SQLite's FTS5 extension provides BM25 keyword search, combined with static vector embeddings from model2vec in a reciprocal-rank fusion setup. At session start, agents receive a budget-capped memory pack — around 4,000 characters by default — of curated records rather than a full transcript.

Provenance is tracked on every entry. An origin_agent field records whether a memory was written by Antigravity, Claude Code, Cursor, the CLI or the user, so a team running several agents on one codebase can see which tool made which decision. The README says existing databases are migrated non-destructively when the column is introduced.

Tooling

Engrim ships a zero-dependency JSON-RPC 2.0 MCP server, started with engrim serve --mcp, that exposes four tools: recall for hybrid search, add for writing durable records, context for the boot-time memory pack, and review, which scans transcript logs for decisions that were never saved before a developer clears a session. A CLI mirrors these operations and adds commands to list recent memories, mark records as superseded without erasing history, and idempotently sync markdown notes into the store.

The recommended workflow is what the project calls continue-as-clear: capture decisions as they happen, and write a tagged resume-pointer before ending a session, so the next agent starts knowing the immediate next task.

Self-reported results

The headline numbers come from the project itself and have not been independently verified. Engrim claims it ran 105 continuous sessions on a 50,000-line algorithmic trading system, with zero regressions across 186 unit tests and no context amnesia when switching models between environments. It also says more than 153,000 tokens of accumulated work were consolidated into an active memory pack under 1,000 tokens — a reduction of over 99% in reloaded context on every session restart.

Why it matters

The friction Engrim targets is one most teams using AI agents already feel: knowledge about a codebase accumulates inside whichever assistant happened to be open, and moving to another tool means starting over. A local-first, plain-SQLite store keeps that knowledge portable, inspectable and vendor-neutral — the opposite of the cloud-locked memory systems each vendor would prefer developers adopt.

The small curated memory pack is also a bet that retrieval beats brute-force context as windows scale past a million tokens, both for reasoning quality and for cost per turn.

The caveats are just as clear. The evidence so far is a single self-reported case study on one codebase, and the project is young. But as an architectural argument — that project memory should belong to the developer rather than to any one agent — it points at where coding tooling is likely heading.