Somewhere on a whiteboard, a well-meaning engineer once wrote memory_enabled: boolean on an agent config schema and called it a day. It felt complete. It was not complete. It was the first domino in a config schema that would, within two quarters, sprout persistent_memory: boolean, memory_scope: enum, and eventually a Slack thread titled "what does it mean if memory_enabled is true but persistent_memory is false - does it remember or not??"
That thread is the tell. When your config combinations start producing states nobody can explain out loud, the problem isn't documentation. The problem is you've modeled a resource as an attribute.
What a Boolean Can't Tell You
"Memory" isn't one thing. At minimum, it's two genuinely different things wearing the same name:
- Session memory - the scratch space an agent uses to track context within a single interaction or task. It should exist for as long as the session does and vanish the instant the session ends. It's the agent's working memory, not its life story.
- Durable memory - context that persists across sessions. The agent remembers that this customer prefers email over chat, or that this recurring task failed the same way last Tuesday too. This is genuinely valuable - and genuinely a different kind of thing, with different retention rules, different access controls, and different reasons it might need to be deleted on request.
A single boolean can't represent two independent axes of variation. Try to force it, and you get exactly the config combinations that make no sense: memory that's "enabled" but not "persistent" (so... session memory? why is that the same flag as durable memory?), or "persistent" but not "enabled" (persistent to whom, if it's not even on?). Every one of those states requires someone to remember, out of band, what it actually means - which is precisely the kind of tribal knowledge a config schema is supposed to eliminate, not create.
Model It as a Resource, With Tiers
The fix is to stop treating memory as a flag on the agent and start treating it as its own resource, attached to the agent but independently addressable, with named tiers instead of booleans:
Session memory lives and dies with the session. No configuration needed - it's just how the agent holds context while it works. Nobody has to opt in or out, because there's nothing to retain past the session boundary.
Durable memory is a resource in its own right: it has an owner, a retention policy, an access-control list separate from the agent's own permissions, and - this is the part that matters most - it is opt-in, not a default.
Why Opt-In Is the Only Defensible Default
Here's the thing nobody wants to say out loud in the excitement of shipping an agent that "remembers you": an agent with durable memory turned on by default is a data retention system that nobody in your privacy or compliance function signed off on. It didn't go through a data classification review. It doesn't have a documented retention period. Nobody can tell you, six months from now, what it actually knows about a given customer, or how to delete it if that customer asks.
Making durable memory opt-in - a deliberate resource someone explicitly provisions, with an explicit owner and an explicit retention policy - turns "what does this agent remember and why" from an unanswerable question into a straightforward lookup. It also means the decision to let an agent remember things across sessions gets made by someone who's thought about the consequences, rather than inherited silently because a boolean defaulted to true in a template someone copy-pasted eight months ago.
A Small, Concrete Example
Consider a customer support agent at a subscription software company. Within a single chat, it absolutely needs session memory - it has to remember what the customer said three messages ago without re-asking. That's not optional and doesn't need a policy decision; it's just how conversation works.
Whether it should remember, next month, that this customer once complained about billing - that's a genuinely different question, with genuinely different stakes. Maybe yes, if the product goal is continuity of service and there's a retention policy and a deletion path. Maybe no, if the customer's plan tier doesn't include that feature, or if legal hasn't cleared cross-session retention of support complaints yet. The point isn't which answer is right - it's that this needs to be an explicit, provisioned decision, not a side effect of a boolean someone set to true because the demo looked cooler that way.
Where We're Genuinely Unsure
The line between session memory and durable memory is cleaner in a blog post than it's been in practice. We've hit cases - a task that spans multiple sessions but arguably shouldn't count as "durable" in the compliance sense - where the two-tier model felt like it was straining. We haven't landed on a third tier yet, and we're not sure we need one versus just being more disciplined about what counts as a session boundary. If you've drawn this line differently, we'd like to know where.
A Few Things We'd Watch For
We'd resist letting "durable memory" become a dumping ground for everything just because it exists as a resource now - it's tempting to route all sorts of context into it for convenience, but the retention policy you write only means something if the data behind it stays deliberately limited to what belongs there.
Giving durable memory the agent's own access controls "for simplicity" is another one we'd think twice about - if memory access is governed by the same permission set as everything else the agent does, it gets harder to answer "who can read what this agent remembers about me" as its own auditable question, which is exactly what a privacy review tends to ask.
And the deletion path is easy to underbuild. Opt-in without a working "forget this" mechanism doesn't fully deliver on the opt-in promise - if a customer asks what an agent remembers about them and there's no clean answer, or no way to remove it, the resource model organized the problem more neatly without actually solving it.
Memory as a resource is one piece of the runtime puzzle. The next post covers a closely related question: what happens when an agent's configuration itself needs to change - does it require a full redeploy, or should some of it just be a runtime knob?
Suggested hashtags: #EnterpriseAI #AIInfrastructure #AIPlatform #AIGovernance #PlatformEngineering #AIAgents #DataPrivacy #AgentArchitecture #DataGovernance