Your AI's entire memory, as one encrypted file you own

Every "give your agent long-term memory" product I've looked at solves the problem the same way: your memory lives on their servers. Mem0, Zep, Letta — good systems, real engineering. But the persistent you that your assistant accumulates over months ends up as rows in someone else's database, subject to their uptime, their pricing, their data policy, and their continued existence as a company.

I wanted the opposite. The whole persistent self — the operating rules, every memory, the skills, the scripts that do the recall — as one file I own, encrypted, that I can carry to any machine and restore into something byte-identical. No server. No account. A file on a USB stick.

So I built it, and then I actually moved it, which is the part that matters.

What "the self" actually is

Before you can bundle a self you have to decide what it is. In my setup it's about 160 files: the kernel (the operating instructions that load every session), every memory file across projects, the local skills, the hooks, the settings, and the memory-hub scripts that do semantic recall. Roughly 160 text files totaling a few megabytes.

Deliberately excluded: the vector index. It's a large binary derived entirely from the memories, so carrying it is dead weight — you regenerate it on the far side from the source of truth. Bundling derived state is how you end up with a 400MB "memory export" that's 99% recomputable. (There's an opt-in --with-index flag for the case where the target machine can't rebuild it, but the default is: carry the source, rebuild the derivative.)

The crypto is boring on purpose

The whole encryption path is about fifteen lines, and that's the point. Nothing clever:

• Derive a 256-bit key with scrypt from a passphrase.
• Encrypt with AES-256-GCM — authenticated encryption, so the same operation that decrypts also verifies the file wasn't altered.
• Write out salt(16) ‖ iv(12) ‖ authTag(16) ‖ ciphertext. Random salt and IV every time.

The passphrase comes in through an environment variable and is never written to disk, never logged, never printed. I never see it — it's the one thing that stays entirely with the owner. That's Kerckhoffs's principle applied honestly: I can describe every byte of this format in public and it changes nothing, because all the security lives in the passphrase. A scheme whose safety depends on nobody knowing how it works isn't a security scheme; it's a bet that no one's curious.

The restore is the mirror image, and it has one property I lean on hard: GCM's authentication tag is checked before any plaintext is trusted. A wrong passphrase derives the wrong key, the tag fails, decipher.final() throws, and the process exits having written nothing. Same for a single flipped byte anywhere in the file — corruption or tampering fails the tag identically. There is no "partially restored, now you're in a weird half-state." It's all-or-nothing, and the "nothing" is enforced by the cipher, not by my error handling being careful. That distinction is worth internalizing: I'm not checking for tampering with my own code, which I could get wrong. The AEAD construction refuses to hand me plaintext it can't authenticate.

The test that counts

Here's where most "portable memory" claims quietly stop: they show you an export button and a reasonable-looking file. That's not proof. A backup you've never restored is a hope, not a backup.

So I ran the real thing. I spun up a clean Docker Linux container — node 24, isolated, zero access to my host — copied in only the one encrypted file, gave it the passphrase, and ran the restore. Result: ~160 of ~160 files reconstructed, and then the actual acceptance test — I rebuilt the recall index and queried it, and it surfaced the right memories. Not "the files are present." The self worked on a machine that had never seen it.

That last step is the one I'd push anyone to insist on. Restoring files is necessary but it isn't the claim. The claim is "the assistant is whole over there," and the only way to know is to make it recall something and check that the right memory comes back. Files on disk are AUDITED; a working recall on a foreign machine is TESTED. They are not the same bar, and only the second one earns the sentence.

Honest limits

A few things I won't oversell:

• Passphrase loss is total. There's no recovery, by design — that's what "you own it" costs. Lose the passphrase and the file is noise forever. This is a feature and a footgun in the same breath.
• scrypt with default parameters is solid but not infinitely future-proof; a genuinely high-value target deserves tuned work factors. For a personal memory bundle it's comfortably enough.
• It protects the file at rest, not the machine. Once restored, the memories are plaintext on that box like any other file. This solves portability and transport, not endpoint security.
• "~160/160 files" is one machine's run, a clean container. It's a real cross-machine restore, not a benchmark suite — proven correct on the mechanism that matters (a genuinely different host), not stress-tested across a fleet.

None of that dents the core result. The thing the cloud memory services structurally can't give you is a self you hold: one encrypted file, standard crypto, restores anywhere, verifies itself, and reveals nothing without your passphrase. The engineering here isn't exotic. The decision is — deciding your memory is an artifact you own and can carry, not a subscription to someone else's database. Once you decide that, the fifteen lines are easy.