A few months ago, two of us on the same team built two agents to do the same job: classify a requirement as a User Need or a Design Input, based on the same requirements taxonomy.
Same task. Same standard. Same company.
The agents disagreed. Confidently. On requirements that should have had one obvious classification.
Neither agent was technically broken. Both were doing exactly what they’d been built to do: retrieve from whatever knowledge base each of us happened to have pointed them at, and answer with full confidence. The failure wasn’t in the model, the prompt, or the retrieval logic. It was that the two agents were reasoning from two different snapshots of the same organizational knowledge and nothing in the system was designed to notice, let alone prevent, that divergence.
That incident stayed with me longer than it probably should have, because once I started looking for it, I started seeing the same pattern emerge in other agentic systems. The problem doesn’t scale linearly; it changes category
One agent working from a stale knowledge base is a fixable bug — patch the source, move on.
Ten agents, built by different teams, each carrying a slightly different version of organizational truth, is no longer a bug you patch — there’s no longer a single place to fix. Each agent’s context was assembled independently, by a different person, at a different time. Patching one doesn’t touch the other nine.
Fifty agents, spread across multiple business units, each with its own informally assembled knowledge base? That’s no longer solvable with better retrieval. It’s an operating model problem — the question stops being “how do we build this correctly” and becomes “who’s responsible for keeping it correct, across teams that don’t share a reporting line.”
This is the part I think is currently underappreciated: the failure mode doesn’t get proportionally worse as agent count grows. It changes kind. As agents spread across teams and business units, the solution shifts from fixing individual implementations to establishing shared architecture and eventually, explicit organizational ownership.
We spend a lot of collective attention right now on how to build better agents — model selection, orchestration frameworks, tool-calling, MCP, evaluation harnesses, observability, guardrails.
But there’s a layer underneath all of it that I think is being quietly underestimated:
Who owns what our agents actually know and remember?
Not simply where the underlying data physically lives — enterprises already have mature disciplines responsible for that. Not even whether an agent can technically retrieve the right document — that’s largely a retrieval-engineering problem, and it’s improving every quarter.
The harder question is whether what an agent retrieves is current, authoritative, traceable, and permission-aware — and whether anyone is accountable for keeping it that way as the underlying knowledge changes, as agents proliferate, and as the organizations they serve keep moving.
A few questions make the gap concrete:
Most organizations running agents today don’t have a clean answer to any of these. Not because nobody’s smart enough to answer them — because nobody has been explicitly asked the question.
Traditional applications mostly queried systems of record and displayed what they found. Early copilots mostly retrieved information for a human to read and judge. Neither pattern put much pressure on this layer, because a person was still the last checkpoint before a decision got made.
Agents change that. Increasingly, they retrieve, synthesize, decide, act, retain context across sessions, and — as the field matures — write information back for other agents to use. Each of those verbs adds a new way for divergence to creep in silently, with no human in the loop to catch it. Our existing Data Engineering, Knowledge Management, and MLOps practices evolved primarily around those earlier patterns. Agentic systems introduce a different set of pressures not because those disciplines are deficient, but because responsibility for operational agent memory increasingly cuts across all of them.
Before naming a discipline, it’s worth being precise about what it would actually be responsible for — because “memory,” used loosely, becomes a metaphor that explains nothing.
In a real enterprise, an agent’s usable memory can come from requirements documents, source code, support tickets, test cases, telemetry, operational databases, policy documents, past conversations, prior decisions, previous agent executions, user feedback, knowledge graphs, and external systems — often several of these at once, for a single decision.
That’s already broader than what most people mean when they say “RAG.” A vector database over a document set is one implementation detail of agentic memory.
AME isn’t an attempt to define a new memory architecture. It’s an attempt to define the engineering responsibility around whichever memory architectures an enterprise chooses to use.
It is not the whole of it. Agentic memory includes the retrieval mechanism, yes, but it also includes the governance around what gets ingested in the first place, how conflicting sources get resolved, how long something stays valid, who’s allowed to see it, and as agents increasingly write things back, how an agent’s own output eventually becomes something other agents can rely on.
Treated seriously, this is closer to a live, governed knowledge system than a search index.
I’ve been calling this discipline Agentic Memory Engineering (AME).
A working definition, stated at the level it deserves:
Agentic Memory Engineering is the discipline of designing, governing, and operating the persistent knowledge and contextual state that AI agents use, create, and share across interactions.
One distinction matters enough to state plainly, because without it this proposal collides unnecessarily with governance, compliance, and domain expertise:
Domain owners own organizational truth. Agentic Memory Engineering owns how that truth becomes reliable, governed, and usable memory for agents.
AME doesn’t decide whether an engineering requirement, a clinical policy, or a financial rule is correct. That authority stays exactly where it already sits, with the people accountable for it today. AME owns the machinery that ensures the appropriate version reaches the appropriate agent, with its provenance, permissions, and lifecycle intact.
Not a team of agents doing data engineering — that’s a different, already well-covered trend, and a genuinely useful one, just not this one. AME is a human discipline: the deliberate design and operation of the substrate that other agents reason over.
A fair objection, and worth answering directly rather than skating past: isn’t this just Data Engineering? Knowledge Management? The AI Platform team?
Briefly — because this deserves its own article, coming later in this series — here’s the distinction as I currently see it. The stronger version of this argument isn’t that these disciplines can’t cover AME’s responsibilities. It’s that none of them inherently guarantees end-to-end ownership of operational agent memory:
Each is foundational to AME, and in some organizations, fragments of AME’s job already live inside one of them. But none carries operational, end-to-end responsibility for the persistent knowledge and context agents actually use, create, and share to make decisions. That gap is real, and in most organizations, nobody’s primary concern currently covers it.
At a high level — deliberately high level, since the full technical architecture is the subject of the next article in this series — Agentic Memory Engineering would own:
Put together, this is what turns “an agent that retrieves documents” into “an agent that reasons from trusted, current, and governed memory with different agents receiving the context appropriate to their domain, identity, and task.” Not identical memory for every agent a Legal agent, an engineering agent, and an HR agent shouldn’t see the same things, but consistent governance over whatever memory each one is appropriately given.
I’m not arguing every enterprise needs a new department tomorrow. Whether this becomes a dedicated team, a capability embedded inside an existing AI Platform group, or a federated model with central governance and domain-level owners is a genuinely open question — the subject of the third article in this series, not this one.
What I am arguing is narrower, and I think harder to dispute: as agents move from isolated pilots into interconnected enterprise systems, responsibility for what those agents collectively know and remember can’t keep living undefined. At enterprise scale, an agent’s memory stops being an implementation detail buried inside someone’s project — it becomes shared infrastructure, the same category of thing as a database or an identity system: invisible when it works, a systemic problem for everyone when it doesn’t.
If this missing layer genuinely needs to exist, the next honest question is: what would we actually have to engineer to build it? That’s Part 2: a reference architecture for enterprise agent memory: canonical knowledge versus agent memory, shared versus agent-specific context, provenance and temporal validity, and what happens once agents don’t just read from memory, but start writing back to it.
This is Part 1 of a 3-part series on Agentic Memory Engineering. If you’re already running multiple agents in production, I’d genuinely like to hear how or whether your organization currently answers the question this article opened with: who owns what your agents know and remember?
The Missing Layer: Why Enterprise AI Needs Agentic Memory Engineering was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.