A Design Exercise That Wouldn't Stay Small
I spent a few days designing something I may never build: an AI companion for one child, from age six to eighteen. Persistent memory, one kid, twelve years. The starting question was pedagogical (could a companion rebuild attention span instead of eroding it), but the interesting problem turned out to be underneath: what does it mean to hold twelve years of a child's private conversations?
Every answer I tried collapsed into one of two failure modes.
Keep everything, and you've built a surveillance log: a database of a child's inner life, readable by whoever holds the account, sellable in an acquisition, subpoenable, breachable. Summarize and discard, and you've built a stale cache: a system that "remembers" a person through embeddings computed years ago, speaking for a kid who no longer exists.
My first architecture chose amnesia. Raw transcripts lived a few weeks, then were destroyed on schedule. What survived was a curated ledger: the kid's own words about each session, nothing else. The transcript was a liability with a scheduled death.
It felt principled. It was wrong.
Deletion Defends Against the Wrong Party
Scheduled destruction was defending against the operator: the company that could leak, sell, or be compelled to produce the archive. But that threat only exists because of an assumption so universal nobody states it: the operator holds the data.
Remove the assumption. Put the entire memory instance on hardware the family owns. Now the operator threat doesn't need mitigating: there is nothing to breach, nothing to acquire, nothing to subpoena. And suddenly deletion stops being protection and starts being loss. You're burning a child's asset to defend against a party who's no longer in the room.
The threat that remains is inside the house. A teenager's private conversations sitting on a server their parent administers is still a surveillance problem, arguably the one that matters most, because the sharpest privacy conflicts in a childhood aren't corporate. They're domestic.
And the answer to that threat isn't amnesia either. It's encryption.
Hand the Kid the Keys
So the design landed here: total recall, sealed corpus, and the keys change hands.
Everything ingests. The full record is encrypted at rest on the family's own instance. While the child is young, the parent holds the keys: full transparency, which is exactly what makes the tool trustworthy at six, now enforced by cryptography instead of a privacy policy. Somewhere around eleven or twelve, in a moment negotiated once and explicitly, the keys transfer.
After that, the parent owns the hardware and cannot read the memory.
I started calling it the key ceremony, and I think it's the most honest interaction I've ever designed: a kid being handed ownership of their own past, with everyone in the room understanding what just changed. Not a settings toggle. A transfer of custody.
It comes with real costs, and they're the price of the whole idea. Lost keys mean lost memory: recovery schemes are backdoors by another name, so recovery has to be social and chosen by the kid, never a silent vendor escrow. And ownership has to include the right to delete: total recall of your own childhood includes your worst day at thirteen, and a record you can't burn isn't yours.
This Was Never About Kids
The design exercise cornered me into a general claim.
Every AI product you use today treats the conversation history as its asset. The memory lives in the vendor's database, formatted for the vendor's retrieval, gone when the subscription lapses, held hostage when the startup folds, and mined in the meantime. Your relationship with the model compounds, and the vendor owns the compounding.
Invert it:
Memory is the persistent layer. Models are interchangeable clients.
The model gets replaced a dozen times a decade: better, cheaper, smaller. The memory is the only part with compounding value, and it's the part you should own outright: sealed with your keys, stored in boring formats, documented well enough that the next system can connect to it. The assistant of 2032 should pick up your context where the assistant of 2026 left off, and no company's death or pivot should be able to take your accumulated context with it.
I already run a version of this for myself: a self-hosted memory service that my coding agents read and write across sessions. What the child-companion exercise added is the part my own setup skips because I trust myself: the custody model. Who holds the keys, when they transfer, what pierces the seal, and who can never read what. That's not a feature list. That's a protocol waiting to be specified.
The Compounding Argument
Here's the part I keep turning over.
A memory layer started in childhood has twelve years of compounding before any adult product's memory begins at all. Whoever builds the persistent layer doesn't own the data (that's the entire point) but they define the format everything else connects to.
The models will keep getting smaller. By the back half of a decade-long relationship, the inference runs at home too, and the "product" reduces to what it always really was: a format, a key ceremony, and a promise that holds because of topology rather than terms of service.
The memory outlives the model. Build for the part that persists.