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.
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.
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.