You Should Own Your AI Memory
The Memory Problem Nobody Is Talking About AI assistants are getting genuinely good at remembering things. Your preferred output format. The tech stack you work in. Your timezone, your team structure, the fact that you a…
ToRun Team
AuthorThe Memory Problem Nobody Is Talking About
AI assistants are getting genuinely good at remembering things. Your preferred output format. The tech stack you work in. Your timezone, your team structure, the fact that you always want citations. This persistent context makes AI dramatically more useful — you stop re-explaining yourself with every session, and the assistant starts feeling like a collaborator rather than a search box.
But a quiet dependency is building alongside that utility. The assistant remembers things about you, and you do not control what it remembers. You cannot easily audit it, you cannot export it in a portable format, and when the provider decides to change its memory product — or simply discontinues it — you have no recourse. You lose not just the convenience, but the accumulated context that took months of interactions to build.
This is not a hypothetical. It is the default state of every major AI platform today.
Three Rights That Should Be Non-Negotiable
The data-rights conversation is not new. GDPR, CCPA, and a decade of debate around social platforms established that users have legitimate claims over their own data. AI memory should be subject to the same norms. Three specific rights matter:
The right to inspect. You should be able to see a plain-language list of every fact the system has retained about you. Not a vague summary, not a marketing-speak "personalization profile" — the actual stored facts, reviewable at any time. If the system thinks you are a backend developer who prefers concise answers and dislikes passive voice, you should be able to read exactly that.
The right to forget. Any stored fact should be deletable by the user, individually or wholesale, with immediate effect. The delete should be real — not a soft-hide that still influences model behavior internally — and it should be verifiable. "I deleted that" should mean the model no longer acts on it.
The right to export and port. If you have spent a year building up a useful memory context with one provider and you want to move to another, you should be able to take that context with you. Memory portability is the same problem as data portability in any other category. The fact that it involves a vector embedding or a JSON blob rather than a spreadsheet does not make it conceptually different.
None of these rights require giving up product quality. They require treating users as principals rather than data sources.
Why Platforms Resist This
The resistance is not primarily technical — it is structural. Memory context is retention infrastructure. A platform that has learned your preferences deeply has a switching cost advantage over one that hasn't. Making memory portable or easily deletable weakens that lock-in, and most product teams optimizing for engagement metrics will quietly deprioritize user control.
There is also an epistemic problem: the teams building memory systems often do not know exactly what the model has retained, because memory is frequently not a clean structured list but an emergent property of embedding space or soft fine-tuning. Providing a clear audit trail requires explicit architectural decisions — storing memory as inspectable, structured facts rather than as opaque model state — and those decisions have to be made early.
Retrofitting auditability onto an opaque system is expensive. Building it in from the start is not. The choice reflects priorities.
Where ToRun Stands
Memory in ToRun is stored as explicit, user-readable facts. You can list everything it knows about you, delete individual items or all of them, and the deletion is immediate and genuine — it affects what the model sees on the next turn. The memory system is also language-agnostic: it works across all 29 locales the platform supports, without requiring you to interact in English to get reliable recall.
We did not build it this way because we were forced to. We built it this way because the alternative — storing memory as a black box the user cannot interrogate — is incompatible with the honest-UX principles that drive the product. If a user asks "what do you remember about me?", the system should be able to answer that question completely and accurately, not approximate it.
Export portability is on the roadmap. The underlying facts are already structured; serializing them to a portable format is a matter of building the endpoint, not re-engineering the storage model.
This is a narrow claim: that your AI memory should belong to you, should be readable by you, and should be deletable by you. It is not a controversial position. The industry should converge on it faster than it has.