An agent that does not remember starts from zero in every conversation: it does not
know what was decided yesterday, what happened with the customer last week, nor how
this type of task is solved in this company. Memory is not an extra:
it is what separates an operating system from an amnesiac oracle.
Introduction
Yesterday we set the distinction that has been with us: the RAG retrieves what
is written, but an agent that decides also needs to know what has
happened. Today we give that capability a name: memory. And we do it with
a precise framework, because “the agent’s memory” is one of the most
used and least defined phrases in enterprise AI.
The problem
An industrial company operates a maintenance agent that advises the
technicians on critical equipment. The agent has a RAG over all the
manuals and answers well to procedural questions. But the technicians
started to stop using it, and the complaints are revealing:
- “Yesterday I asked why pump B-7 was vibrating and it gave me three
possible causes. Today I asked it whether the alignment had already been ruled out and it
told me it did not have that data. It does not remember that I answered it last night that the
alignment was verified.” - “I asked it how a bearing change is solved and it gave me the
generic procedure from the manual. It does not know that in this plant we use a
modified procedure approved by quality, because it only exists in a
2024 email.” - “Every week it repeats the same three causes for every pump. It does not
learn that on this line the vibration almost always comes from the broken
coupling.”
Three complaints, three different failures, and all three have the same name:
the agent has no memory of anything. It does not remember the conversation (what
happened), it does not remember the local knowledge (what is known here that is not in
the manual), and it does not remember how things are done (the real procedure,
not the one on paper).
The concept
The recent literature on agents (in particular the CoALA framework, by
Sumers et al., 2023) distinguishes four types of memory, taken from
cognitive science, which are exactly the ones an enterprise agent
needs. To them we add a fifth, specific to the company.
- Working memory (working / in-context). The information of the
current task: the ongoing conversation, the state of the plan, the data
being manipulated. It is the context window. It is erased when
the task ends. - Episodic memory. What happened, indexed by time:
conversations, decisions, incidents, events. “On March 3 the
alignment of B-7 was ruled out”, “claim S-2026-007 was paid with
depreciation”, “the negotiation with supplier X closed with a
12 % discount”. Episodic memory is the “what has happened”. - Semantic memory. Facts and concepts that are stable and generalized,
derived from the episodes: “in this plant, the vibration of line
3 almost always comes from the coupling”, “customer Y is strategic”,
“the escalation threshold is 50,000 €”. Semantic memory is the “what
we know”. - Procedural memory. How things are done: skills, routines,
playbooks, operational policies. “The bearing change in this plant
is done with modified procedure P-114 (not the manual’s)”, “before
intervening on a turbine the authority is notified according to N-9”. The
procedural memory is the “how we do it”. - Organizational memory. The one that none of the previous ones captures on
its own: the institutional knowledge of the company —historical
decisions, undocumented agreements, incident lessons, the
operational “culture”—. It is the memory of the organization, not of the individual
agent. In practice, it is the one that costs the most to build and the one that is most
valuable, because it is the one that is not in any system.
The difference between episodic and semantic is the one most confused, and the
one that matters most: the episode is the specific fact (“claim X was paid with depreciation,
in 2024”); the semantic knowledge is the generalized
rule extracted from several episodes (“claims of this type
are paid with depreciation according to clause Y”). An agent with only episodic
memory repeats facts; one with semantic memory applies patterns. And an
agent with procedural memory does not start from zero in every task.
Architecture
In the series diagram, memory is one of the two pillars of
retrieval, alongside context:
KNOWLEDGE
↑
┌──────────┴──────────┐
↓ ↓
MEMORY CONTEXT
(working, episodic, (tomorrow: the context
semantic, procedural, brought into each
organizational) decision)
Memory is fed by three sources we have already seen: the stable
knowledge (which comes from the graph and the RAG), the episodes (which are generated
in operation: conversations, decisions, events) and the procedure
(playbooks and policies). And it produces what the agent needs in each task:
not “everything it knows”, but “what serves it now”.
Use case
The industrial company, with its maintenance agent. We break it down:
- Problem. The technicians lose time re-explaining to the agent the
context of each incident, and the agent repeats diagnoses already
ruled out, because it does not remember anything between interventions. - Decision. Recommend the next diagnostic/action step for the
vibration of pump B-7. - Knowledge needed. The real (modified) procedure for
vibration diagnosis; the probable causes on this line; the
state of the diagnosis already done; the safety constraints. - Data. Manuals (PDF), the incident history of B-7, the state
of the checks (alignment, bearings, coupling). - Relationships. Pump B-7 → line 3; line 3 → pattern → broken
coupling; procedure P-114 → applies to → bearing change; B-7 →
previous incidents. - Context. It is night shift; the on-duty technician is not the one
who opened the incident; there is a planned shutdown next week that
changes the urgency. - Memory. Episodic: “last night the alignment was verified (OK)”;
semantic: “on line 3, the vibration is almost always coupling”;
procedural: “the bearing change uses P-114, not the manual”;
organizational: “after the 2023 incident, vibrations over threshold
U are reported to management within 24 h”. - Reasoning. Exclude the alignment (already verified, episodic
memory); prioritize the coupling (line’s pattern, semantic
memory); apply procedure P-114 (procedural memory);
check threshold U (organizational memory) → report to management. - Action. Recommend “check the coupling with P-114; if the vibration
stays over U, report to management within 24 h” and register the decision in
the episodic memory for next time. - Infrastructure. The four memories + the graph of
equipment→line→pattern + the manuals RAG. Memory is what turns
the agent from an oracle that starts from zero into a technician who “knows
the plant”.
Trade-offs
- Cost. Each type of memory is a subsystem: an episode store,
a fact store, a procedure repository. Designing and operating
the four is a project, not a configuration. - Complexity. The episode→semantic transition (extracting patterns from
facts) is not trivial: doing it badly produces “learnings” that are noise or
bias. Curation is part of the work. - Consistency. If the episodic memory and the semantic one contradict each other
(a specific fact vs. a general pattern), you have to decide which one rules and in
what context. Without that rule, the agent gives incoherent answers. - Currency. Memory expires: procedure P-114 is revised, the
line 3 pattern changes, threshold U is modified. A memory that does not
expire or get updated gives confidence in a past that no longer is. - Privacy and security. Episodic memory accumulates
sensitive information (conversations, decisions, customer data). You have to apply
permissions, retention and deletion, not only to the source data but to what
the agent remembers. - Honest limitation: the agent’s memory is a representation of
the company’s memory. It captures what it is told and what it observes in
operation; it does not capture the tacit knowledge of the people that is not
made explicit. It improves the explicit; it does not replace the teams.
Implication for the company
For the CDO, memory is the asset that turns the agent into a
accumulative capability: each intervention makes it better, instead of
repeating the same error. 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 and
how long is a product decision, not an engineering one. And measuring
memory (does the agent repeat what is already ruled out? does it apply the correct
procedure?) is as important as measuring retrieval.
For operations, the implication is the most tangible: the agent stops
needing to have the plant re-explained to it every shift and starts to operate with
the accumulated knowledge of the team. That is what the technicians wanted
when they stopped using it.
Conclusion
The memory of an enterprise agent is not one: it is four (working,
episodic, semantic, procedural) plus the organizational, which is the one that costs
the most and is worth the most. An agent without memory is an amnesiac oracle: brilliant
in every answer, useless over time.
But there is a problem that memory on its own does not solve: remembering everything
is not the same as remembering what matters now. What determines which
information — from which memory, from which source — is brought at each concrete
moment? That is context, and it is tomorrow’s topic.
Next article
Tomorrow: A Huge Context Window Does Not Mean the Agent Understands the Business. We will see the difference between context window (the model’s
capacity) and business context (the situated information the decision
needs), and we will present the concept of context engineering.
Sources
- Sumers, T. R. et al. (2023). “Cognitive Architectures for Language Agents”
(CoALA). arXiv:2309.02427. — Memory typology (working, episodic,
semantic, procedural) formalized for LLM agents. - Working definition of the ICE: see series, Day 1.
