Almost nobody publishes this, which is odd, because it is where the
confidentiality incidents come from.
Memory is not one thing, and the reason to separate it into layers is that
each layer has a different retention period and a different access-control
boundary.
Most discussion of AI memory treats it as a single capability — the system
"remembers things" — and argues about how much. That framing hides the question
that actually matters in an enterprise, which is not how much is remembered
but for how long and who is allowed to see it.
Business knowledge spans wildly different timescales. What the user said two
turns ago is relevant for minutes. What this project concluded last month is
relevant for the project's life. That Acme Ltd is the parent of Acme Services is
relevant indefinitely. What was retrieved to answer a given question must be
retained for as long as the audit obligation runs, which may be years.
Five different lifetimes. Five different read scopes. Hence five layers.
The layers
1. Working memory — the current turn
Ephemeral by construction. What the model is holding right now to answer this
question: the prompt, the retrieved passages, the intermediate reasoning.
Retention: the request. Read scope: this request.
2. Session memory — the conversation
What was said earlier in this exchange, so that "what about the second one"
resolves to something.
Retention: the session, discarded on a defined schedule. Read scope: the
user.
The discard schedule is a real decision, not a default. A session that never
expires is a durable store that nobody has thought about the retention of.
3. Project memory — durable working knowledge
What this project has established. Conclusions reached, decisions recorded,
context that should survive between conversations.
Retention: the project's life. Read scope: agents and users assigned to
that project.
This is the layer where the most useful accumulation happens, and it is also
where promotion becomes a design problem — something has to decide that a
fact from a session is durable project knowledge. That decision is a source of
both real value and real error, and it should be explicit rather than automatic.
4. The knowledge graph — entities and relationships
Not documents. Things, and how they relate: this company owns that subsidiary,
this contract governs that relationship, this person signs for that entity.
Retention: indefinite, with provenance on every assertion. Read scope:
filtered by entitlement, like everything else.
Why it earns its place: a question about a customer should be able to reach the
customer, not merely the documents that happen to mention them by that exact
name. It is what lets a system answer "what have we agreed with this group"
across subsidiaries that are named differently in every contract.
5. The audit trail — what actually happened
An append-only, hash-chained record of what was retrieved, by whom, under what
scope, and what was returned.
Retention: as long as the obligation runs. Read scope: deliberately
narrow, and never the model's.
It is memory in the strict sense — the system's record of its own past — but it
is the only layer that exists to be read by people rather than used by the
system. That distinction is why it is separated rather than merged into the
layers above.
Why the separation is the point
Systems that conflate these leak.
When conversation context, project knowledge and organisational facts share one
store, the access-control boundary becomes ambiguous — and ambiguity in an
access boundary resolves, under load, in the permissive direction. Not through
malice or a bug. Through a series of individually reasonable decisions about
what should be available to make answers better.
The concrete failure is a user in one project receiving context derived from
another project's material. That is a confidentiality incident, not a quality
bug, and the person it happens to may never realise it happened.
Each layer therefore has its own retention rule and its own read scope, and no
layer inherits another's by default. The default is the safe direction, which
means it is occasionally the annoying direction.
What it costs
Five stores rather than one, each with its own lifecycle. Promotion between
layers as an explicit decision, which is complexity you are choosing to carry.
Graph construction as an ongoing pipeline rather than a one-off build.
We would rather state that than pretend the design is free. It is a considered
trade, and the thing being bought is that the boundary between one project and
another is a property of the architecture instead of a hope.
What it still gets wrong
Entity resolution is the hard part and it is never fully solved.
Whether "Acme Ltd", "Acme Limited" and "ACME (UK)" are one entity or three is a
judgment — sometimes a legal one — and the graph is exactly as good as that
judgment. When it is wrong, it is wrong in the worst available way: not a
missing answer, but a confident one that has quietly aggregated two unrelated
companies.
The mitigation is provenance. Every assertion in the graph carries where it came
from, so a wrong merge can be found and unwound. That is a repair path, not a
prevention, and anyone claiming their knowledge graph has solved entity
resolution is describing a corpus they have not met yet.
The question worth asking
"Which layer is this remembered in, and who else can read it?"
Ask it of any system that offers memory. If the answer is "it remembers
everything" without a boundary, you have not been told about a feature. You have
been told about an unpartitioned store — and somebody in your organisation will
eventually ask it a question they were not entitled to have answered.
