The problem with session memory
Most agent frameworks treat memory as an implementation detail of the session: a scratchpad that fills up during a conversation and empties the moment it ends. That works fine for a single-turn assistant. It breaks down the moment an agent is expected to do anything that spans more than one sitting.
What agents actually need
Session memory is ephemeral, siloed, and opaque. It lives inside the model context window and disappears when the session ends. That makes it difficult to build systems that can retain important information across long-running workflows.
A better way to think about memory
Agents need memory that is persistent, structured, and external to the model. Memory should be something the agent can read, write, and reflect on — not just something it dumps tokens into and forgets.
Design implications
Think of memory as an external system of record for the agent's experience. The model becomes a reasoner over that memory, not the container of it. This creates clearer boundaries between reasoning, persistence, retrieval, and execution.
Conclusion
Building agents with the right memory abstraction changes everything — from how you evaluate them, to how you debug them, to how they scale in the real world. Session memory makes sense for short conversations, but long-running agents need memory built for action.