Yesterday we built the stable knowledge. Today we build what the agent
uses day to day: its memory. And “designing memory” is not “choosing a database”.
It is deciding what is retained, what is consolidated, what expires and what is
deleted — because a memory that is not managed becomes a
dumpster the agent consults with confidence.
Introduction
Yesterday we set down the knowledge layer: the data, the semantics, the
ontology, the entities, the graph and the RAG, integrated. That is the
stable memory of the organization.
But an agent does not only consult stable knowledge. Day to day
things happen: conversations, decisions, events, incidents, corrections. And the
agent has to remember them, selectively, for the time that
they matter. That is the memory architecture, and it is today’s topic.
The problem
An insurance company has deployed a claims (loss management)
agent on top of its knowledge layer. The agent consults the policies well,
the endorsements and the rules. But the claims team starts to complain:
- “The agent does not remember that this claim has already been visited twice.
Every time I ask it, it proposes a visit again, as if
it were the first.” - “It proposed an advance payment that was already made last month. It had to be
stopped by a human.” - “When a claim has been going on for months, the agent treats every query as if
it were new: it does not know what has been done, what has been promised to the insured nor
what is missing.”
The pattern: the agent has knowledge, but not operational memory.
It knows what a claim is (stable knowledge), but it does not remember what has
happened with this specific claim (episodic memory), nor what has
been decided (decision memory), nor what has been committed to the
insured.
The result is an agent that repeats actions, forgets promises and starts
each case from zero. And in a domain like claims, where the customer’s trust
is played out in coherence over months, that is unacceptable.
The concept
The memory architecture is the design of how the different
memory stores the agent needs are combined, and the rules that govern what
comes in, what is kept, for how long, and how it is consolidated or expires.
It builds on the typologies of day 9, but it lands them as an
architecture, with four design decisions:
-
Which stores exist and for what.
– Working memory: the state of the current task (erased when
it ends).
– Episodic memory: the events and conversations, indexed by
time and by entity (“what happened with claim S-2026-007”).
– Semantic memory: the generalized, stable facts (“the
claims of this type are paid with depreciation”).
– Procedural memory: the procedures and operational policies.
– Organizational memory: the institutional decisions and lessons.
– Knowledge base / RAG: the stable knowledge in prose (day 8, 11).
– Knowledge graph: the structured relationships (day 7, 11).
– Events: the stream of what happens in operation (new
claims, payments, visits, notes). -
What is retained (ingest). Not everything that happens deserves memory. It is
decided which types of event are recorded (decisions, commitments,
executed actions, corrections) and with what detail. -
How it is consolidated (episode → semantic). Specific episodes are
distilled into general facts when the pattern repeats. “Claim
X was paid with depreciation” (episode) → “claims of this type
are paid with depreciation” (semantic). This transition is the one that turns
memory into knowledge, and it has to be done with curation, not at random. -
How long it lasts (retention and expiration). Each type of memory has a
useful life: working memory lasts the task; the episodic memory of a
claim lasts until it is closed (and then it goes to archive); the
semantic lasts until it is corrected; the procedural lasts until it is
revised. A memory without expiration is a dumpster, and an agent that
consults a dumpster gives answers from the past with the confidence of
the present.
The most important decision, and the one that separates a useful memory from a
dumpster, is consolidation with curation: deciding which episode becomes
knowledge, and who approves it. Without it, the
semantic memory fills up with “learnings” that are noise.
Architecture
In the series diagram, the memory architecture is the pillar of
retrieval, alongside context:
AGENTS
↓
REASONING
↓
┌───────────┴───────────┐
↓ ↓
MEMORY CONTEXT
(TODAY: memory architecture) (tomorrow)
working + episodic +
semantic + procedural +
organizational + KB +
graph + events
↓
KNOWLEDGE (day 11)
Memory and context are two sides of the same coin: memory is what
is kept; context is what is brought now. The memory
architecture produces the store; the context engineering (tomorrow) decides what
is brought from that store for each decision.
Use case
The insurance company, with its claims agent. We break it down:
- Problem. The agent repeats actions already done, forgets promises to
the insured, and treats each case as new, because it does not have
operational memory of each claim. - Decision. Define the next step of an ongoing claim and
guarantee that nothing is repeated and no commitment is forgotten. - Knowledge needed. The current state of the claim (what has
been done, what has been paid, what has been promised); the management rules;
the procedure for this type of claim. - Data. Policy, endorsements, the claim file, the stream
of events (visits, payments, adjuster notes). - Relationships. Claim → policy; claim → insured; claim →
events; claim → actions taken; claim → commitments. - Context. The claim has been going on for 4 months; there is a paid advance;
a loss-adjustment visit was promised to the insured within 10 days; there is a
fraud investigation open. - Memory. Episodic: “visited on 2/03 and 20/03”, “an 8,000 € advance was paid
on 25/03”, “a loss-adjustment visit before 10/04 was promised”;
semantic: “claims of this type with open fraud do not admit
additional advances”; procedural: “the closure of a claim requires a
signed loss-adjustment report”. - Reasoning. State: advance already paid → do not propose another; the
promised loss-adjustment visit is overdue → that is the next step; open fraud →
apply the no-more-advances constraint; the signed report is missing → the
claim cannot be closed. - Action. Recommend “schedule the pending loss-adjustment visit (overdue
since 10/04); do not pay any more advances (open fraud); the closure is
blocked until the signed report” and register the commitment. - Infrastructure. The memory architecture: the claim’s
events (episodic) + management rules (semantic) + procedure (procedural)- policies knowledge base (RAG) + relationship graph claim→
policy→insured. The operational memory is what prevents repeating the
advance and forgetting the promise.
- policies knowledge base (RAG) + relationship graph claim→
Trade-offs
- Cost. Each memory store is a system with its own operation.
Designing and operating the complete memory architecture is a project, not a
configuration. - Complexity. The episode→semantic consolidation is the most
delicate point: doing it badly produces “knowledge” that is noise or bias. The
curation (who approves which episode becomes knowledge) is
business work, not engineering. - Consistency. If the episodic memory and the semantic one contradict each other,
you have to decide which one rules and in what context. Without that rule, the agent gives
incoherent answers within the same case. - Currency and expiration. Memory expires. If the
expiration is not managed, the agent consults a dumpster and acts on a past that
no longer is. Retention by memory type is part of the design. - Privacy and security. Episodic memory accumulates
sensitive information (conversations, customer data, decisions). You have to apply
permissions, limited retention and deletion, not only to the source data but
to what the agent remembers. - Honest limitation: the memory architecture manages the memory the
system receives. It does not capture the tacit knowledge of the people that is not
made explicit (the veteran adjuster’s judgment). It improves the explicit; it does not
replace it.
Implication for the company
For the CDO, the memory architecture is what turns the agent into a
accumulative and coherent capability over time: each case makes it
better and, above all, does not make it repeat errors. And it is an asset with an
operational cost: it has to be curated, updated and monitored.
For the AI team, the lesson is one of design: deciding what is remembered,
how long it lasts and what is consolidated is a product decision with
compliance implications (data retention), not an engineering one. And measuring the memory
(does the agent repeat what is already done? does it forget commitments?) is as important as
measuring retrieval.
For top management, the message is one of trust: in domains where
the relationship with the customer lasts months (claims, projects, negotiations),
the coherence of the agent over time is what separates a
usable system from one that generates friction.
Conclusion
The memory architecture is the design of how the
memory stores (working, episodic, semantic, procedural, organizational,
knowledge base, graph, events) are combined and the rules of ingest, consolidation,
retention and expiration. Its central decision is the consolidation
with curation: which episode becomes knowledge, and who approves it.
Without it, memory is a dumpster the agent consults with confidence.
Today the agent remembers. But remembering everything is not the same as bringing what
matters now. What, in each concrete decision, determines what information
— from which memory, from which source — is brought and in what order? That is context,
and tomorrow we build it as a mechanism, not as a concept.
Next article
Tomorrow: Context Engineering: Giving an Agent the Context It Actually Needs. We will see how context is built dynamically from
user, task, knowledge, memory, relationships, policies, process
state and time.
Sources
- Sumers, T. R. et al. (2023). “Cognitive Architectures for Language Agents”
(CoALA). arXiv:2309.02427. — Memory typology formalized for
LLM agents. - Working definition of the ICE: see series, Day 1.
