AI Memory

One git-backed memory that every coding agent on your machine or team can read and write

Solution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors

Category
Developer tools
Audience
Developers
Language
Rust
Licence
MIT

Updated

AI Memory is a self-hosted long-term memory service for AI coding agents, storing what your sessions learn in a git-backed Markdown wiki that any agent can read. It is aimed at developers who switch between command-line coding agents — Claude Code, Codex, Cursor, Gemini CLI and others — in the middle of a single piece of work, and at small teams who want one person's hard-won context to be available to everyone else's agents instead of trapped on one laptop.

What it does

The problem it addresses is familiar to anyone who uses more than one agent. Your coding agent already keeps notes of its own: Claude Code takes them, Cursor remembers some things, and every platform is adding more. All of those notes share the same walls — they live on one machine, belong to one agent, and disappear the moment you switch tools or hand work to a teammate. Quit Claude Code mid-task, open Codex in the same directory, and the second agent knows nothing about the architecture you settled on, the approaches that already failed, or the questions still open.

AI Memory sits on the other side of those walls and gives all of them one shared memory:

  • Across agents. More than twenty harnesses feed the same store — Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok, Devin, Kimi, Kiro and more. The next agent to open the directory picks up a real handoff: where you left off, what failed, what is unresolved.
  • Across machines. Memory lives in a server you run yourself, on the same laptop, a homelab box, or wherever you like. The project you left on the desktop is the project you resume on the laptop, with the same knowledge and the same open questions.
  • Across people. Point a team at one server and what one person's sessions learn, everyone's agents can retrieve. Knowledge is shared per project while personal handoffs stay personal, and multi-user auth, per-person attribution and an audit log are built in.

Handoffs are treated as a protocol rather than a convention. Each one is typed, owned, and claimed exactly once, so a piece of work is not silently picked up twice or dropped between two agents.

How it works

Capture happens through hooks in the agents themselves. As you work, prompts and decisions are recorded quietly in the background, with no separate language model involved in writing the notes down — nothing extra to pay for and nothing extra to wait on.

What comes out the other end is deliberately boring: a Markdown wiki under git, not an opaque embedding blob. You can open the files, read them, diff them and version them like anything else in the repository, which also means you can correct the memory by hand when an agent writes down something wrong.

On retrieval, an agent starting fresh gets a bounded brief — a summary sized to fit rather than the whole history dumped into the context window — plus full search over the project's accumulated notes when it needs to dig further.

Getting started

The project is written in Rust, needs a reasonably recent toolchain, and publishes tagged releases on GitHub; the license is MIT. The shape of a setup is a server you host yourself, agents configured to point at it, and the hook integration for whichever harnesses you use. Because the README available here is truncated, check the repository for the exact install and configuration commands rather than guessing at them.

When to use it / when not

This is worth your time if you genuinely move between agents, machines or teammates on the same codebase, and you have felt the cost of re-explaining a project from scratch. It is also a good fit if you want your agents' memory to be auditable and under version control rather than hidden inside a vendor's product.

It is less compelling if you live inside one agent on one machine and work alone. The built-in memory of that agent already covers most of the ground, and AI Memory is a service you have to run, back up and keep running. Teams adopting it are taking on a small piece of shared infrastructure, with the operational follow-through that implies.

Alternatives

The realistic alternatives are the memory features that ship with the agents themselves, plus the hand-rolled convention of a checked-in notes file that everyone is asked to update. Both work until you cross a boundary — a different tool, a different machine, a different person — which is precisely the boundary this project is built around.

Take AI Memory seriously if you are a multi-agent developer or a small team that has already standardised on coding agents and keeps losing context at the seams between them. The design choices are conservative in a good way: plain Markdown, git underneath, hooks instead of an extra model, and handoffs with explicit ownership. Nearly 7,500 stars in a few months suggests the pain it names is widely shared. If you use exactly one agent and never leave your desk, you can safely skip it.

More in Developer tools

All of Developer tools →