The Memory Taxonomy: Short-Term, Long-Term, Episodic, Semantic, and Procedural

Here is the complete picture up front, because every section after this one is an expansion of one row in this table rather than a build-up toward it.

[GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md): the domain's own framing states the core distinction is "short-term vs long-term, with three finer functional categories drawn from the CoALA (Cognitive Architectures for Language Agents) framing" — which is the structural fact this whole lesson is built to make unmissable: episodic, semantic, and procedural are not a third and fourth and fifth sibling of short-term and long-term. They are subdivisions inside long-term. Short-term stands alone as its own category; long-term is the umbrella that episodic, semantic, and procedural each sit underneath, each doing a different job.

Short-term memory is the recent-inputs buffer that feeds the immediate decision an agent is making right now. It is the mechanism M5-01's worked example already showed in miniature: a rolling record of the current session's turns, resupplied into each new call so the agent's responses stay coherent with what has already happened in this conversation. The defining property, worth stating precisely because it is the property the exam's distractors most often attack, is that short-term memory does not persist beyond the session it belongs to. Close the session, start a new one, and the buffer is gone — whatever the agent needs to carry forward past that boundary has to live in one of the long-term categories instead.

Why short-term memory alone cannot do everything

Short-term memory is fast and cheap precisely because it is small and disposable: there is nothing to write to durable storage, nothing to index, nothing to retrieve from across a large corpus — it is just the current context, held for as long as the current session lasts. That is also exactly its limit. An agent that only has short-term memory has learned nothing from any interaction that happened before the current session started, has no record of any specific past event beyond what is still sitting in the current buffer, and has no accumulated general knowledge beyond what its underlying model already had baked into its weights before this conversation began. Every one of those gaps is what the three long-term categories exist to close, each in a different way.

Long-term memory is knowledge that survives past the session boundary short-term memory cannot cross. [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md): the source material's typical-implementation list for long-term memory names "databases, knowledge graphs, or vector embeddings," with retrieval-augmented generation named as "a common technique" for reading relevant pieces of that stored knowledge back into a call. The mechanical difference from short-term memory is durability plus retrieval: instead of a buffer that is simply resupplied wholesale on every call within one session, long-term memory is a store that an agent queries — typically for the small subset of stored content relevant to the current task — and the retrieved subset is what actually gets injected into the model's input for that call.

That query step is worth dwelling on because it is the source of the storage-vs-retrieval-efficiency trade-off M5-01 introduced: a long-term store can grow arbitrarily large without directly slowing down any individual call, but every call that needs to consult it now pays a retrieval cost — a database lookup, a graph traversal, a vector similarity search — that a short-term buffer never has to pay, because the short-term buffer is simply handed over in full every time.

Why "long-term" alone still under-specifies the design

Saying an agent "has long-term memory" answers one question — does it, or does it not, retain something past the session boundary — and leaves the more consequential design question completely open: what kind of thing is being retained, and for what purpose? A system that stores raw transcripts of every past support ticket and a system that stores the general policy rules an agent has inferred from those tickets are both long-term memory systems, backed by entirely plausible implementations (a document store in the first case, a compact rule table in the second), and they answer completely different questions when queried. This is exactly the gap the three finer categories exist to close, and it is where this lesson's real depth — and the domain's most commonly missed distinction — lives.

Episodic memory stores specific past events — a record of what happened, when, involving whom, and with what outcome — for the purpose of case-based reasoning: given a new situation, look up a specific, similar past situation and reason from what happened then. [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) names the typical implementation as "logs of events/actions/outcomes," which is the clue worth internalizing for telling episodic apart from the other two: an episodic memory entry is inherently particular. It names a specific instance — "on this date, this customer's return request for this item was denied for this reason" — not a general rule extracted from many such instances.

L1 — Intuition

Episodic memory is a diary. Each entry is one dated, specific thing that happened: what the situation was, what was tried, and how it turned out. You do not consult a diary to learn a general life lesson directly — you consult it to find the entry that most resembles your current situation, and you reason from that one specific precedent forward.

L2 — Mechanism

An agent implementing episodic memory logs, for each meaningful interaction, a structured record: the context at the time, the action taken (by the agent or the user), and the observed outcome. When a new situation arises, the agent (or a retrieval component acting on its behalf) searches this log for entries similar to the current context — often via embedding similarity over a description of the situation — and surfaces the most relevant past episode or episodes into the current call's input. The model then reasons over the current situation with that specific precedent visible, rather than reasoning in a vacuum or reasoning from a pre-digested general rule. This is why episodic retrieval is closely associated with case-based reasoning as a technique: the value of the memory is precisely that it is a specific case, retrievable and inspectable, not a compressed abstraction.

