ai-memory: the agent handoff layer that treats context as a git repo

Fabio Akita’s ai-memory project on GitHub solves a problem every developer who has switched between coding agents has felt: Claude Code finishes a task, you open OpenAI Codex in the same directory the next morning, and it asks what the codebase does. Akita’s tool gives agents a shared, persistent wiki compiled from sanitized lifecycle observations, so the next agent receives a bounded handoff before its first prompt. Quit Claude Code mid-task, start Codex hours later, and the new agent sees a “where you left off” block. No re-explaining the architecture, the failed approaches, or the open questions.

The striking part is not that the tool exists. It is how it works. The wiki is plain markdown in a git repo, grep-able, openable in Obsidian, backed up with rsync. No vector database to babysit, no write_note ceremony, no manual context-loading. In an AI ecosystem that has spent two years chasing ever-larger context windows and ever-more-complex retrieval pipelines, Akita’s bet is that the humble git repo is the right substrate for agent memory. The design document lives in docs/ARCHITECTURE.md, and the influences and priors are listed at the bottom of the README.

The support matrix is the story

What makes ai-memory genuinely new is the breadth of its support matrix. This is not a Claude Code plugin with a Codex afterthought. The README lists first-class support for Claude Code, OpenAI Codex, Command Code, Devin CLI, OpenCode, Cursor, Gemini CLI, Oh My Pi, Pi, OpenClaw, Antigravity CLI, Grok Build CLI, Kimi Code, Kiro CLI, and Zero. MCP-only support covers Claude Desktop, Swival CLI, VS Code Copilot, and Zed. Hermes Agent gets a community-maintained plugin. That is roughly eighteen different agent harnesses, each with its own hook schema, config file location, and session-boundary semantics.

The per-harness notes read like a field guide to the fragmentation of the agent ecosystem. Grok Build CLI captures work but cannot inject handoffs because it ignores SessionStart stdout, so recovery happens via MCP memory_handoff_accept. Kimi Code discards SessionStart hook stdout too, so handoffs inject via UserPromptSubmit instead. Antigravity CLI only maps PreInvocation with invocationNum = 0 to SessionStart, and later model calls cannot consume a next-session handoff. Zero discards sessionStart stdout as well. Kiro has no true SessionEnd hook, so you run ai-memory finalize-session --agent kiro-cli manually, with --session-id <uuid> for concurrent sessions.

This is the real state of the AI coding agent market in August 2026: a dozen vendors, none of whom agree on what a session is, none of whom expose a stable session-end event, and most of whom cannot be bothered to read a handoff from standard output. Akita’s tool is effectively an adapter layer that normalizes all of these divergent contracts into one portable format. The fact that it needs to exist, and that it has to document eighteen different hook schemas, is the most honest picture of the agent ecosystem available anywhere.

What the tool actually does

The mechanics are straightforward. Lifecycle hooks fire-and-forget bounded, sanitized observations of prompts, tool lifecycles, and session boundaries. User prompts and post-compaction summaries retain up to 16 KiB; notifications and tool excerpts retain up to 2 KB, with a 16 KiB durable backstop for every observation body. When a session ends, relevant observations become a coherent summary, and consolidation stores up to 10 specific nouns per page in canonical entities.

The opt-in managed workstreams feature is where it gets interesting. ai-memory run claude, then ai-memory run codex --yolo, then ai-memory run command-code transparently resumes one logical workstream with native per-harness sessions and a portable visible-event ledger. Delivered packets are origin-marked, and Claude transcript import rejects a packet that Claude persisted and read back through a tool. That last detail matters: it prevents the agent from hallucinating that it wrote the memory itself, which would corrupt the provenance chain.

Per-repository capture exclusions let you drop sensitive file-tool events before they reach the local spool. A nearest-marker [capture] ignore_paths policy handles that. Optional per-operator memory slots on shared servers keep engine-written context in a bounded namespace derived from the authenticated operator, though the README is careful to call this context-injection isolation rather than RBAC. Exact wiki reads and searches remain project-wide.

The architectural bet

Akita’s design rejects several assumptions that have become orthodoxy in the AI industry. The first is that agent memory requires a vector database. The README is explicit: no vector database to babysit. Plain markdown in a git repo is searchable enough for the use case, which is bounded handoff, not semantic retrieval over a corpus of millions of documents. The second is that memory should be written by the agent as a deliberate act. ai-memory captures lifecycle observations automatically and consolidates them at session boundaries, so the agent never has to remember to write a note.

The third assumption is the most consequential: that agent memory should be vendor-neutral. The entire tool is built around the idea that your work-in-progress belongs to you, not to Anthropic or OpenAI or Google. When you switch from Claude Code to Codex, the memory of what you were doing should follow you. That is a direct challenge to the lock-in strategy that every major AI lab is quietly pursuing. Anthropic would prefer you stay in Claude Code forever; OpenAI would prefer you never leave Codex. Akita’s tool makes switching costless, and that is a genuinely subversive position in the current market.

There are real limits. The wiki is only as good as the observations captured, and the README is honest that direct launches keep a lightweight path that is not a complete native transcript. Managed workstreams are opt-in. Native Windows support is experimental. And the tool cannot fix the underlying problem that most of these agent vendors do not expose a true session-end event, which is why so many entries in the support matrix end with the instruction to run ai-memory finalize-session manually.

What this means for AI builders

The existence of ai-memory is a signal about where the agent market is heading. The vendors are consolidating around MCP as the configuration standard, and around lifecycle hooks as the capture mechanism, even as each implements them differently. The fragmentation is real, but it is surface-level: underneath, everyone is converging on the same shape. A tool like this is possible precisely because the ecosystem has standardized enough that one adapter layer can cover eighteen harnesses.

The deeper implication is about where the value in AI coding tools actually sits. The labs compete on model quality, but the switching costs are in the context. Your accumulated knowledge about a codebase, the failed approaches, the open questions, those are the real moat. ai-memory treats that context as a portable asset that belongs to the developer, not to any single vendor. That is a bet that the future of AI coding is multi-vendor, and that the developer, not the lab, owns the memory. The git repo, of all things, is the neutral ground everyone can agree on.

The tool’s own README says the wiki is backed up with rsync and openable in Obsidian. The most durable infrastructure in the AI stack, it turns out, is the one that has been there since 2005.