Types of Memory

One table for everything the agent remembers is simple to build, but facts, events and instructions each need their own store, write rule, and way of failing.

"Long-term memory" is not one thing. Sort every remembered item by what it is for, then give each kind its own write rule and store, building on the scopes in Why Agents Need State.

Objectives:

• name four kinds of memory and the write rule, store and failure that go with each;
• explain why enterprise knowledge is retrieval, not memory;
• translate between the vocabularies used by the four source documents.

Three remembered items show the split. "Alice prefers concise answers" is a durable fact about a person. "This task succeeded this way last time" is a record of an event. "Always check the refund window before issuing a refund" is an instruction that changes how the agent behaves.

These need different write rules. The fact should overwrite itself when it changes. The event should append a new record every time. The instruction should change only after someone approves it. A single update rule cannot fit facts that overwrite, events that append, and instructions that need approval. Put them in one table with an extra column and that discipline becomes impossible to hold.

The sources converge on four kinds. The table merges their descriptions.

Working memory is the context window, so it belongs to the turn scope. The other three outlive the turn. Episodic and semantic memory usually live at the user scope. Long-Term Memory: Write, Retrieve, and Forget covers how each is written and read. Advanced Memory Architectures covers richer forms of procedural memory.

Warning: a vector store cannot pick the one correct value. Some facts have exactly one right answer, such as a customer's tier or a contract's renewal date. Similarity search returns several plausible candidates and has no way to choose between them. Store those facts for exact lookup by key, not for nearest-neighbour search. "Why not put everything in a vector store?" is a common follow-up, and this is the answer.

The FDE Handbook's customer-support design names three layers. Two of them are memory. The third is not.

The common mistake is to merge the second and third layers. Both feel like "things the system knows". But they fail in different ways, at different costs, and are refreshed on different schedules. A stale preference makes personalisation mildly wrong; an outdated policy makes an answer wrong in a way that can bind the business. Keep enterprise knowledge in the retrieval layer and customer memory in a per-user store. Merging them makes both harder to fix.

The four sources behind this module use different words for overlapping ideas. Read this table when a term in one source does not match another.

Three differences are worth knowing before an interview.

Where semantic facts live. The agentic design book puts single-valued facts in a relational or graph store and warns against a vector store. Module 9's first topic lists a vector database plus a relational database for long-term memory, and fetches memories by vector similarity. Module 9's fifth topic resolves this itself: vector search for "find memories relevant to this situation", structured queries for exact questions. Use both, each for its own question.

What "semantic" means. The book and the interview tutorial use it for durable facts about an identity. Module 9 uses it for general learned knowledge. Say which you mean.

What gates procedural memory. The interview tutorial gates a procedural change on human approval. The book gates it on an evaluation. Both agree on the principle: nothing becomes behaviour without a gate.

Take the support agent from Why Agents Need State and sort what it encounters.

"Can you refund it?" needs the earlier turn. That is thread history, read straight into working memory. The customer's preferred language is a semantic fact; it goes under a stable key such as preferred_language, so restating it overwrites rather than duplicates. Last week's support interaction is an episode; it is appended as a fresh record and read back by recency and similarity. "Always check the refund window before X" is procedural; it changes only through a gate. "What is your refund policy?" is not memory at all; it is a retrieval question against the policy documents.

Five items, five homes. Each home was chosen by asking what the item is for and how it fails when it goes stale.

• Sort each remembered item by what it is for: a fact, an event, or an instruction.
• Use four kinds of memory, working, episodic, semantic and procedural, each with its own write rule, store and failure.
• Enterprise knowledge is retrieval, not memory, because it fails and refreshes differently from customer memory.
• The four sources name these kinds differently; translate before comparing.
• The sources disagree on where semantic facts live, what "semantic" means, and what gates procedural memory.

1. Why should a customer's renewal date not be stored only in a vector index? It has exactly one correct value. Similarity search returns several plausible values with no way to choose. Store it for exact key lookup.

2. Why should enterprise knowledge never be stored in the same place as customer memory? They fail differently and refresh on different schedules. A stale preference mildly mis-personalises; an outdated policy gives a wrong, possibly contractual answer.

3. Give the write rule for semantic, episodic and procedural memory. Semantic: update in place under a stable key. Episodic: append a fresh record per task. Procedural: versioned, and changed only through an approval or evaluation gate.