Building a persistent memory system for AI agents is one problem. Operating it at scale
is a different one. After two months of daily use, memstore holds around 1,500 active facts
across a dozen projects – project architecture, coding conventions, design decisions,
cross-cutting invariants, and roughly a thousand symbol-level descriptions generated by
running an LLM over every Go function in every codebase I work on. The system works. The
recall pipeline surfaces relevant context on every prompt without manual search. But getting
from “works” to “works well” required a series of scoring adjustments, noise filters, and
feedback mechanisms that the original design didn’t anticipate.
Most memory systems for AI agents treat knowledge as a key-value store. Write a fact, overwrite it later, old value is gone. That works for simple preferences – “use dark mode” doesn’t need a paper trail. But knowledge that evolves over time is a different problem. When a design decision turns out to be wrong, or a project’s architecture shifts, or a dependency gets replaced, you don’t just want the current answer. You want to know what you believed before, when it changed, and ideally why. Losing that history means losing the reasoning trail, and reasoning is the expensive part. Memstore’s supersession system brings version control semantics to AI memory: facts get replaced, not erased, and the full chain of revisions is preserved.
Claude Code sessions start with amnesia. Every conversation begins cold – no memory of what you worked on yesterday, what invariants matter in the file you’re about to edit, or what tasks are still pending from last week. CLAUDE.md helps by injecting static project context, and MCP tools let the model search for facts on demand. But both of those require something to go right first: either the static file happens to cover the relevant topic, or the model decides to search before acting. In practice, the model often doesn’t search. It plows ahead with what it has, and the most valuable context – the constraint you documented last Tuesday, the task you left half-finished – stays in the database unsurfaced. This post is about closing that gap with hooks: small scripts that fire at specific points in the Claude Code lifecycle and inject relevant context automatically, before the model even knows it needs it.
AI coding assistants are goldfish with a PhD. They can solve complex problems within a single session – refactoring a module, debugging a race condition, designing an API – but the moment the conversation ends, everything they learned about your project evaporates. After months of building software with Claude Code, I found myself re-explaining the same project conventions, the same architectural decisions, the same mistakes we’d already caught and fixed, at the start of every session. CLAUDE.md files help, but they’re static and they don’t scale. You can’t stuff a dozen projects’ worth of design context into a single markdown file. So I built memstore: a persistent memory system that gives AI agents durable, searchable knowledge across sessions, projects, and machines.
I play in two weekly D&D groups and write session reports as narrative prose from the characters’ perspectives. The reports expand on what happened at the table, adding dialog and internal monologue in each character’s voice. This workflow has evolved through several iterations, each one solving a problem the previous version left on the table.
How it started
The first version was simple: play the session, take notes, write the report from memory afterward. This worked when I had time, but a four-hour session generates a lot of material, and between work and life, writing sometimes slipped by a week. By then the details had faded. The bullet-point notes I’d scribbled during play were thin on dialog and light on the small moments that make session reports worth reading.
In the early days of the internet, and even before that, there was a distinct difference in the terminology used for the people who obtained unauthorized access to computer systems. The term hacker meant someone who created an interesting hack, usually something interesting that used a system – not necessarily even a computer system – to do something outside its design intent. A Rube Goldberg machine
is a good example of a hack. So is playing music with printers
. Conversely, cracker was applied to people who broke into computer systems for nefarious purposes. There was often some overlap between the two, as people making interesting hacks often didn’t have authorized access to the systems they were using.
Last weekend, I took the certification exam to become a GIAC certified incident handler
. Both the exam and the course material leading up to it were interesting enough to deserve a few comments.
One thing I was moderately surprised by in the SANS course
was the initial focus on Linux shell tools and Windows Powershell. I’ve been using Linux for a long time, so there weren’t any surprises there. The Powershell material was new to me.