A Genius With Amnesia: Teaching My AI to Remember
Every conversation used to start the same way. Catching up. Explaining what we were working on. Reminding each other where we left off. Re-establishing the shorthand that made the last session flow.
Every. Single. Time.
How I Use Claude
Before the memory system makes sense, you need to understand the setup it sits inside.
I don't use the Claude app. No web interface. No desktop client. No sidebar of saved conversations or suggested prompts. I run Claude Code from the command line, launched through CLAW — a launcher I built myself. Terminal only. Just me, a prompt, and the filesystem.
That's a deliberate choice. I wanted to understand what the tool actually does — not what a polished UI decides to show me. Every file it reads, every command it runs, every decision it makes — I can see all of it. Nothing is hidden behind someone else's interface.
It takes longer sometimes. There are conveniences I'm choosing not to use. But the tradeoff is understanding and independence. I know exactly what's happening in my system, because I built the system myself.
The memory came out of that same philosophy. If I'm going to build my own way of working with AI, I'm going to build all of it — including the parts the app doesn't give you.
The Problem
Working with an AI co-engineer from the CLI is like working with a brilliant contractor who gets total amnesia every time they leave the room.
They can write kernel drivers. They can debug registry hives. They can reverse engineer HID protocols from a hex dump. But close the terminal and open a new one, and they have no idea who you are, what you're building, or what you tried yesterday.
The Claude app handles some of this for regular users — conversation history, project context, things that persist between sessions through the platform. Running from the CLI, you don't get any of that. Every session starts completely blank. Raw.
I was spending the first fifteen minutes of every session re-establishing context. Here's the repo. Here's where the project is at. Here's what we tried last time and why we changed direction. Here's how we like to work together.
Multiply that by two or three sessions a day across months of building, and it stops being a minor annoyance. It becomes the bottleneck. Not the AI's capability — just the cold start.
The Fix
The fix came from thinking about it the same way I think about any engineering problem: what does the tool have access to, and what can I build on top of it?
Claude Code can read and write to the local filesystem. That's the hook. Instead of hoping the AI remembers things it can't remember, I gave it a place to write things down — and instructions to read them back at the start of every session.
The system is a collection of markdown files with a simple index. Each file covers one piece of context. When a new conversation starts, Claude reads the index, loads what's relevant, and picks up where we left off.
No database. No cloud service. No third-party tool. Just text files and a convention I defined. It sits alongside the project instructions that Claude Code already supports, extending them into something that grows over time.
I built the persistence layer myself, the same way I built the launcher. From the ground up, on my terms.
What Gets Remembered
The memory is organised into types, each one serving a different purpose.
User context captures who I am and how I work. My background. The fact that I'm a single parent fitting engineering sessions around school runs. Not because that's technically relevant, but because it shapes the pace and style of how we work together. Someone who tinkers with kernel drivers and soldering irons needs a different kind of collaboration than someone writing their first script.
Feedback is corrections and confirmations. "Don't generate docs unless I ask." "Kill the previous dev server before starting a new one." "Only promote what's physically built." These are the things I used to repeat every session. Now they're written down once and applied automatically. This is the memory type that saves the most frustration — every correction I only had to make once is a correction I never have to make again.
Project state tracks what's happening across the work. Which projects are active, which are parked, what was tried last session, what's next. The VirtualController driver has been through dozens of sessions — from first BSOD through IOCTL debugging to VHF enumeration. Without persistent state, I'd have been re-explaining the driver architecture every single time.
References point to external resources. Where to deploy test drivers. Which device is the test tablet. What SSH pipeline to use for remote work.
The Running Brief
The most important piece is the running brief — a single document that gets updated at the end of every session with what we did, what's next, and any notes for the future.
When Claude starts a new conversation, the first instruction is: read the running brief and tell me what you see.
A typical brief might say the VHF driver is working and committed, the next step is testing the DLL backend, and there are cleanup tasks pending on two machines. When I open a new session, I don't have to say any of that. Claude reads it and says "from the brief: VHF driver is committed, next up is VCClient testing." And we're straight in.
On the CLI, without conversation history, without any platform remembering what happened last time — this one document is the difference between starting cold and picking up warm. The fifteen-minute preamble is gone.
"Remember For Reboot"
The phrase that makes it work day to day is "remember for reboot."
If I discover something important mid-session — a debug technique, a root cause, a decision about architecture — I say "remember that for reboot" and it gets written into the brief or the appropriate memory file immediately. Claude confirms what it saved so I know it stuck.
It's become a reflex. Like hitting Ctrl+S, but for context.
At the end of a session, the brief gets updated automatically. Current work moves into the history section. Active threads get refreshed. Anything resolved gets cleared. The system is always ready for the next conversation to pick up cold — because on the CLI, every conversation is cold.
What It Actually Feels Like
Before the memory system, every session felt like day one. The AI was capable but contextless. It would suggest approaches we'd already tried and abandoned. It would use the wrong brand name. It would generate documentation I didn't want. It would ask questions I'd already answered three sessions ago.
Now it feels continuous. Not perfect — it's still reading files, not truly remembering — but the effect is the same. The AI knows the projects. It knows my preferences. It knows what we tried last week and why it didn't work. It knows not to open extra windows, not to oversell features that aren't built yet, not to write multi-paragraph docstrings.
The difference is most obvious on long-running projects. The VirtualController driver has been through weeks of development across dozens of sessions. Each one built on the last. The DLL debugging saga that nearly broke the X52 configurator — the lessons from that are in the memory now. The next time something similar happens, we won't repeat the same spiral.
And because it's all plain text on my machine, I can see exactly what Claude knows about me and my projects at any time. No guessing what's in some cloud-side profile. No wondering what data is being used to shape responses. The memory is mine. I wrote the rules for it. I can read every word of it.
What It Doesn't Do
It's not magic. Memories go stale. Sometimes Claude references a function that's been renamed or a file that's been moved. The brief needs manual nudges when priorities shift. It can't infer context that was never written down.
And it's not learning. There are no weights being adjusted, no fine-tuning happening in the background. It's just a system reading its own notes. The intelligence was always there — what was missing was the context to apply it well.
Why Build It Yourself
People will ask: why not just use the app? It has conversation history. It has projects. It probably handles this better than a handful of markdown files.
Maybe. But I don't know how. I don't know what it stores, where it stores it, how it decides what's relevant, or what it quietly drops. I can't read the memory. I can't edit it. I can't delete the parts that are wrong. I can't inspect the system that's shaping my experience.
From the CLI, I can.
Every file. Every rule. Every preference. Every correction. All of it is text I can open in an editor. When something's wrong — a stale memory, a bad assumption, a preference that's changed — I fix it the same way I'd fix a line of code. Open the file, change it, save.
That transparency is the whole point. Not just of the memory system — of the entire way I work with this tool.
I'm not the fastest user. I'm not the most efficient. But I understand what's happening, and I built it, and it's mine. That matters to me more than convenience.
The Principles
For anyone who works with AI tools and wants to try something similar:
Give it a place to write things down. A folder. Markdown files. An index that lists what's stored. Nothing fancy.
Structure the memory by purpose. User context, feedback, project state, and references are different kinds of information with different lifespans. A brand name correction lasts forever. A project status changes weekly.
Make one file the priority. The running brief — what happened last time, what's next, what to watch out for — is the single highest-value document. Everything else is supporting context. The brief is what turns "what are we doing?" into "let's go."
Build in a save reflex. "Remember for reboot" or whatever phrase works for you. Make it easy to persist context mid-session, not just at the end.
Keep it plain text. No databases, no embeddings, no vector stores. Files you can read, edit, and delete yourself. Transparency matters more than sophistication.
The whole system is maybe ten kilobytes of text across a few dozen files. It carries months of context.
What I Learned
1. Memory is a file problem, not an AI problem. The model doesn't need to literally remember. It needs access to what was written down. The simplest possible persistence — text files on disk — turns out to be enough.
2. The running brief is the highest-value document. Everything else is nice to have. The brief is essential. It's the difference between a cold start and a warm handoff.
3. Feedback memories prevent the most frustration. The things that annoyed me most were the repeated corrections. Don't do this. Stop doing that. I already told you. Writing those down once eliminated an entire category of friction.
4. Context is the bottleneck, not capability. The AI was always capable of doing the work. What it lacked was the context to do it well. Giving it memory didn't make it smarter. It made it useful from the first minute instead of the fifteenth.
5. Understanding beats convenience. I could use the app. I could let someone else handle the persistence, the UI, the memory. Instead I built it from the CLI up, and I know exactly what every piece does. That understanding compounds. Every session I run, I understand the tool better than I did the session before — because nothing is abstracted away from me.
The Bigger Picture
This is what working with AI looks like when you strip away the product layer and build on the raw tool.
No chat history provided by a platform. No curated UI deciding what context to show. No algorithmic selection of which memories matter. Just a terminal, a filesystem, and conventions I wrote myself.
It's slower. It's more manual. It requires me to think about things that other users never have to consider. But it means the system I've built is genuinely mine. I understand every part of it. I can modify any part of it. And when it works — when I open a new session and Claude already knows the projects, already knows my preferences, already knows what we did yesterday and what's next — that's not a product feature I'm consuming. That's infrastructure I built.
A genius with amnesia is still a genius. You just need to give them a notebook — and if you write the notebook yourself, you'll never wonder what's in it.
The memory system is part of how I use Claude Code from the CLI at indigo-nx.com. The launcher is CLAW.