There is a scene I keep watching repeat itself in enterprise AI programs.
The demo was brilliant. The agent answered fluently, reasoned through multi-step tasks, called the right tools in the right order. Budget approved, pilot launched. Then production traffic arrives, and within weeks the same agent is asking users questions they answered two sessions ago, acting on data that was current last quarter, and confidently contradicting the decision it made yesterday. The team’s first reaction is always the same: the model must not be smart enough. So they upgrade to the newest, largest model available.
And the agent fails in exactly the same way, at a higher cost per token.
After thirty years of building data systems, and the last few spent as an architect helping large organizations put agentic AI into production, I have become convinced that this pattern has almost nothing to do with intelligence. The models are, for most enterprise tasks, already capable enough. What fails is everything around the model: what the agent knows, when it knows it, what it is allowed to know, and what it should have forgotten.
In other words: your agents don’t have an intelligence problem. They have a memory problem. And memory is a data engineering discipline, not a prompt engineering trick.
The wrong diagnosis
The instinct to blame the model is understandable. The model is the visible, glamorous part of the system, the one with a version number and a benchmark score. When behavior disappoints, upgrading it feels like action.
But look closely at how agents actually fail in production and a different picture emerges. The agent that re-asks answered questions has no durable record of the conversation. The agent that acts on stale data has no freshness contract with its sources. The agent that leaks information across users has no entitlement model. The agent that behaves inconsistently across sessions has no persistent state at all: every session is an amnesiac reboot wearing the same face.
None of these are reasoning failures. They are the classic failure modes of a data platform that was never designed, showing up in a new costume. We have simply forgotten that we already know this class of problem, because the chat interface makes the system look like a mind instead of what it is: a stateless function that desperately needs state.
Four problems hiding inside the word “memory”
When teams say “the agent needs memory,” they are usually compressing four distinct engineering problems into one word. Untangling them is half the work.
State. What has happened so far, in this task and in this relationship? Working memory for the current session is the easy part. The hard part is durable state: decisions taken, commitments made, preferences expressed, and the ability to reconcile them when they conflict.
Context. Of everything the organization knows, what belongs in front of the model right now? This is a retrieval and ranking problem with a hard budget: context windows are large but attention is not, and in practice every irrelevant document you inject displaces a relevant one. Context assembly is query design, not luck.
Permissions. What is this agent allowed to know, on behalf of this user, in this moment? This is the least discussed and, in regulated environments, the most important. An agent is a confused deputy by construction: it acts with someone’s authority over someone’s data. If entitlements are not enforced at the memory layer itself, they are not enforced. A model cannot be trusted to “remember not to say” what it should never have retrieved.
Forgetting. What must decay, expire, or be provably deleted? Nobody builds this until a regulator, a lawsuit, or an incident forces the issue. I will come back to it, because it is the part of the discipline that I believe will define the next few years.
Read that list again and notice what it is: access patterns, consistency, authorization, lifecycle. It is the same list a good architect would have written on a whiteboard for any data-intensive system in the last two decades. Agent memory is data modeling, resurrected. We spent years learning to design schemas around how applications actually query data. Agents demand exactly that mindset: their memory has to be designed around how they think, act, and resume, not around how it is convenient to store transcripts.
The anatomy that works in practice
In the architectures I see holding up under real workload, agent memory is not one store but a small system of them, each with a different lifecycle.
Working memory holds the live task: the current goal, intermediate results, tool outputs. It is ephemeral by design, and its main quality is disciplined truncation, deciding what graduates into something more durable before the window closes.
Episodic memory records what happened: past interactions, decisions and their outcomes, summarized at the right granularity. Raw transcripts are almost useless here; the engineering is in the distillation, and in being able to answer “have we been here before, and how did it end?”
Semantic memory holds what the agent knows about the domain and the entities in it: customers, cases, systems, policies. This is where retrieval quality lives or dies, and where most “hallucination” complaints in enterprise settings turn out to be retrieval problems wearing a model costume.
And wrapped around all three, an entitlement layer that filters every read and write by who is asking, on whose behalf, under which policy. Not as an afterthought at the application layer, but as a property of the memory system itself.
Forgetting is a feature
Here is the part almost nobody writes about, and the one I find myself discussing most often with organizations in regulated sectors: an agent that never forgets is not an asset. It is a liability with excellent recall.
Every piece of durable memory an agent accumulates is discoverable, breachable, and subject to law. Personal data carries retention limits and erasure rights. Sovereignty rules constrain where memory may physically live. Sector regulations dictate what may be retained about a citizen, a patient, a case, and for how long. The moment your agent remembers users across sessions, you have built a personal data platform, whether you meant to or not, and every obligation that applies to one applies to your agent’s memory.
This means deletion has to be an architectural capability, not a cleanup script. “Provably forget everything about this person, including derived summaries and embeddings” is a genuinely hard requirement, and it is unmeetable if memory is smeared across prompt logs, vector stores, and analytics pipelines that nobody inventoried.
Designed deliberately, forgetting even improves behavior. Memories that decay by relevance and age keep context assembly sharp. Expiring stale facts prevents yesterday’s truth from poisoning today’s decision. The best memory systems I have seen are opinionated about what not to keep.
What this means for how we build
If you accept the thesis, the practical consequences are refreshingly unglamorous.
Treat memory as a first-class component with its own design review, not as whatever the framework’s default “memory” flag happens to persist. Ask the boring questions early: what are this agent’s access patterns? What consistency does resuming a task require? Who can read which memories, and how is that enforced? What is the retention policy, and can we prove deletion?
Measure memory, not just the model. When behavior disappoints, instrument what was actually in context, what was retrieved and what was missed, which stale facts survived. In my experience the majority of “the model was wrong” tickets dissolve into “the context was wrong,” and that is good news, because context is fixable with engineering.
And staff accordingly. The scarce skill in agentic AI right now is not prompt craft. It is the data architect’s instinct for state, lifecycle, and authorization, applied to a new kind of application. If your team built serious transactional or analytical platforms, they already have most of the mental toolkit. Tell them so.
The memory we choose
There is a larger point underneath the engineering, and I will only gesture at it here.
We are, at industrial scale and considerable speed, giving machines memory: of our conversations, our organizations, our citizens. And we are doing it, in most places, without deciding the rules of that memory, what it keeps, what it must lose, who may see it, who answers for it. Those rules will not emerge from the model. They are designed, by people, into the data layer, or they are absent.
The behavior of the agents we deploy over the next few years will be determined less by how intelligent their models become and more by how deliberately we engineer what they remember. That part is not a research frontier. It is our job, and we already know how to do it.
