Your assistant remembers things now. Every vendor ships it, it's on by default, and it works — you correct it once and the correction sticks.

Then one day it tells you something wrong, and you go looking for why. Try asking it these two questions:

What did you believe about this last Tuesday?

What did you do while I was asleep?

Neither one has an answer today. Not because the models are weak — because of how the memory underneath them works.

Memory that overwrites itself

Almost all assistant memory is a file the assistant rewrites. Teach it something new and the old belief is gone. Not superseded, not dated — gone, with nothing left to say it was ever there.

That's fine right up until the assistant is wrong, and then it's the worst possible design. You cannot tell the difference between it made a mistake and it acted correctly on something stale it learned in June. Those two need completely different fixes, and a rewritten file has destroyed the evidence that would tell them apart.

It gets worse when you teach it twice. Correct it in June, phrase it differently in August, and now two beliefs sit side by side. Nothing flags the collision. The assistant quietly picks one, usually whichever it saw last, and you find out which one the hard way.

Memory that keeps its receipts

I built the other kind, and I give it away.

Corrections go into an append-only log instead of over the top of the last one. Nothing overwrites anything. What you get from that:

  • Re-teaching supersedes. Say it differently in August and the new version replaces the old one on that subject. Your memory doesn't silt up with three versions of one rule.
  • Contradictions park, loudly. When two live beliefs disagree, the system pulls both and flags them for you. The assistant doesn't get to quietly pick.
  • You can rewind. One command reconstructs exactly what your assistant knew at any past moment. "It got that wrong" and "it was working from what it knew at 3:14 on the 9th" stop being the same sentence.

That last one changes what you can do after a bad answer. You stop guessing and start reading.

I ship the proof rather than the promise. A drill stands up three copies of the memory against real git in a temp folder and runs every guarantee above as a test — supersede chains, parked contradictions, replay, recovery from a torn write. It needs nothing but Python and git, and you run it yourself.

The half nobody builds

The second question matters more than the first, and it gets less attention.

A chat window only works while you're typing at it. Most of what you actually want from an assistant happens when you're not there — the check that runs at 4am, the thing that should have told you on Tuesday.

So underneath the memory there's a plainer layer: your jobs on a real schedule, one record per run, and a vault that keeps credentials encrypted and out of every transcript.

And one piece I'd argue is the whole point. It notices silence.

A job that fails shouts at you. A job that quietly stops running says nothing at all, and no health check on that job can see it, because the check stopped running too. Something outside has to be watching for the absence. That is the failure that gets people, and it's the one thing you cannot bolt on later.

The three questions

I judge everything I build by three questions now, and I'd suggest them for anything you're deciding whether to adopt:

1. Does it show you what you can do?
2. Does it tell you exactly what to do?
3. Does it hand you what you need?

Most tools in this space clear the first two and fail the third. The popular ones will interview you and generate an excellent plan for the assistant you should build. You end the session holding a document.

This ends the session with a scheduled job already running, a database with its first row in it, and something watching to make sure it keeps going. Not a plan for those things. Those things.

How hard is it

You paste one instruction into Claude Code and your agent does the install, working from a file written for it.

Two rules it keeps while it works. It shows you every command that changes anything before it runs it. And only scripts move bytes — the agent drives the installer and never retypes a file, so nothing quietly paraphrases your config on the way in. There's a real uninstall that removes what it added and nothing else. If you'd rather drive, the whole thing is six plain commands.

It's MIT, free, and there is no paid tier. No account, no telemetry, no network calls. It's a public alpha, and the README tells you plainly which parts I verified on real hardware, which parts only CI covers, and which control I built and then pulled because it didn't hold up.

Bring a machine that stays on and something you actually want watched.

github.com/cvp1/ai-os-seed — start with the README, and tell me what breaks.