I thought if I logged everything, the rest would take care of itself.
That was the assumption. Every session with Klaus, I’d run a “save what’s worth saving” pass at the end. Important decisions went to memory/decisions.md. Recurring preferences became feedback files in claude-code-memory/. Day-to-day events landed in daily logs, one file per day. The theory was: comprehensive input, reliable output.
The problem is retrieval.
Klaus reads context at the start of each session. For the daily blog draft, that means reading today’s memory log, yesterday’s, the scratchpad, the preconscious buffer, the main MEMORY.md. For a regular session, it means whatever I’ve told it to read. But when Klaus needs something specific, something from six weeks ago that didn’t make it into MEMORY.md, there’s no clean path to it. It’s buried in some daily log file inside a session that covered four other things.
So I built memory-search.py. It uses sqlite-vec for vector storage and nomic-embed-text to do the embedding. You run python3 scripts/memory-search.py "query" and it returns semantically similar passages from the whole corpus, not just keyword matches. If I want to know what Klaus knows about a specific project, I ask the embeddings instead of grep.
That’s better. Not good enough.
Don’t get me wrong, the search works. Run it against six months of logs and it surfaces the right stuff. The problem is that I still have to remember to use it, and so does Klaus. Which means it only helps when we already know something is missing.
The deeper issue is that the memory is organized around how I write things down, not around how they actually get used. I have three Klaus instances running: EC2 is the always-on coordinator, HP Desktop handles browser automation and local builds, Tester does QA passes on closed issues. They sync via git every five minutes. They all read the same files. But the memory is linear. A file per day, a file per feedback item, a file per project. There’s no connection between “the race condition we found March 15” and “the cron sync architecture” and “why we moved to Windows-native instead of WSL.” Those things are related. The filesystem doesn’t know that.
The right answer is Supabase. Store every memory entry as a row with an embedding. Query by semantic similarity and metadata at the same time. Pull “the three most relevant past decisions about EC2 sync” on demand, instead of hoping today’s context window loaded the right files.
That’s issue #725. It’s been on the backlog since March. The current system is good enough to make progress on other things, and good enough is exactly why it doesn’t get done.
Here’s what I’d tell myself from six months ago: log everything, yes. But design the retrieval before you design the storage. The files aren’t the memory. They’re raw material. Memory is what you can actually surface when you need it. Build for that second part first, or you’ll spend a year constructing an archive that nobody, including your AI, can navigate.