Conversation History Is Not the Same as AI Memory

Working context versus stored history

"Your conversations are saved" and "the AI remembers your conversations" sound like the same promise. They aren't, and conflating them is one of the more common ways AI products quietly overpromise.

Saved history is a record: a transcript sitting in a database, retrievable on request, exactly as it was written. Working context is something narrower and much more temporary: whatever slice of that history actually gets sent to the model on a given turn. A long conversation cannot simply be replayed in full every time -- models have finite context windows, and even where the words would fit, spending most of a request's budget re-reading old messages is not a good use of it. So a real system has to choose what a model sees on any given turn, and that choice is a design decision, not an implementation detail to wave away.

The honest version of "we save your history" is: everything you wrote is retrievable by you, and a bounded, relevant slice of it -- plus a compact summary of what came before -- is what the model actually reads on each turn. That's a more modest claim than "the AI remembers everything," but it's the one that's actually true, and it's the one worth making.

Summarised conversation memory

Between "the last few messages" and "the entire transcript" sits a useful middle layer: a rolling summary of the conversation so far. Instead of re-reading pages of back-and-forth, a good system periodically compresses what's been established -- the user's actual goal, decisions made and why, open questions, what's been produced -- into something compact enough to carry forward cheaply.

This is memory in a narrow, useful sense: memory of this conversation, refreshed as it grows, never substituting for the real transcript underneath it. If summarisation ever fails or falls behind, the conversation should degrade gracefully to recent-message context rather than break -- a compression layer is allowed to be imperfect; it is not allowed to be a single point of failure.

Long-term retrievable knowledge

The much bigger promise -- and the one products reach for too casually -- is memory that spans conversations: the assistant recalling something from three weeks ago without being told. That's a genuinely different capability from saving a transcript, and it deserves to be treated as a separate, deliberately built feature rather than an implied side effect of "we keep your history."

Done well, cross-conversation memory should behave like evidence, not folklore: retrieved sparingly, within its own bounded budget, always traceable back to where it came from, and never presented with more confidence than it deserves. Not every past statement earns equal trust, either -- something a user explicitly confirmed should outrank something the assistant merely inferred, and newer confirmed information should be able to supersede older information without silently deleting the record underneath it.

Corrections and deletion

Memory that can't be corrected is a liability, not a feature. If an assistant forms an impression that turns out to be wrong -- or right at the time but later superseded -- there has to be a real path to fixing it, one that a user doesn't need to reverse-engineer. And if a user deletes a conversation, that deletion should actually mean something: whatever was derived from it -- summaries, retrievable memory, anything downstream -- should stop influencing future answers too. A memory system where deleting the source doesn't delete its fingerprints isn't really honoring the delete.

User disclosure and consent

None of this needs to be a secret, but it does need to be described accurately, in the product, in plain language -- not buried in a settings page or a terms document nobody reads. A user should be able to tell, from the interface itself, what's actually true: that their conversations are saved and can be revisited, whether the assistant is drawing on anything beyond the current conversation, and roughly what that means for how their words might resurface later.

The failure mode worth naming directly: telling a user "this will help future conversations" when the product doesn't yet do anything of the kind. Saved history, conversation continuity, and cross-conversation memory are three different claims. Make only the ones that are actually true, and update the wording the moment the underlying behavior changes -- not before.

Preventing one user's history from leaking to another

Last, and non-negotiable: whatever gets remembered, summarised, or retrieved has to stay strictly within the boundary of the person who created it. In a shared, multi-user product this isn't a nuance -- it's the whole game. Every layer of memory, from the raw transcript to a compressed summary to a retrievable long-term fact, needs to carry its ownership with it, enforced the same way the underlying data is protected, not assumed because "it's probably fine."

Get that boundary right, and everything above it -- summaries, retrieval, corrections -- is just refinement. Get it wrong, and none of the rest matters.