Part 2 of 3 in a series on Agentic Memory Engineering. Part 1: The Missing Layer established that as agents scale past isolated pilots, nobody explicitly owns what they collectively know and remember. This article asks the next question: if that responsibility needs to exist, what does it actually have to engineer?
One naming note before the architecture: Agentic Memory Engineering (AME) is the discipline Part 1’s proposed responsibility. What follows is the platform that discipline designs and operates: call it the Agentic Knowledge & Memory Platform. AME is the who and the why; the platform below is the what.
Ask most teams building enterprise agents today how their agent “remembers” things, and you’ll get roughly the same answer: a vector database sitting on top of a document store. Embed the documents, retrieve the nearest neighbors, stuff them into a prompt.
That’s not wrong; retrieval is a real and necessary part of any memory architecture. It’s incomplete in a specific way that matters.
Retrieval answers a narrower question than memory does. Retrieval answers “what’s semantically similar to this query, right now.” Memory has to additionally answer: is this still true? Who’s allowed to see it? Where did it come from? Has a newer version superseded it? Did an agent, not a human, write this, and if so, has anyone validated it?
None of those are retrieval questions. They’re authority, provenance, and lifecycle questions. Retrieval is a capability that sits inside a larger governed architecture, not a competing approach to it, and not something this platform replaces.
The core architectural idea in this article is a governed layer connecting enterprise knowledge to the agents that consume it, logically centralized in responsibility, contracts, and governance, even though nothing about that requires it to be one physical system.
In practice, this typically means a set of independently deployable services, knowledge admission, catalog and metadata, provenance, identity and access enforcement, semantic retrieval, graph traversal, episodic memory, procedural memory, lifecycle evaluation, and audit/observability, that agents interact with through governed interfaces. What makes this one platform, architecturally, isn’t a shared runtime. It’s a shared set of contracts: every one of those services agrees on how provenance is recorded, how access is enforced, and how lifecycle state is tracked, regardless of which team built which piece.
Its job: turn authoritative enterprise knowledge and agent-generated experience into something an agent can retrieve, trust, and act on with the constraints enforced by the platform, not left to whichever agent happens to be asking.
It’s easy to blur “knowledge” and “memory” into one word and lose something important. Knowledge is what gets published, in a system that remains its owner, a requirement goes final in the requirements system, a policy gets approved in the policy system, a defect gets logged in the tracker. Memory is what an agent draws on to act. Between the two sits what I’d call the Agentic Knowledge Admission Pipeline, and getting it right takes the same category of discipline data engineering already applies to structured data, adapted here for knowledge instead of tables. (Useful to think about in the spirit of medallion-style data architectures, not a document version of Bronze/Silver/Gold, but its own pattern with the same underlying instinct: nothing reaches consumers without passing through graduated levels of trust.)
The governance gate between Landing and Validated is really three separate checks, not one, and conflating them is where this tends to go wrong:
That third check is the one that’s easiest to skip, and it matters the most. A SharePoint export can be perfectly authenticated and perfectly contract-compliant, a well-formed, legitimately sourced, requirement-shaped document, and still not belong in canonical agent knowledge, if the designated authoritative source for requirements is the requirements management system, not SharePoint. Authentication and contract compliance tell you the artifact is trustworthy. Only authority tells you it’s the version that counts.
On timing: not everything needs to move through this pipeline in real time, and “real time” isn’t really the right target. A requirement publication, a policy approval, or a code merge probably justifies event-driven processing; the cost of staleness there is high. An archive of five-year-old defect records doesn’t need the same urgency; batch ingestion is fine. The architectural concept that matters is a defined Knowledge Freshness SLA per source, measurable, source-appropriate latency, not a blanket promise of real-time everything.
Three layers get conflated constantly, and the boundaries matter enough to state precisely:
Authoritative Enterprise Sources are the systems where organizational truth is formally created and remains owned: the requirements system, the code repository, the policy system, the test and defect trackers, approved enterprise databases. These stay the systems of record. The platform described here doesn’t replace them, and it doesn’t get to overrule them.
Canonical Agent Knowledge is not itself “the truth”; it’s the governed, agent-ready representation of knowledge derived from those authoritative sources, produced by the admission pipeline above. It’s largely the same content Data Engineering already serves as reliable data products; the platform’s job is re-shaping that content for agent consumption, not re-deciding what’s true. This is the Part 1 principle again, restated architecturally: domain owners own organizational truth; AME owns how that truth becomes reliable, governed, and usable by agents.
Agent Memory is the working layer built on top of canonical agent knowledge further shaped by an agent’s identity, domain, and task, and progressively enriched by what agents themselves produce: decisions, synthesized answers, learned patterns.
The shared-vs-specific question sits inside agent memory, not between these three layers. Canonical agent knowledge is mostly shared, a policy shouldn’t have five silently diverging copies. But not everything downstream of it should be shared identically. A Legal agent, an engineering agent, and an HR agent drawing from the same canonical policy set should still end up with different agent memory; filtered by relevance, and gated by what each is permitted to see. Consistent governance over appropriate memory, not identical memory for every agent, is the actual target.
Inside agent memory, it’s also useful to split by kind:
Each of these can exist at either scope, shared across an agent population, or held specific to one domain or agent. Kind and scope are independent dimensions, not the same axis.
Four properties turn this platform into something an enterprise can actually rely on. None of them are exotic technology; they’re closer to discipline than invention, but skip any one of them and the whole thing degrades back into “a vector database on a document set,” just with better branding.
Provenance and lineage. Every piece of knowledge or memory needs a traceable answer to “where did this come from, and what happened to it since?” Not for audit theater, because when two agents disagree, provenance is how you find out which one is working from a stale or unauthoritative source.
Temporal validity. Knowledge has a shelf life, and most of it isn’t marked with one. A policy that was true in March and superseded in June needs the platform to know both facts, not just serve whichever version got embedded first.
Identity and access control. The access-control subject here isn’t just the human who ultimately benefits from an answer; it’s the agent itself, as a first-class identity, alongside the human. The effective authorization decision is really a function of several inputs together: user identity × agent identity × purpose or task × resource policy → effective memory access. That framing avoids two default mistakes: assuming an agent should automatically inherit everything the requesting human can access, and assuming a human should automatically see everything an agent or service identity can technically reach. The platform needs to enforce this directly, not rely on a prompt instruction an agent could ignore or a bad actor could override.
Lifecycle. Knowledge and memory that are never revisited rot quietly. Every piece needs a lifecycle state: active, deprecated, expired, disputed, and a defined path between them.
The properties above cover knowledge and memory flowing into agents. The harder, less-discussed half is memory flowing back out: what happens once agents start generating experience worth keeping.
An agent that resolves a tricky edge case, or synthesizes an answer nobody had written down before, has arguably just created something worth remembering. Whether it should become part of governed agent memory available to other agents in that scope is a validation question, not a retrieval question.
The loop has a consistent shape: an experience or decision becomes a candidate memory, gets evaluated against what’s already known, and is then promoted, merged, expired, or rejected back into governed agent memory, available to the agents in scope for it. Merged memory reconciles with an existing entry rather than duplicating it. Expired memory ages out on schedule. Rejected memory, including agent-generated memory that contradicts a higher-confidence source, never enters circulation.
That loop has a hard boundary, worth stating as its own principle: agents can promote memory. They cannot promote organizational truth. Nothing in the loop above writes back into canonical agent knowledge, and canonical agent knowledge is itself only a representation of the authoritative source, not the source. If an agent-generated insight genuinely deserves to become enterprise knowledge not just something worth other agents remembering, but something that should change what the organization considers true that’s a different, slower path: the candidate goes to domain validation, and if approved, gets published into the authoritative source itself, the same way a human would. From there, it re-enters through the normal admission pipeline like any other published artifact. An agent’s inference doesn’t get to become enterprise truth by skipping the people accountable for that truth.
This is also where contradiction resolution lives. Two agents producing different answers to the same question isn’t just a Part-1-style ownership failure once agents can write back it’s an expected event the platform needs a defined process for, not an incident that gets routed to a human every time.
It doesn’t name a vendor, a vector database, or a specific graph technology; the properties above are implementable on more than one stack, and locking this article to a specific one would date it within a year. The same goes for the Landing/Validated/Agent-Ready tiering; it’s a pattern to adapt, not a specific product or medallion implementation to copy exactly.
It doesn’t claim one architecture fits every organization. A ten-agent internal tools team and a five-hundred-agent regulated enterprise will reasonably land on different implementations of the same underlying properties and reasonably land on different physical topologies for the same logically centralized set of contracts.
And it doesn’t answer who runs this day to day: which team owns which service, whether AME ends up centralized or federated, which existing departments absorb which piece of it. The platform is logically governed as one capability; how that capability is organizationally owned is a separate question, and it’s exactly the one the next article takes on.
Enterprise agent memory isn’t a bigger vector database. It’s two connected governed layers sitting on top of the systems that already hold organizational truth: a knowledge layer that continuously admits published enterprise knowledge from authoritative sources, validates it through authentication, contract, and authority checks, and prepares it for agent consumption and a memory layer that gives agents governed, identity-aware access to that knowledge plus their own accumulating experience, with a defined lifecycle and a hard boundary around what agents are and aren’t allowed to promote.
Together, these form the technical platform boundary that Agentic Memory Engineering designs and governs.
Once that platform exists as shared infrastructure used by many agents, a question Part 1 only gestured at becomes unavoidable: who owns and operates it?
That’s Part 3.
This is the second article in a three-part series on Agentic Memory Engineering. Missed Part 1? Read “The Missing Layer” here. Part 3 on ownership, operating models, and where this responsibility should live inside an organization is coming next.
Engineering the Enterprise Knowledge & Memory Layer: A Reference Architecture for Agentic AI was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.