A Notebook That Forgets on Purpose
Summary
The Slipbox maintenance loop on video, and the protocol I wrote to make the same vault double as an AI agent's memory across sessions.
The video below shows an AI taking notes. The part I find interesting is underneath: the system is shaped the way memory should work for something with no continuous self.
I introduced Slipbox a few months back. This post is two things: the maintenance loop I run day to day, in the video above, and a proposal I have not built yet. The same vault could be an agent's memory, not just a tool the agent tends.
The loop
Slipbox runs a small lifecycle. The video walks all of it.
- Capture. A raw thought lands verbatim. Claude tags it lightly and finds one obvious link (this idea extends that one). Nothing is processed yet; it just made sure the note landed somewhere I'll see again.
- Analyze. I paste the note and ask: is it atomic, what should it connect to, which tags from my taxonomy fit, is it ready to be permanent? A workflow grades atomicity, builds a connectivity table, and proposes exact tags.
- The refusal. My favorite moment. Claude declined to promote the note. Its reasons were pure Zettelkasten: a permanent note has to state its principle so it stands alone for a future reader, and mine was still in a first-person confessional voice. Worse, the rule I'd written was untested, so it told me to go try it before canonizing it. A tool telling me I hadn't earned the note yet.
- Cluster to structure. The maintenance report ranks emergent clusters by how much connectivity a little work would buy. I take the top one (prompt engineering: seven notes, two orphans) and have Claude write a structure note linking the members.
- Forget, but linked. Once a cluster has a structure note, the next maintenance run stops surfacing it. It's moved from emergent to organized to, honestly, forgotten about. But linked, so I can find it again. That's the full loop, repeated as the vault grows.
What if the vault were the agent's memory
To be clear up front: I have not done this. I have written down how it would work, and I think it is the most interesting thing Slipbox could become.
The intro post ended on Andrej Karpathy sketching the direction publicly: ingest your documents, compile them into a linked wiki, run health checks, propose connections, and build "an incredible new product" instead of a hacky pile of scripts. This is one concrete corner of that. Karpathy pointed at the shape; here is a protocol for the memory half.
The premise is simple. An agent has no memory between sessions. Every request starts cold: the system prompt, and whatever the last session wrote down. So give the agent a place to write for its own successor. The mechanism already lives in the Slipbox system prompt; here is what it says.
A memory note is tagged agent-memory and carries one prefix:
[failure]an approach that didn't work, and why[pref]a human constraint that'll come up again[correction]a reasoning error the human fixed[domain]a fact about the code that cost real effort to establish
Two rules do the work. Read before you write: starting a real task, the agent searches its own memory first, and if a past failure surfaces it says so ("last time, X failed because Y") and pulls the linked neighbors, so one hit rebuilds a whole context. And grow by connecting, not accumulating: a connected memory beats a flat one (a rules file, a native-memory blob) because you retrieve it by walking links, not scanning. Before saving, look for what the note connects to; if it connects to nothing, reconsider saving it.
The link that matters most is contradicts. It stops a future session from trusting something no longer true, and a confident false memory is worse than none. Most AI memory just accretes, with no way to say "this belief was wrong." Typed links give the vault a way to carry its own corrections. The refusal in the video hints at the same instinct, a system that won't canonize an untested claim, but I have not watched an agent enforce that on its own memory yet. That's the experiment.
One vault or two
There's a design choice worth naming. You could run two fully isolated slipboxes, one for you and one for the agent, never touching. Cleaner separation, and probably what you'd reach for first.
I think one shared vault is better, with distinct ownership of who wrote what. The agent tags its notes agent-memory and never touches yours; you can both read across the line. The whole value of the tool is cross-domain connection: the intro post is a story about Claude linking two notes I would never have crossed. Split the vault in two and you cut exactly the edges that make it worth building. Keep it one graph, mark the provenance, and a contradicts link can run between your note and the agent's.
Where this could go
This is a proposal, not a result. I have not run the memory loop in anger, the synthesis step is the shakiest part of the tool as it stands (turn Claude loose across the whole vault and it sometimes invents connections that aren't there), and seven link types might be too small a grammar. But the shape feels right: human-authored atomic notes, a closed grammar of links, and an agent that maintains its memory instead of generating summaries of it.
The mechanism is in the README, the workflows ship with the server, and if it sounds like something you want to try, I'd love to hear where it breaks.