Pick the right choice between rolling summary and vector store memory for cross-session continuity

Cross-session continuity means the assistant remembers things from previous conversations when the user comes back later. There are two natural approaches, and the better one depends on understanding how the relevance of stored facts shifts over time. **Rolling summary across sessions.** Keep a single growing summary that gets re-injected at the start of every new session. This sounds reasonable but breaks in two ways. The summary grows monotonically, because every new session adds material. Across dozens of sessions it either becomes very long (and eats budget) or it has to compress harder on every refresh (and loses fidelity). Most of the content is also irrelevant to any single new session: a user who chatted about cooking last month and about coding this month does not want the cooking summary loaded for the coding question. **Vector-store memory keyed on user_id.** Store discrete facts as items in a vector store associated with the user. On each new turn, embed the current user message, retrieve the top-K relevant facts, and inject only those into context. Scaling is graceful: the store grows with the user's lifetime, but only the relevant facts ever reach the prompt. This is the right shape for cross-session continuity. The other two options fail more obviously. Combining both without coordination double-pays and creates conflicting versions of the same fact. Asking the user to re-state context every session puts the burden in the wrong place.

The right choice is a **vector-store memory keyed on user_id**, and the reason is that cross-session continuity has a specific structure: a user accumulates many facts across their lifetime, but only a small relevant subset matters to any one new conversation. The retrieval per turn shape matches that asymmetry; the rolling-summary shape does not. A rolling summary grows monotonically. Every session adds material, and the summary refresh either keeps the material (the summary gets longer and eats budget) or compresses harder (fidelity degrades on each refresh). Across many sessions both failure modes appear: the summary is both bloated and lossy. Worse, the relevance distribution is wrong: a user who discussed cooking three months ago and is now asking about code does not want the cooking summary anywhere near their coding question. The summary cannot selectively include only relevant content because by construction it covers everything. A vector store solves this by storing discrete facts (preferences, identifiers, decisions, constraints) as embedded items associated with the user. On each new turn, the current user message gets embedded and the store returns the top-K most relevant items. Only those items reach the prompt. The store can grow without bound; only the relevant subset is ever paid for. Production implementations of this pattern (Mem0, Zep, Letta) also handle the surrounding plumbing: fact extraction from conversations, contradiction resolution when a new fact conflicts with an older one, decay or invalidation of stale facts, and per-user scoping. ChatGPT memory and Claude projects both expose user-facing surfaces backed by a similar shape. The other options fail in identifiable ways. Combining a rolling summary with a vector store without coordination (option 2) double-pays for the same facts and creates conflicts between the summary's version of a fact and the store's version.