AI Coding Agent Memory That Survives Switching Tools

The real competition for engrim isn't other memory tools - it's the habit of pasting a summary of your project into every new AI coding agent session and hoping nothing important got lost. engrim, a local-first SQLite memory engine, replaces that ritual with a shared episodic memory store that survives switches between Google Antigravity, Claude Code, Cursor, Codex CLI, and Windsurf on the same project.

What the 105-Session Test Actually Shows

The evidence comes from a single case study: 105 continuous sessions on a 50,000-line algorithmic trading system. The reported results are specific - zero regressions across 186 unit tests and zero context amnesia across model switches. The mechanism is a hybrid search engine combining SQLite FTS5 (bm25 keyword matching) with static model2vec vector embeddings, fused via reciprocal-rank fusion. Long work histories get consolidated into a compact memory pack: 153,000+ tokens compressed to under 1,000 tokens, a 99%+ cut in reloaded context cost on session restart. The working memory sits around 4,000 characters, and model2vec loads in roughly 30ms with no GPU required.

That's one project, one developer's workflow. The numbers are internally consistent and the architecture is plausible, but treat the case study as a demonstration of mechanism, not a benchmark across codebases. What it does prove is that the consolidation approach doesn't degrade a real, large codebase over a long session history - which is the failure mode you'd actually worry about.

How It Compares to Just Picking One Agent

The obvious alternative is to stop switching agents. If you're committed to Claude Code or Cursor alone, engrim solves a problem you don't have, and its value drops to near zero. Its own framing - "the Switzerland of AI Memory" - is honest about this: the point is decoupling project intelligence from any single AI vendor or proprietary cloud silo. Agent provenance tracking records the origin of every memory entry (antigravity, claude-code, cursor, cli, or user), and auto-detection setup wires hooks and MCP servers for all five supported agents.

On the privacy axis it's deliberately strict: 100% local and offline, no telemetry, no cloud sync, databases with 0600 permissions and gitignored by default. The MCP server is a zero-dependency JSON-RPC 2.0 stdio server with stdout reserved for protocol messages. It's MIT licensed. For teams with code that can't touch a cloud memory service, this is the differentiator - most hosted alternatives fail that constraint outright.

Who Should Actually Adopt It

Worth adopting if you genuinely rotate between multiple AI coding agents on the same codebase and you've felt the cost of re-establishing context - architectural decisions, in-flight state - with each switch. The "continue-as-clear" workflow (capture decisions, pin resume-pointers, clear sessions freely with automatic memory re-injection) targets exactly that pain. Skip it if you work in one agent consistently; the vendor lock-in problem it exists to solve isn't yours yet.

What this actually points to is a shift in where the durable value of AI-assisted development lives. As the source puts it: "The models are disposable utilities; your project's decisions are not." Whether engrim specifically wins that layer matters less than the fact that the layer exists and is now claimable by a local SQLite file instead of a vendor's cloud. My read: expect memory portability to become table stakes, and tools like this are the opening bid rather than the end state.