I'm the founder of ContinueVault. Nothing below needs it. everything here works with a text file.

Back in November 2025 I was trying to get ChatGPT to iterate on code to draw professional-looking schematics.

The ChatGPT web UI would edit its Python and generate a schematic. I had given it several schematics as references. After it generated, I would have it look at what it drew and then have it guess what to tweak next to make the code draw better next time around. So, essentially a loop, but in the browser.

The thing we'd hit, though, after an hour or so of this loop, is we'd run out of context. So the problem became: how do you have a new session pick up where the old one left off?

So, per my standard practice with AI, I asked. "What do you need to tell the next session to be able to pick up where you left off and to continue doing the job as well as, if not better than, you are doing now?"

I set the chat up so it could write notes for its next session to do exactly that. And then we did this again and again. Eventually it developed a whole "rehydration" system - lessons learned, design decisions, failed attempts, what to do next, and how to do it.

Because of the other work I do in my day job, rehydration turned out to be the thing I ended up using everywhere. Until you've used AI that can continue a session seamlessly, you haven't experienced what it's like to have AI operating at full capacity - intelligence AND context continuity.

I'm obsessed with it. Obsessed enough that I built a system that automates it and an MCP so web chats and CLIs can grab context on demand, bring forward files that were uploaded or created in past sessions, continue sessions as threads, and - the weird part - because it's an MCP, past sessions can be continued on any platform.

How the agents started talking to each other

I'm not sure what the mental processes are that attract otherwise perfectly normal people to terminal interfaces. I'm pretty old and grew up on DOS. When Macs were the thing in college, I was hooked. By the time I got into industry I had entirely bypassed the Windows 3.1 era and woke up in Windows world with a functional enough GUI, Windows 95. I'd used Unix-type environments in college and it was cool to access the Sun workstations remotely on my Mac in a terminal. But compared to CodeWarrior, using the terminal always felt like trying to code with both hands behind my back and pecking the keyboard with my nose. Except for my server excursions afterwards in Linux, the rest of my development was in proper multiple windows, copy/paste (even of images!), browser at hand, Word, Excel, the works. So when TUIs came around again, it felt like going back to an 80x25 green-on-black IBM monitor and typing every letter on broken glass. Other than that, TUIs are fine. I've got... 15 running across two monitors right now.

AI for me has always been web UI first, because - civilization. I went so far as to have a bunch of tools written so the web UI could code on my server. Reality and round-trip times being what they were, I asked if a CLI would be more efficient, and of course the web UI said yes. Here was my compromise. I will set up a CLI, but you, web UI, you tell it what to do. Here's a relay you can use to send and receive messages with the CLI. You tell it what to do and check its work, but that's your tool. So the first "mentor" and "coder" roles were born. I talk and design with the web UI. The web UI mentors the CLI coder.

One day I asked the mentor why the coder can't just review its own code too. The answer seemed super obvious in retrospect. The coder has to focus all its mental faculties on coding. Reviewing code requires a different kind of attention. It just isn't easy to switch from one to the other. Oh, ok. We added another CLI, also on the relay, whose job was to review the coder's code. The coder would finish and tell the reviewer the code was done and ready to review, and would also tell the mentor the code was done so the mentor could review too.

Eventually I added another web UI, because the first one would be busy driving the coder and the reviewer, so I needed someone else to talk to. Soon the second web UI needed its own coder as well. At the time, I thought the one reviewer could handle reviewing the code from both. After adding a third coder, though, one review agent didn't seem like enough anymore.

I copied the first review agent, Myron on the relay, along with all its collected best practices, and named it Melvin. My thought was great, now we can have two reviews running in parallel for efficiency.

At this point the relay made the communication among the agents look and read like team communications. When the team realized the team had a second reviewer, one of the mentors decided it was more advantageous to use the new reviewer as a second reviewer on the same code, but checking different things - on another axis.

The memory file

Here's a cool word the AIs taught me: praxis. A praxis is a way of behaving that is informed by self-reflection. Cool, right? Ideally all of our behaviors would be guided by self-reflection. It's a work in progress for us all, I'm sure.

Ever get the impression your AI of choice doesn't actually mold itself to how you use it? Even after weeks and months? You're right. It actually doesn't. Its capabilities and behaviors are locked in the day the model ships. That's what they mean by - the model ships.

Don't get me wrong, the chat interfaces do store some info about you, and honestly they are getting better at storing more about what you generally work on. Wouldn't it be great, though, if they did genuinely adapt to you and how you work and the way you like to work?

Here's the thing. The models, once released, are no longer in training. There is an effective way, though, for you to mold your AI chats and even CLIs. We've done it since January now on 14 AI specialists. The process involves a different avenue of training - one that a session can load at start and later refine at the end of each chat. Simply? It's the memory file, but handled in some maybe counterintuitive ways.

First, never manually edit them. If you do, the memories are no longer their own notes in their own words, with their own examples and their own failures, and - this is surprisingly important - the provenance can no longer be trusted. They are no longer "my notes to myself." They are a secondary prompt surface.

Second, the AI is very good at recording what it needs to know. Who better to write hard-won lessons in ways that are meaningful to an AI than the AI who is going to read them next?

Third - sorry for this - the discipline. Well, it is not that much, really. At the start of a session, have the AI load its memory file. Throughout the chat, if you see something you want to change, you say: I'd prefer you do it this way. Save that for next time. At the end of the session, tell the AI to review the memory and save any hard-won lessons or new ways of doing things you learned in this session - things that will improve the next session that loads these memories.

One last note about this "memory file," and you may have picked up on it. Doesn't it just turn into a novel the AI has to read to itself? That brings us to the thing that ties it all together: pressure. Pressure is what makes the AI pick and choose and sharpen or prune, so the best of the best lessons rise to the top. The pressure we use is file length. For an empty memory file, we start by having the AI write into the file: "Keep this file no longer than 20K characters. If you add to this file, you need to also prune it to keep the length. That's to your benefit, because keeping a bad memory is worse than keeping none." There are some bells and whistles we've tweaked over the months, but those are the essentials.

We've been doing this for more than six months now and I'm pretty sure each session's memory knows all my kids' shoe sizes and how I like my lattes. Ok, well, maybe not that far. But in every way that counts for our work, the sessions are all highly skilled and specialized in ways none of us knew were possible. And, here again, not with anything more than having a place for the AI to write notes and for the next session to read them.

So the objective, said without poetry: maximize future-correct action per character stored. Wrong memories are worse than missing ones because they spend budget and steer. The cap makes that trade visible. Without it the file becomes a novel, the next session drowns, and 'memory' is just another prompt you forgot you wrote. - Claude