L3 — The exam-relevant edge case: episodic memory is not just "any log"

Not every log an agent keeps is functioning as episodic memory in the taxonomy's sense. A log kept purely for observability — timestamps, error codes, latency figures, kept so an engineer can debug the system later — is operational telemetry, not episodic memory, unless the agent itself is actually retrieving and reasoning over past entries from that log as part of making a current decision. The distinguishing test is functional, not structural: does a past, specific event get retrieved back into the agent's reasoning process to inform a present decision? If yes, it is doing episodic-memory work, whatever storage format it happens to use. If a log exists only for a human to read later and never round-trips back into the agent's own decision-making, it is not, in the taxonomy's functional sense, the agent's episodic memory — it is just a log.

Semantic memory stores generalized factual knowledge — facts, definitions, and rules that hold generally, independent of any one specific past instance. [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) lists the typical implementation as "knowledge bases, symbolic AI, or vector embeddings" — notice this overlaps in implementation technology with long-term memory's general description and even with episodic memory's possible backing store (vector embeddings show up in both), which is exactly why implementation technology is the wrong axis to sort these categories on. The axis that actually distinguishes semantic from episodic is not "what database or index backs it" — it is what the content is: a general fact that holds across many situations, versus a specific record of one situation.

The clean test: could this be true even if this specific event never happened?

A reliable way to tell a semantic-memory candidate from an episodic-memory candidate is to ask whether the content would still be a valid, useful fact even with the specific instance that first surfaced it removed. "Refund requests over 500 typically require manager approval" is semantic: it is a general rule, and it remains true and useful even if you strip away the memory of any one particular refund request that led to its being learned. "On March 3rd, customer 4471's 650 refund request was escalated to a manager and approved" is episodic: strip away the specificity — the date, the customer, the exact amount — and there is nothing left, because the value of the entry was always in its being that one particular case. Semantic memory is what is left once specific instances have been generalized into a rule; episodic memory is the specific instances themselves, kept intact and un-generalized.

Where semantic memory sits relative to model weights

It is worth being precise about one more distinction here, since it is a natural place for confusion: semantic memory, in this taxonomy, is not the same thing as "facts the underlying model already knew from training." A model's pretrained knowledge is baked into its weights and is not what this lesson's semantic-memory category refers to — this category is about an added, explicit store of general facts an agent accumulates or is given, on top of whatever the base model already knows, retrievable and updatable independently of retraining the model itself. That is consistent with M5-01's framing: agent memory, semantic included, is an added component, never a property the model already has.

Procedural memory stores learned skills and behaviors — the "how," not the "what happened" or "what is true." [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) states this memory is stored so that "tasks run automatically," and names its typical implementation as being "often refined via reinforcement learning" — which is the single most distinguishing clue for telling procedural apart from the other two categories: procedural memory is about execution getting better with practice, not about recall of a fact or a specific past instance.

L1 — Intuition

Procedural memory is muscle memory. A skilled driver does not consciously retrieve a rule ("when approaching a red light, decelerate") or a memory of one specific past drive — the skill has been compiled into something that executes automatically, faster and with less deliberate reasoning than it took the first time. The knowledge is real, but it no longer looks like a retrievable fact or a retrievable event; it looks like fluency.

L2 — Mechanism

For an agent, procedural memory shows up as a policy or a set of learned behaviors that improve at executing a specific kind of task through repeated practice and feedback, typically via reinforcement learning: the agent tries an approach, receives a reward signal reflecting how well it worked, and the underlying policy is updated to make similar future attempts more likely to succeed, without the agent needing to explicitly retrieve a fact or a past case each time it performs the task. Over enough repetitions, what started as an effortful, multi-step reasoning process for a task can become something closer to a compiled skill — faster, more reliable, and less dependent on explicit retrieval at execution time.

L3 — The exam-relevant edge case: procedural is the one most often confused with "just doing it well by design"

