Session state and long-term memory are different schemas
Session state and long-term memory look similar enough — both are "what the agent remembers" — that most frameworks shove them into one store. They are different schemas, and conflating them produces systems that do both badly. I learned this the slow way in my own knowledge base: an "agent state management" cluster grew to 220 concepts before I admitted it was six distinct layers wearing one name, session lifecycle and durable execution and memory among them, and split it. The taxonomy was telling me what the architecture should have said from the start.
Session state is a checkpoint. Its native forms are the append-only transcript, auto-save, a session_id with a resume parameter, forkSession for branching, checkpoint-and-rollback. Its job is crash recovery and exact continuation: kill the process mid-task, restore, and the agent proceeds as if nothing happened. Correctness here means fidelity — replay must reconstruct the run precisely, which is why serious harnesses persist transcripts append-only rather than in-place. Any lossiness is a defect. And its lifecycle is deliberately bounded; production harnesses put hard lifetimes on resumable sessions (five hours, in one I've studied) precisely because this state is scaffolding for a task, not knowledge. The clearest tell is that checkpoints branch: fork a session and run three continuations off the same saved state, and the operation is perfectly coherent. Try to fork a memory and the concept dissolves — knowledge doesn't branch, it revises. Any operation that's natural on one side and incoherent on the other is telling you these are different types.
Long-term memory is a curated database. The CoALA framing gives it typed stores — episodic, semantic, procedural, plus a preference store in practice — populated by extraction, not by recording. It is lossy on purpose: consolidation, conflict resolution, and decay are features, because the goal is not replaying the past but retrieving what's still useful. Correctness here means usefulness under a future query from a different session, possibly months later, about a task that no longer exists.
Three axes, three different answers
Lifecycle: session state should die with the task; memory must outlive every session. Consistency: session state has to be exact and fresh — this is the layer where you tag tool results with freshness timestamps and raise a StaleContextError before acting on a stale read — while memory tolerates eventual, curated consistency and actively benefits from forgetting. Storage: a sequential transcript log with checkpoints on one side; indexed vector, graph, and key-value stores on the other. Any one of these differences would justify separate schemas. All three together make the shared-store design indefensible.
The conflation fails in both directions. Transcript-as-memory — running retrieval over raw session logs — gives you an unbounded, uncurated corpus where contradictory facts sit side by side and get retrieved together; that's memory pollution built into the schema. Memory-as-checkpoint fails worse: resume a crashed task from a summary and you discover that non-lossless compaction permanently discarded the exact tool state, file handles, and step ordering that replay needed — the agent resumes confidently into a world that no longer matches its notes. Even MemGPT, the most influential architecture here, invites the confusion by presenting its FIFO main context and external archive as one paging hierarchy, when the eviction rules each side needs are entirely different. Checkpointing belongs with durable execution, not with recall.
This year's privacy research added a third failure I hadn't weighted properly: conflation is also a privacy defect. Cross-session context bleeding — episodic memory that isn't scoped per session contaminating later ones — is precisely what the shared store produces, and it now appears in agent threat models as a named vulnerability, not a design smell. The deeper reason is that the two schemas want opposite retention policies. Session state should expire by default — working memory purged when the task completes — while long-term memory needs per-category TTLs enforced by infrastructure: hours for raw PII, weeks for preferences. One store means one retention policy, which means the wrong policy for half the data. The schema split I argued on lifecycle and consistency grounds turns out to be a data-flow privacy control as well.
The honest concession: the boundary is a pipeline, not a wall. Long-term memory is largely extracted from session transcripts; compaction sits exactly at the hand-off, deciding what graduates from state to knowledge; and a mid-task scratch pad is deliberately ambiguous between the two. A small single-user assistant can genuinely start with one SQLite file. But even then, name the two schemas separately — separate tables, separate retention rules, separate write paths. The systems that do both well aren't the ones with the cleverest unified store. They're the ones that never pretended checkpoint and knowledge were the same thing.