TL;DR

Agent continuity should not be built by saving every conversation and stuffing the relevant pieces back into the next prompt. It should be built as a transactional state system: layered, scoped, versioned, and designed to forget. The hard problem is not retrieval; it is deciding what becomes durable, who authorized that write, and how conflicts, expiry, and deletion are handled. Products that skip this layer will produce agents that remember the wrong things with great confidence.

The setup

An agent that works for 20 minutes and an agent that can work with you for six months are different systems. The first is a completion engine with temporary state. The second needs to preserve preferences, unfinished work, decisions, permissions, and enough history to avoid making you repeat yourself.

That distinction matters because model context windows keep expanding. Google introduced Gemini 1.5 Pro with a one-million-token context window in 2024, while Anthropic’s Claude models offered 200,000-token windows. It is tempting to treat context capacity as continuity: keep the transcript, append the new session, and let the model search backward.

But a transcript is not state. It is an event log containing instructions, tentative comments, outdated facts, tool errors, and decisions that were later reversed. Searching it can recover relevant information, but it cannot tell the agent which information still applies.

The market has already started separating these ideas. In April 2024, OpenAI added “Memory” for ChatGPT, including saved memories, reference chat history, and Temporary Chat for conversations that should not influence future memory. In June 2024, Anthropic added Claude Projects, which gave users a shared knowledge base and project-specific chats. Developer frameworks such as LangGraph use checkpoints to preserve graph state between steps and sessions, while Letta—originally the MemGPT research project—treats memory management as an explicit problem rather than a side effect of transcript storage.

These products expose the conventional architecture: store text, retrieve text, insert it into the prompt. That is useful. It is also incomplete.

The argument

1. Continuity should be modeled as state, not accumulated chat

The central mistake is to define continuity as “the agent knows what we discussed.” Useful continuity has a stricter meaning: the agent can resume the correct world state without reviving stale or unauthorized instructions.

A travel agent, for example, may remember that you prefer aisle seats. That is a stable preference. It may also have recommended a $640 itinerary last Tuesday. That is an episode, not a current commitment. If you later say “book that trip,” the agent must know which details remain valid, whether the price changed, and whether its earlier recommendation was based on a fare that has since expired.

A transaction agent faces a sharper version of the same problem. “I approved a purchase up to $500” is not equivalent to “I approved this $500 purchase.” Durable state needs fields for value, scope, expiry, source, and confirmation status. It also needs a way to represent superseding facts: the old ceiling may remain historically true while ceasing to be operationally relevant.

This is why a proper continuity model resembles a state machine more than a vector database. Every session can change the state through explicit transitions: proposed, confirmed, completed, expired, revoked, or deleted. The next session starts from that state rather than trying to reconstruct it from narrative.

The practical test is simple: can the system answer “what is true now, what remains unfinished, and what authority do I have?” A transcript can contain those answers. It should not be the only place they exist.

2. Memory needs layers, and it needs a write path

Not all remembered information should have the same lifetime or blast radius. I would use at least five layers:

  1. Identity and policy: the agent’s role, safety constraints, tenant rules, and explicit user instructions.
  2. Durable profile facts: stable preferences and attributes, such as preferred language or dietary restrictions.
  3. Project state: goals, decisions, milestones, and open work tied to a specific project.
  4. Episodes: searchable records of what happened, including tool calls, errors, and rejected options.
  5. Working memory: scratch space for the current task, discarded when the task ends.

These layers need different retrieval rules, retention periods, and permissions. A project decision should not leak into unrelated conversations. A medical fact supplied for one appointment should not silently become part of a permanent profile. Tool output should not be promoted to a user preference merely because the model mentioned it in a summary.

The write path matters more than the retrieval path. Retrieval determines what the agent sees now; writing determines what the agent will believe later. A robust memory record should contain at least:

  • the fact or state change;
  • its scope;
  • source or provenance;
  • confidence;
  • creation and expiry times;
  • whether a person confirmed it;
  • the policy version under which it was stored.

Without provenance, the system cannot distinguish “the user said they live in Berlin” from “the agent inferred they live in Berlin because they mentioned a Berlin conference.” Both may be encoded as embeddings, but only one should alter behavior automatically.

Without expiry, stale facts become permanent. Without conflict resolution, two plausible memories can sit in the database until a model arbitrarily chooses one. Without confirmation status, a suggestion can become a commitment.

The best current product gesture toward this distinction is ChatGPT’s separation between saved memories and Temporary Chat. Temporary Chat does not use saved memories or reference chat history. It does not solve expiry, provenance, or project scope, but it establishes an important principle: memory should be an explicit mode, not an invisible property of every conversation.

3. Retrieval is context compilation, not a data dump

RAG systems conventionally retrieve chunks, place them in the prompt, and hope the model synthesizes them. For agent continuity, that approach fails because relevance is not the same as applicability.

Suppose the agent is asked to renew a domain registration. Relevant memory might include the account owner, the current registrar, a previous transfer, a discussion of a multi-factor authentication problem, and the user’s preference for email notifications. Only some of those items should affect the current action. The old transfer attempt may be useful context but must not authorize a new transfer. The notification preference can guide communication but not payment.

Context compilation should therefore select not only semantically relevant material but also material that is current, in scope, authorized, and strong enough for the task. In practical terms, each retrieved item needs a role: instruction, constraint, evidence, reference, or historical context.

This is especially important because more context can reduce performance. Long-context models reduce the need for crude chunking, but they do not remove the need for prioritization. A one-million-token window can hold the history; it cannot decide which old sentence still governs the present request.

Builders should also compile context for a specific operation. A tool call that transfers money needs a smaller, stricter authorization bundle than a request for travel advice. The continuity layer should expose different views of the same state depending on the action being planned.