The trap with procedural memory is mistaking a well-engineered fixed behavior for a learned one. An agent that reliably executes a five-step checkout process because an engineer hard-coded those five steps is not exhibiting procedural memory — there was no learning, no improvement through practice, no reward signal that shaped the behavior over time; it is simply a fixed procedure someone wrote once. Procedural memory specifically names the case where the skill itself was acquired or refined through experience, most commonly reinforcement learning, rather than authored directly. A scenario describing a hard-coded workflow that "just works well" is testing whether you will mistakenly label good fixed engineering as procedural memory — the correct answer in that case is that no memory mechanism is being exercised at all, because nothing was learned.

The row worth internalizing above the others is the "could this survive losing the specific instance" test — it is the fastest way to separate episodic from semantic under exam time pressure, and it does not require guessing at implementation details the scenario may not even mention.

Consider a customer-support agent handling returns, built with a full memory stack rather than any single memory type in isolation.

Session buffer (short-term):
  "User: I want to return the jacket I bought last week.
   Agent: Sure, can you give me the order number and reason?"
  -- discarded when this session ends; never written to durable storage.

Episodic entry (long-term, written after this session):
  {date: "2026-06-14", customer: "4471", item: "jacket", reason: "wrong size",
   action: "issued return label", outcome: "customer confirmed receipt of label"}
  -- a specific, dated record of one particular return.

Semantic entry (long-term, generalized from many episodic entries like the one above):
  {rule: "Wrong-size returns on apparel do not require manager approval up to $150"}
  -- true independent of any one customer or date; would still hold if this specific
     jacket return never happened.

Procedural behavior (long-term, refined via reinforcement learning over many sessions):
  A policy that has learned, through repeated practice and reward signal on resolution
  time, to ask for the order number and the reason in a single combined message rather
  than two sequential questions -- a compiled interaction pattern, not a retrieved fact.

Constructed scenario — the specific values (customer id, dollar threshold, date) are illustrative, not drawn from a real support system. Notice that all four of these — short-term, episodic, semantic, and procedural — can coexist in the same agent, each answering a different question. The session buffer answers "what did this user just say." The episodic entry answers "what specifically happened with this one customer's return." The semantic entry answers "what is the general policy for this class of return." The procedural behavior answers "how should this agent's interaction pattern itself execute" — and none of the four is a substitute for any other.

A common exam-style scenario names an agent behavior and asks which memory type it demonstrates. Work through four variants of the same underlying agent to see how the same surface behavior ("the agent handled the situation well") maps to different categories depending on what is actually being retained.

Variant A: The agent recalls that this exact user, in this exact session, already gave
their order number two messages ago, and does not re-ask for it.
  -> Short-term. Nothing here persists past this session; it is the current buffer only.

Variant B: The agent recalls that a customer with this exact name filed a nearly
identical return request four months ago, and cites that specific prior case while
handling the new one.
  -> Episodic. A specific, dated past event is being retrieved as a precedent.

Variant C: The agent applies a rule -- "returns without a receipt still qualify for
store credit" -- that holds for every customer and every date, with no reference to
any one prior case.
  -> Semantic. A generalized fact/rule, not tied to any specific instance.

Variant D: The agent's phrasing and question-ordering for return requests has become
noticeably more efficient over many months of live traffic, having been tuned by a
reward signal on faster resolution times, with no explicit fact or case being retrieved.
  -> Procedural. A learned behavior improving through practice, not a retrieved item.

Constructed scenario — illustrative only. The exam's version of this question typically gives you only one variant at a time and expects you to classify it correctly without the other three as scaffolding; working through all four side by side here is what makes the boundary between them visible before you have to draw it cold.

Cognition, Planning, and Memory carries 10% of the NCP-AAI blueprint, and [GROUND TRUTH] (Sources/ncp-aai/domain-5-cognition-planning-memory.md) states plainly that "the memory taxonomy and the five planning directions are the most testable pieces" in this domain, with an explicit scope note instructing candidates to "memorize which memory type stores what." The source material's own list of common exam traps names exactly the failure modes this lesson has walked through in order: treating short-term memory as though it can persist across sessions, mixing up episodic ("specific events"), semantic ("general facts"), and procedural ("skills/how-to"), and assuming an LLM remembers on its own rather than needing memory added as a component (the premise M5-01 already covered in full).

Expect the question shape to present a short scenario describing what an agent retained and how it used it, then offer four memory-type labels as options, exactly one of which fits — with the incorrect options deliberately built around the three specific confusions named above. The "could this survive losing the specific instance" test from §7 and the "did anything actually get learned, versus hard-coded" test from §6's L3 are the two fastest checks for resolving these under time pressure, because both let you classify correctly from the scenario's content alone, without needing to know or guess at what storage technology sits underneath it.

