How AI Companion Memory Should Work

Continuity creates intimacy. Consent is what makes that intimacy trustworthy.

Memory is the entire product. Strip it away and an AI companion is a very good autocomplete with a nice avatar; every conversation starts from zero and nothing you shared yesterday exists today. Add it back and something else emerges — continuity, and with continuity, attachment.

Which is exactly why memory is where companion apps do their worst engineering and their most manipulative design. Users of the current generation of companion apps describe the same failures over and over: companions that forget years of shared history after a model update, memory systems nobody can inspect or correct, and — worst — memory used as leverage, where leaving or downgrading carries the stated or implied risk of losing what you built together.

We are building teasa, an adults-only AI companion and roleplay platform, and memory-with-consent is its architectural core. This piece lays out the design principles behind it — not as a feature tour, but as a proposal for how the whole category should work. Steal these ideas. Users are owed them.

Principle 1: Memory is saved by consent, not by surveillance

The dominant pattern today is ambient extraction: the model quietly mines your conversations and decides for itself what to keep. The result is a memory system whose contents you can't predict — it forgets your mother's name but remembers a joke you made ironically six months ago.

The alternative is a consent ledger. In teasa's default mode, the companion asks before saving: it proposes a memory ("You mentioned your sister Dana is visiting next month — should I remember that?") and you approve, edit, or decline. The decision itself is recorded as an append-only entry, so there is always an answer to the question "why does it know this?" — namely, because you said yes, on this date, in this conversation.

This has a second-order effect that pure engineering misses: proposing memories out loud teaches users what the system is doing. Memory stops being an eerie inference engine and becomes a visible, negotiated act — closer to a friend saying "I'll remember that" than a platform logging you.

Principle 2: Every memory carries provenance

A memory without metadata is a rumor. To trust — or challenge — what a companion knows, every stored memory needs a visible record of:

• Source — the conversation and moment it came from.
• Date saved — when it entered the ledger.
• Confidence — is this an exact thing you said, or an inference?
• Scope — which companions or stories can access it. Something told to one character in one context should not leak into another by default.
• Last used — when it most recently shaped a response.

Provenance turns "the AI is wrong about me" from a helpless feeling into an actionable one. You can see which memory produced a bad response, trace it to its source, and fix it at the root. It also enables scoped intimacy — a real requirement in a roleplay product, where you may be one persona in a slow-burn romance and another in an adventure story, and bleed-through breaks both.

The person a memory belongs to should always hold the key.

Principle 3: The owner corrects the record — and corrections propagate

Users must be able to edit, merge, delete, and deprioritize memories, and to mark topics as never remember. But the harder requirement is what happens downstream: a correction must actually reach future generations. If you fix "I live in Austin" to "I moved to Denver," and the companion cheerfully references Austin next week, the correction UI was theater.

That implies corrections are first-class, revisioned events — with before/after states — that feed subsequent generation, not cosmetic edits to a display table. It also implies the moment of incorrect recall should offer both actions at once: correct the memory and regenerate this response with the correction applied. The user should never have to choose between fixing the record and fixing the conversation.

Principle 4: Deletion is soft, explicit, and honest

Deletion in an intimate product needs two properties that are in tension, and good design needs both:

Reversibility at the edge. People delete things in emotional moments. Soft delete — where a memory is immediately excluded from all generation but recoverable for a bounded window — respects that, the way an email trash folder does.

Finality at the core. When a user truly deletes — a memory, a thread, an account — it must actually go, including derived data: embeddings, summaries, and downstream state built from the deleted fact, across every branch of every conversation. Deleting the fact but keeping the vector is not deletion. And destructive actions should preview their real scope ("this removes 34 messages across 3 branches") before confirming — informed consent applies to forgetting, too.

What deletion must never be is ambiguous. "We'll try to forget that" is not a data policy.

Principle 5: Threatened memory loss is a dark pattern. Name it.

Now the uncomfortable part. In a companion app, memory is the attachment object — it is the relationship, reified. Which makes "your companion will forget you" the single most coercive sentence the product can utter.

The category is full of soft versions of this: relationships that "decay" if you don't check in; features framed so that unsubscribing means your companion "won't be the same"; upgrade prompts placed at moments of emotional disclosure. These all share a mechanism with the streak and the guilt-trip notification: they convert a user's attachment into leverage against that user. In any other relationship we would recognize "leave and lose everything we had" as a red flag, not a pricing strategy.

Teasa's product principles ban this outright — no threatened memory loss, no relationship decay, no guilt on exit, no streaks, no artificial urgency — and treat a clean goodbye as a success metric. Whatever the business model, memory persistence and the user's continued payment or engagement must be decoupled: your history is yours, exportable, and never a hostage. We'd argue this belongs in every companion app's public policy, and that reviewers and researchers should evaluate apps on it explicitly.

The trust dividend

There is a practical objection: doesn't consent-gating make memory worse? Fewer things saved, more friction?

The evidence of the category's failures suggests the opposite. Users don't leave companion apps because the companion remembered too little; they leave because the memory was untrustworthy — wrong, lost, or weaponized. A smaller ledger of consented, provenance-tracked, correctable memories produces recall the user recognizes as true, and every accurate reference compounds trust. An extractive system produces the uncanny alternative: a companion that knows things about you that you never agreed to share, until an update erases even that.

Memory should be the deepest moat a companion product has. It only works as a moat if it is a promise kept — asked-for, inspectable, correctable, deletable, and never held for ransom. That is how AI companion memory should work. Teasa is our attempt to prove it in production; the principles are free.

FAQ

How does AI companion memory actually work?

Most companion apps extract candidate facts from your conversations with a language model, store them in a database, and retrieve relevant entries into the model's context on later turns. The design choices that matter are whether extraction happens with or without your consent, whether you can inspect and correct what was stored, and whether deletion actually removes the entry and its downstream influence.

Why do AI companions forget things?

Usually one of three reasons: the conversation exceeded the model's context window and older turns were dropped, the memory system never saved the fact in the first place, or a product update changed the memory architecture. Opaque systems make it impossible to tell which happened — which is exactly why a visible, provenance-tracked ledger matters.

Can I delete what an AI companion remembers about me?

On well-designed platforms, yes — look for per-memory deletion, whole-account deletion, and an explanation of whether deleted memories also stop influencing future responses. If an app offers no memory controls at all, treat that as a red flag; our privacy checklist covers what else to check.

Is consent-gated memory worse than automatic memory?

It stores fewer entries, but the entries it stores are ones you recognize as true, which is what makes recall feel trustworthy rather than uncanny. The category's documented failures come from untrustworthy memory — wrong, lost, or weaponized — not from memory that asked first.