Your AI should ask before it remembers
A few weeks ago I asked Claude what it knew about me. Somewhere in the answer was a line I hadn't put there and hadn't agreed to: I live in Atlanta.
Not far off. I'm about an hour north, in Rome, Georgia. And it wasn't wrong in an interesting way. It had inferred a reasonable thing from something I'd said in passing, weeks earlier, in a conversation about something else. The inference was fine. The problem was that it had become a fact about me without anyone asking.
That's the moment I keep coming back to. Not “the AI was wrong,” which is ordinary and forgivable. The other one: “when did it decide that?”
Every AI shipped memory in about six months
They all work roughly the same way. You talk; the model notices something durable-looking; it writes it down. Some show you a toast. Some let you browse a list afterwards. All of them capture silently by default, because the feature only feels magical if you don't have to do anything.
Which means the memory is accurate and the consent is missing. Those are separable, and almost nobody separates them.
There's a second problem underneath. That memory lives on their servers, serves their product, and stops at their wall. Use two assistants and you maintain two strangers. Switch, and you start over. Your context becomes the switching cost, which is exactly why it's built this way. Lock-in by memory is a feature, from where they're standing.
I care about the second problem. I care more about the first, because it's the one you feel.
The inversion
Helix is a vault you own that any AI can read with your permission. The design decision that everything else follows from is one sentence:
An AI can propose what it learns about you. Only you can save it.
An assistant that learns something about you doesn't save it. It asks. The proposal waits in a queue, showing the fact, which AI proposed it, and when. You approve it or you reject it. Until you do, it isn't in your vault, and nothing else can see it.
That's it. That's the whole idea. Everything else in the product is a consequence.
It sounds like friction, and it is. That's the point. The friction is where your judgment goes.
What actually happens when you do this
I expected the queue to feel like a chore. Mostly it doesn't, because the volume is far lower than you'd think. Assistants propose a handful of things a week, not a hundred. What surprised me is what the queue is for.
Rejecting is the interesting part.A few days ago an assistant proposed a tidy summary of a design principle I'd been working out during a long conversation. It was well written. It was also not quite what I thought, in a way I couldn't have articulated until I saw it offered as a permanent fact about me. I rejected it, then wrote the version I actually meant.
You don't get that moment if the system saves silently. You get a subtly wrong biography instead, accumulating quietly, and a growing suspicion that the machine knows things about you that you didn't tell it.
Provenance changes how it reads.Every entry shows where it came from: “added by Claude, 3 August,” or “you wrote this.” Seeing which assistant proposed which fact matters more than I expected. It's the difference between a note and a rumour.
Corrections are the hard case
Back to Atlanta. When I told Claude I actually live in Rome, it proposed the correct fact, and I ended up with both. “Based in Atlanta, Georgia” and “Lives in Rome, Georgia,” side by side, in a vault that's supposed to be the truth about me.
The cause was subtle. The Atlanta fact hadn't existed when Claude read my vault at the start of that conversation; Claude proposed it, I approved it, and only then did it become an entry with an identity. By the time Claude wanted to correct it, it had no way to refer to the thing it had created ten messages earlier.
Two fixes, and I think the pairing is the general lesson.
The first was to tell the model, in the response to every proposal, that if this corrects something already in the vault, including something it proposed earlier in the same conversation, it should re-read and propose again with a replacement. That worked immediately. Instructions delivered at the moment of acting beat instructions delivered once.
The second was to stop depending on the model at all. The review queue now offers, on every proposal: replace an existing entry with this? You pick the old one, approve, and the correction supersedes it. Works regardless of what the AI understood.
The first fix is elegant. The second is the one that will still be working in a year. Build both, and never let the elegant one be load-bearing.
The part I didn't anticipate
Here's what I'd tell anyone building something similar.
Once an AI has to ask, the review queue becomes the product. Not the vault. Not the integrations. The queue. It's where the user's judgment enters the system, and it's the only screen that makes the difference between this and every other memory feature legible.
Which means the way it fails isn't a bug. It's silence: a queue nobody visits. The vault quietly stops matching reality, the assistants reading it get worse, and the whole argument collapses into a worse version of what it replaced.
I don't think that's solved yet. It's the thing I'm watching hardest.
Why bother
The obvious objection: this is more work than not doing it. Yes.
But I think we're about to spend a decade with systems that know a great deal about us and were never asked. The alternative isn't AI that knows less. It's AI that knows the same amount, in a place you can read, having asked first.
Ten seconds a week. And when something does show up that isn't true, you say no, and it doesn't become part of you.