⭐ THE EARNED INSIGHT

The three finer categories are not sorted by where they live or how they are indexed — a vector store can back episodic, semantic, or even long-term memory generally, so "what database is this" answers nothing about which category applies. They are sorted by one question alone: would this content still be true and useful if the one specific instance that produced it disappeared? Semantic and procedural pass that test by design; episodic fails it by design, because being irreducibly specific is the entire point of an episode. Answer that one question first, and the label follows — guessing from the storage technology never will.

Naming which of the five categories a given piece of memory belongs to is necessary but not sufficient for designing the memory system itself — the taxonomy tells you what kind of thing you are storing, not how much of it to keep, how to decide what is worth writing in the first place, or when a semantic rule extracted from episodic entries should be trusted over the raw entries it was generalized from. Those are real design questions with no single universal answer: an agent might keep every episodic entry indefinitely if storage is cheap and audit requirements demand a full history, or it might aggressively summarize old episodes into semantic rules and discard the originals once confidence in the generalization is high enough. The taxonomy is a classification scheme, not a retention policy, and the exam tests the classification, not the policy — but it is worth being explicit that classifying correctly is the first step of a larger design job, not the whole job.

It is also worth being explicit about what this lesson has deliberately not covered, so the boundary with neighboring lessons stays clean. This lesson classifies memory; it does not cover how an agent decides, moment to moment, which memory to act on as part of a multi-step plan, and it does not cover the mechanics of how a long-term store is queried at the implementation level — chunking, indexing, similarity search, and the retrieval pipeline itself belong to this cert's Module 6 on knowledge integration, not to the classification question this lesson answers. Keeping those two questions separate matters for the exam specifically because a scenario can test "which memory type is this" and a completely different scenario can test "how would you retrieve from it," and answering the first with a retrieval-mechanics answer, or the second with a classification answer, misses what is actually being asked.

Episodic memory stores specific past events — a particular case, with its own context, action, and outcome, such as one customer's return request on one date. Semantic memory stores generalized facts and rules that hold independent of any single instance, such as a general return policy. The fastest way to tell them apart is to ask whether the content would still be true and useful if the one specific instance that first produced it were removed: episodic memory fails that test because the specific instance is its entire content, while semantic memory passes it because generalization is exactly what makes it semantic.

No. Procedural memory specifically refers to a skill or behavior that was acquired or refined through experience — commonly reinforcement learning — improving with practice rather than being authored directly by an engineer. A hard-coded workflow that reliably executes the same fixed steps every time demonstrates good engineering, not procedural memory, because nothing about it was learned or improved through repeated exposure and feedback. The distinguishing question is always whether the behavior got better through experience, not whether it currently runs reliably.

Because "long-term" only answers whether information persists past a session boundary — it says nothing about what kind of information is persisting or how it functions once retrieved. Episodic, semantic, and procedural memory are three functionally distinct answers to that follow-up question, each with its own typical implementation and its own role in an agent's reasoning, and a scenario question naming one of the three expects that specific label, not the umbrella term one level above it.

• The taxonomy has five categories, not two: short-term and long-term are the top-level split, and long-term further subdivides into episodic, semantic, and procedural.
• Episodic memory holds specific past events; semantic memory holds generalized facts; procedural memory holds learned skills — sort by content and function, never by implementation technology, since all three can be backed by overlapping storage choices.
• The fastest test for episodic vs. semantic: would this content survive losing the one specific instance that produced it? Episodic fails that test; semantic passes it.
• The fastest test for genuine procedural memory vs. a hard-coded process: did the behavior improve through experience or a reward signal, or was it simply authored once and never learned?
• Short-term memory does not persist across sessions under any circumstance — anything that must survive a session boundary belongs in one of the three long-term categories.
• On the exam, expect a short scenario naming a specific agent behavior and asking which memory type it demonstrates, with distractors built around exactly the three confusions this lesson worked through: two-category reduction, episodic/semantic mixing, and procedural/hard-coded conflation.

This lesson has been about what an agent stores and recalls. The next lesson turns to what an agent does with a task once it has decided to act on it: M5-03 covers chain-of-thought and task decomposition as reasoning frameworks, including how ReAct — already covered by id in this cert's Module 1 — fits as one application of a CoT-style reasoning loop wrapped around tool actions, rather than a competing framework.