The thing that makes coding agents feel disposable is that they forget everything. Every session starts from nothing. Claude Code works out some detail about my setup, a port already taken by another container, a quirk in how a service boots, and then the session ends and that knowledge is gone. Next time it rediscovers the same thing from scratch, burning tokens and my patience. If I switch to Codex, it never knew in the first place. Three agents, three separate cases of amnesia.

I wanted one memory they all share. Local, so it stays private and free. Persistent, so what one agent learns sticks around. Shared, so a fact Claude figures out is there for Codex and Hermes too. This was the bigger sibling to the scheduler bridge I wrote about separately, and the part I learned the most from.

The store

The memory itself is unglamorous, which is the point. It’s a vector database (Qdrant) running on a box I already keep on, with a small server in front of it that speaks MCP, the protocol these CLIs use to reach external tools. It exposes two operations: store a piece of text, and search for the text most relevant to a query. Each of my agents points at the same endpoint. One writes, the others read.

The question I expected to wrestle with was how to decide what’s worth storing. The common answer is to run a language model over each session and have it pull out the important facts. I didn’t want a paid API in the loop, and then I realized I didn’t need one. The agent doing the writing is already a language model. Whatever it chooses to save is already distilled. The memory layer doesn’t have to be smart, it has to store text and find it again by meaning. The intelligence is the agent I’m already paying for, so the memory itself costs nothing to run.

What a hook is, and why the memory needs them

A memory the agents can reach is not automatically a memory they use. Agents are focused on the task; they don’t stop to take notes. To make the memory part of the loop, I leaned on hooks.

A hook is a script your CLI runs on its own at a specific moment: when a session starts, when the agent finishes a turn, before it runs a tool, and so on. The CLI passes the script some JSON about what’s going on, and the script can pass text back that becomes part of the conversation. It wraps the model in a bit of scripted scaffolding without touching the model itself, which is how you get deterministic behavior out of something that’s otherwise improvising.

I wired up two. One runs when a session starts: it asks the memory for anything relevant to the project I’m in and drops it into the context, so the agent opens already knowing what earlier sessions worked out. The other runs when the agent finishes a turn: it reads the final message and saves anything I marked with a <remember>...</remember> tag. The agent chooses what’s worth keeping, and the hook guarantees the saving actually happens instead of relying on the agent to call a tool it might forget.

My first marker was [REMEMBER: ...]. It broke instantly, because facts are full of brackets, an array index here, a regex there, and the script kept slicing each fact off at the first ]. The XML-style tag has no such problem, so I switched.

Why Nix makes this practical

Wiring a memory into three different agents on every machine I own sounds like the kind of fiddly per-host setup that never stays consistent. In Nix it’s a single description. One entry in my config defines the memory server, and it emits the correct configuration for both Claude Code and Codex on its own. The hooks are scripts pinned to exact versions of their dependencies, so they behave the same everywhere instead of depending on whatever Python happens to be on the machine. I commit it once, and every host wires its agents to the same brain.

The store itself, the database on my always-on box, is the one stateful piece that lives outside Nix. Everything that connects to it, every agent, every hook, every credential, is declared and version-controlled. If I rebuild a laptop from scratch, it rejoins the shared memory automatically, because rejoining is just part of what the config already says the machine is.

What I expect to learn

This is the part I’m genuinely unsure about, and that’s why I built it instead of theorizing. The open question is whether a memory like this compounds into something useful or just fills with noise. Does the store gradually become a real shared base of knowledge about my systems, or a junk drawer of half-duplicated facts? I already know some of the limits. There’s no deduplication yet, so the same fact saved twice in different words shows up twice. And coverage is partial by design, since it only remembers what an agent thought to flag, which means it catches explicit decisions well and lets the ambient stuff slip by.

The honest test is time. In a few weeks I’ll be able to tell whether sessions actually feel more continuous, whether recall surfaces things I’m glad to see or things I scroll past, and whether the gaps annoy me enough to add the next layer. That layer would be a job that runs a local model over old sessions to backfill what got missed, still on my own hardware, still free. I set myself a reminder to check in, by handing it to my assistant, which felt like the right way to close the loop.

Either way, the foundation is the part I’m confident about. The agents share one local memory, it costs nothing to run, and the whole thing is described in a config I can read top to bottom. What grows on top of that is the experiment.