ai-memory: A Portable Memory Layer for AI Coding Agents, Written in Rust

You sigh, ready to explain your entire line of thinking all over again.

This is the "amnesia" of the Agent era — every AI coding CLI is an island, with no shared memory. Akita On Rails (a veteran of the Brazilian Ruby community) got tired of this fragmentation and wrote ai-memory in Rust: a local-first, long-term memory layer that lets Agents hand off work to each other.

What It Actually Does

In one sentence: it turns an Agent's working memory into portable files.

Specifically, ai-memory does three things:

1. Automatic capture: Through MCP configuration + lifecycle hooks, it automatically records key decisions, failed attempts, and open questions in every Agent session. No action needed from the Agent — hooks fire on SessionStart/Stop events. 2. Structured storage: Dual-writing to SQLite + FTS5 full-text index and Markdown. SQLite provides the query interface for Agents; Markdown is for humans to read. It's not a black box — you can open the files directly to see what your Agent remembered. 3. Cross-vendor handoff: Supports Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Devin CLI, Command Code, Antigravity CLI, Grok Build CLI, OpenClaw… twenty-plus Agent CLIs. When you switch Agents, the new Agent's SessionStart hook automatically injects the previous handoff notes.

The revolutionary part: Agent vendors can no longer lock you in. You're no longer tied to Anthropic just because "Claude Code remembers my project" — the memory is yours, stored locally, readable by anyone.

Why Rust + SQLite

Akita's choices are counter-trend: it's 2026 — why not a vector database? Why not LLM-as-memory?

The answer lies in the word "debuggability." Vector databases are black boxes — you don't know why an Agent recalled something. LLM-as-memory is Schrödinger's cat — every recollection may differ. SQLite + FTS5 is deterministic: the same query always returns the same result. Markdown is human-readable: when there's a bug, you can open the file directly to see what the Agent got wrong.

Rust isn't about speed either — an Agent memory layer doesn't need nanosecond latency. Rust's real value is type safety and thread safety. Agents may write memory concurrently (multiple subagents working simultaneously); Rust's ownership model eliminates data races at compile time. It's a classic engineering trade: compiler guarantees instead of runtime checks.

How It Differs From Other Memory Solutions

| Solution | Storage | Readability | Cross-Agent | Deterministic | |------|------|--------|----------|--------| | Vector DBs (Mem0, etc.) | Vectors | Black box | Needs adapters | Fuzzy | | LLM context compression | Inside model | Unreadable | Not supported | Uncertain | | MemTools (declarative contracts) | JSON | Semi-readable | Needs adapters | Deterministic | | ai-memory | SQLite+MD | Human-readable | Native support | Deterministic |

The key difference: ai-memory isn't "adding a memory system to an Agent" — it's "giving humans a window into the Agent's memory." The Markdown dual-write is the soul of this design — it turns the Agent's black-box thought process into auditable engineering documentation.

Conceptual Lineage: The "USB-C Port" for Memory

This points to a bigger pattern. In the lineage of "solving problems at a different layer," ai-memory is the eleventh member:

• Octopuses use RNA editing for "DNA pretraining + compute at inference time"
• Slime molds externalize memory via slime trails
• SOPHA routes different states to different exit directions
• Euclid-MCP outsources reasoning to Prolog
• ai-memory moves memory from inside the Agent to the filesystem

Common principle: don't strengthen the same component — solve the problem at a different layer. An Agent's context window is limited, volatile, and vendor-locked — so instead of fighting the context window, externalize memory to the filesystem where every Agent can read it.

This is isomorphic to MemTools' "USB-C port" idea: MemTools gives Agent memory systems a standard interface; ai-memory gives Agent working memory a standard format. The difference: MemTools solves "how memory systems interoperate," ai-memory solves "how Agents hand off to each other" — one is the data layer, the other the session layer.

An Overlooked Detail: Capture Exclusions

One design detail deserves special mention: native commands enforce capture exclusions. Certain sensitive operations (e.g., asking the Agent to handle files containing secrets) won't be recorded into memory.

This isn't a technical footnote — it's a security boundary. The biggest risk of Agent memory systems isn't "forgetting too much" but "remembering too much" — logging API keys, passwords, and customer data, then handing it all to the next Agent. ai-memory was designed with this in mind: capture is opt-in (--capture-assistant off by default), and exclusions are enforced.

This echoes output-layer intervention from alignment work: don't retrain the model, just add constraints at the output layer. ai-memory adds constraints at the capture layer — far more reliable than trusting the Agent to "judge for itself what to remember."

Limitations and an Honest Assessment

It's not without problems:

• Hook dependency: Every Agent CLI has different lifecycle hooks. Devin CLI has no SessionEnd hook, so you must manually run ai-memory finalize-session. This fragmentation mirrors the current state of the Agent ecosystem.
• Memory quality: Automatic capture records "what happened," not "why." The Agent's reasoning process remains a black box — hooks only see inputs and outputs, not the thinking in between.
• Single-machine assumption: Local SQLite doesn't support team collaboration. If two people use different Agents on the same project, memories will fork. This is the next problem to solve.

But as "the first memory standard of the Agent era," it gets the most important thing right: memory belongs to the user, not the Agent vendor.

Closing Thought

ai-memory reminds me of the birth of Git — what Linus solved wasn't "how to store code" but "how code flows between people." What Akita solves isn't "how Agents remember" but "how Agent memory flows between vendors."

From an Agent engineering perspective, this validates the "granularity isomorphism" principle again: the medium of memory should align in granularity with how memory is used. Agents work at the session level, so memory is captured at the session level; Agents need cross-vendor handoff, so memory is stored at the filesystem level. Not a stronger model — a more appropriate granularity.

---

Project: https://github.com/akitaonrails/ai-memory Language: Rust Stars today: 207 Who it's for: Developers switching between multiple Agent CLIs, especially Claude Code + Codex mixed workflows