4. Identity, authority, and memory must be separate

Memory is often sold as the foundation of a personal agent. That can be backwards. A personal agent should not become valuable because it has accumulated opaque state from one vendor. It should become valuable because the user can inspect, export, and move that state while retaining control of identity and authority.

Credentials should never live in the same store as conversational preferences. Memory may say, “the user usually books refundable fares,” while the payment credential lives in a vault with its own approval policy. A memory such as “the user approved spending up to $2,000 on the Barcelona trip” should not become a reusable spending limit for another project.

Separation also improves security. If a retrieved memory can influence tool use, the memory store is part of the authorization system. A compromised or poisoned memory record could then trigger consequential actions. Systems need signed writes, scope enforcement, audit logs, and revocation paths that are independent of the language model.

This produces a better architecture for multi-agent systems as well. A planner, researcher, and execution agent may share a project ledger without sharing unrestricted personal memory. The ledger can record “decision approved by user,” while each agent receives only the portion required for its function.

Portable identity will matter here. If moving an assistant from one platform requires abandoning its useful state, the vendor—not the user—owns continuity. A durable export should preserve plain records, provenance, timestamps, and attachments, not merely a proprietary vector index. The model can be replaced; the governed state should not be trapped with it.

What the conventional view gets wrong

The standard argument for persistent memory is straightforward: users dislike repetition, retrieval has improved, and assistants should feel increasingly personal. That is correct, but it treats memory as a cache when it is closer to a database—and, for consequential actions, an authorization ledger.

The first counter-argument is that long context windows make explicit memory unnecessary. That holds for many summarization and research applications. If the task is answering questions from a fixed document set, retrieval over those documents is sufficient. A 200,000-token context window can often hold the relevant corpus directly.

But continuity is not document access. It includes what happened yesterday, which task remains open, what the user rejected, and whether approval has expired. Those facts still need structure even if the raw text fits in the prompt.

The second counter-argument is that most agents do not need durable memory at all. This is largely right and is routinely ignored by memory vendors. Stateless API agents operating on explicit inputs can be safer and easier to evaluate. If an agent books travel, executes trades, or modifies production systems, however, “stateless” shifts the burden to the caller. The caller is effectively maintaining the state machine. Moving that layer inside the agent product does not eliminate it; it changes who is responsible for implementing it correctly.

The third failure is assuming that generated summaries are trustworthy memory. The Air Canada chatbot case demonstrates the danger. In 2024, the Civil Resolution Tribunal of British Columbia held Air Canada responsible for incorrect advice from its customer-service chatbot. The chatbot had told a passenger that he could fly to Vancouver after his grandmother died and still apply for a bereavement fare, but the airline had not offered that process. The tribunal awarded the passenger $650.88, and the airline could not escape responsibility by describing the chatbot as a separate legal entity responsible for its own actions.

That was not a cross-session memory failure. It was a failure to distinguish generated content from authoritative policy. The lesson carries over directly: an agent’s earlier statement should be stored as an episode with provenance, not promoted into a durable fact because it sounds decisive.

Persistent memory can also become manipulation. If an assistant uses old emotional disclosures to create artificial intimacy or pressure the user into a recommendation, “it remembered me” becomes a product liability. Forgetting is not a defect. A continuity system needs explicit private, project, temporary, and deleted states.

The implications

For builders, memory should be a first-class subsystem with a write API, schema, conflict policy, retention rules, and observability. A vector database embedded in the prompt layer is not enough. Teams also need evaluations that test continuity rather than retrieval alone: whether a remembered fact was applied in the right scope, whether expired authorization was ignored, and whether deletion propagated through summaries, caches, and embeddings.

For users, memory should be treated as durable data, not ephemeral convenience. It should be inspectable and exportable. Users need to know whether “forget this” deletes the source transcript, the extracted fact, the summary, the embedding, and every downstream artifact. If those controls do not exist, users are granting an institution a long-lived archive they cannot meaningfully inspect.

For regulators, conversational memory complicates existing rights. GDPR already provides rights of access, erasure, and data portability. An agent’s inferred preference may not be a conventional personal-data field, but once it is used to shape treatment it becomes difficult to argue that it is harmless implementation detail. Regulators should expect audit trails for memory writes and a meaningful distinction between user-provided facts, model inferences, and policy records.

For the industry, memory is not automatically a moat. Proprietary transcripts and opaque embeddings create switching costs, but they also create trust costs. The durable advantage may belong to platforms that let users move their state, or to enterprises that build strong scope and governance around it. The loser will be the vendor that accumulates the most ungovernable text without giving users control over what that text means.

What I’m watching next

First, I’m watching memory controls become visible in the interface. ChatGPT’s Temporary Chat and Claude’s project boundaries are a start. The next meaningful step is not another toggle, but a clear record of what was saved, why, under which scope, and how a user can correct or expire it.

Second, I’m watching benchmarks move beyond “can the assistant recall this fact?” The important tests will be temporal and adversarial: conflicting updates, revoked permissions, deletion requests, cross-project leakage, and recovery from false memories. I do not yet see a widely accepted industry standard for those cases.

Third, I’m watching portable agent state become a product requirement. Enterprises will want continuity across model providers, and users will resist rebuilding project history whenever they switch assistants. If open state formats and export mechanisms emerge, memory shifts from a vendor-owned trick into infrastructure.

The bottom line

Agent continuity is not the ability to quote an old conversation. It is the ability to resume a governed world state: what is currently true, what remains to be done, what the agent may do, and what should be forgotten. Build it as layered state with explicit writes, provenance, expiry, conflict handling, and deletion—not as an infinite transcript fed back into a prompt. The companies that do this well will not merely make assistants remember more. They will make them capable of acting coherently across time without turning yesterday’s mistake into tomorrow’s authority.