Session state is not memory

The state stack, by lifetime

1. Long-term memory — lives across every session — curated

   Facts, preferences, and distilled conclusions written out of sessions and retrieved into them. Not automatic: something must decide what is worth extracting, how to index it, when it goes stale, and how to correct it. Deleting a session does not delete what was copied here — which is a privacy question with teeth. See context engineering and the retrieval machinery that usually implements it.

2. Session / conversation state — lives as long as the interaction — durable, ordered, append-only

   The transcript: messages, tool calls, tool outputs, in order. Survives process restarts and reconnects because it lives in a database — yours or the platform’s. This is the layer subject to retention policies, deletion requests, and residency rules, because it is where the raw conversation actually sits.

3. Run state — lives for one execution — transient, addressable

   Status, steps, pending tool calls, usage totals for a single execution of the loop. Addressable by run id, which is what makes cancellation, approval, and reconnection possible. When the run reaches a terminal status this layer is finished; only its outputs graduate into the transcript.

4. Connection state — lives for one socket — disposable by design

   The SSE stream or WebSocket, its buffers, and your last-seen cursor. Assume it dies constantly: mobile networks, proxy timeouts, deploys, closed laptops. Nothing that matters may live only here — the moment it does, a dropped socket becomes data loss.

Myth: “The platform stores my thread, so my agent has memory”

Thread storage gives you durability and reconnection, not recall. It replays everything, in order, forever — the opposite of what memory does. Recall requires extraction, indexing, retrieval by relevance, and staleness handling. Notice that platforms tend to ship both and keep them separate: a durable conversation history is one product surface, a memory or state store is another.

Myth: “Bigger context windows make this a non-problem”

Bigger windows change the failure mode from an error to a bill plus a quality regression. You still pay per token on every call, latency still grows with input size, and relevant facts still get diluted by irrelevant ones. A million-token window is a reason to be thoughtful about what you put in it, not permission to stop thinking.

Myth: “Deleting the session deletes the data”

Only for that layer. Facts extracted into long-term memory, embeddings written to a vector index, events in your durable log, spans in your observability backend, and platform-side copies all persist independently. If you promise a user erasure, you owe them a deletion path through every layer of this pyramid — and you cannot write that path if you do not know which copies exist.

Myth: “Session state and memory can share one store, it is all just history”

They have opposite access patterns. Session state is read whole, in order, by one session id — an append-only log. Memory is read by similarity or key, across sessions, with updates and corrections. Merging them produces a store that is slow for one job and wrong for the other, and it makes per-user deletion far harder than it needed to be.