AI Agent Memory Types: Give Each One a Health Test

The useful answer to “which AI agent memory type do I need?” is not “all of them.” Choose the smallest memory that crosses the boundary your task requires, then give that memory its own acceptance test. A current goal that must survive the next graph step is working memory . A fact that must remain available across sessions is semantic memory . A past attempt that is valuable because of what happened is episodic memory . A rule that changes how future work is performed is procedural memory . Those four jobs fail differently. A generic “the vector search returned a result” check can miss a lost checkpoint, a stale fact, an episode with no outcome, or an unapproved procedure. The operational default is therefore: 1. declare the boundary the memory must cross; 2. retain a content free write and read receipt; 3. verify scope, freshness, provenance, and activation; 4. apply one type specific invariant; 5. verify the external task separately. This article turns the common AI agent memory types taxonomy into that testable contract. Start with the boundary, not the database The CoALA architecture separates short term working memory from long term episodic, semantic, and procedural memory. It also distinguishes retrieval, which reads long term memory into working memory, from reasoning within working memory and learning that writes long term memory. That separation is more useful operationally than a list of storage products. A PostgreSQL row, a JSON file, a vector, and a checkpoint can each implement more than one memory type. The datastore does not tell you what failure matters. LangGraph’s memory documentation makes the scope distinction concrete: short term state is attached to a thread, while long term items can live in custom namespaces and cross threads. The same documentation describes semantic memory as facts, episodic memory as experiences, and procedural memory as rules or instructions. These are different contracts even when one store holds all three. Use one question to choose the first boundary: What must still be available, in what scope, at which future decision? “Remember the current tool result during this run” needs a smaller contract than “remember this customer preference next month.” “Recall a similar incident” is weaker than “activate only the approved recovery procedure.” Adding long term memory where working state would suffice creates extra retention, deletion, privacy, and retrieval obligations. Redis’s current implementation guide recommends starting with the short versus long term need and adding specialized memory when its operational value justifies the complexity. That is a good default, independent of whether Redis is the chosen store. Give each memory type a different acceptance test The four types can share an evidence envelope, but they should not share their final verdict rule. Memory type Job Boundary to prove Type specific failure Working Carry active goals, intermediate results, and dependencies The next required step, checkpoint, or controlled restart The item was written and read, but did not cross the required continuity boundary Semantic Supply current facts and concepts The intended tenant, user, project, or agent scope across sessions The retrieved fact is stale, superseded, or from the wrong scope Episodic Reuse a past experience From a recorded attempt to a later decision that needs its outcome The episode lacks an observed outcome, so the agent cannot tell success from activity Procedural Control how work is performed From an approved version to the active prompt, rule, code path, or model behavior The active procedure is unapproved, unversioned, or has no bounded rollback Working memory: prove continuity Working memory is not synonymous with “whatever fits in the model context.” CoALA describes it as the active variables available to the current decision cycle. In a runtime, that state may be assembled from messages, a graph checkpoint, task metadata, tool results, or an external state record. Test it with an opaque canary tied to a required boundary: write the active goal ID and checkpoint version; advance one real step or perform the controlled restart the runtime promises to survive; read the state in the same expected thread or run scope; confirm the goal ID and pending dependency are still available; prove the restored value entered the next decision. The last check matters. A checkpoint can contain the canary while prompt assembly silently omits it. Storage is green; behavior is not. Semantic memory: prove currency and scope Semantic memory stores facts rather than one particular event. A healthy read needs more than similarity. Retain the opaque memory ID, source version, scope hash, write time, read time, and invalidation status. Then verify that the effective fact is current for the decision time and belongs to the expected namespace. A high similarity score cannot make a superseded address or revoked permission current. The safe response to contradictory facts is usually uncertain , not “pick the nearest vector.” Resolve provenance or ask a human before allowing the fact to drive an irreversible action. Episodic memory: prove the outcome An episode is useful because it connects a situation, an action, and what followed. An event log containing many tool calls is not automatically episodic memory. For an incident response agent, an episode such as “retried the export” is incomplete. The useful record also says whether the destination received exactly one valid export, whether the retry exhausted its budget, and whether a human intervened. The content free receipt can keep an episode ID, action class hash, outcome receipt ID, timestamps, and verification state. Test retrieval with a known case whose outcome changes the correct next action. If the episode is returned but the outcome is absent, classify it as OUTCOMELESS EPISODE . Do not let activity masquerade as experience. Procedural memory: prove authority Procedural memory includes the rules used to perform tasks. CoALA includes both implicit procedures in model weights and explicit procedures in agent code; LangGraph’s guide also includes code, model weights, and prompts in this category. This is the highest risk memory to change because it alters future behavior. Its receipt should include: the active procedure version; the approved version; the actor or policy that authorized promotion; a test suite or evaluation reference; an activation time; a rollback reference; the scope in which the procedure may run. If active and approved versions differ, retrieval health is irrelevant. The correct verdict is UNSAFE PROCEDURE , and the next move is an authority or release decision—not an automatic rewrite. Use one content free receipt The shared envelope below records operational evidence without storing the fact, episode, prompt, or user content: Seven checks form the common path: 1. Available: Was the memory subsystem observable, or is the verdict unknown? 2. Write: Did the intended store acknowledge the write? 3. Read: Did a later decision retrieve the same opaque item? 4. Scope: Did expected and observed scope identifiers match? 5. Freshness: Was the evidence within the declared age budget? 6. Provenance: Can the system identify where this item or version came from? 7. Activation: Did the item enter the intended decision, rather than merely appear in search results? Then apply the type specific rule: continuity for working memory, source currency for semantic memory, outcome linkage for episodic memory, or approval and rollback for procedural memory. The order prevents misleading verdicts. For example, a scope mismatch should stop evaluation before activation. A missing read should not become “not activated,” because the first failed layer is retrieval. Run the nine case classifier The inspectable publication artifact contains memory health cases.json and classify memory health.mjs . The decision precedence is small enough to reproduce in any runtime: The fixture covers a healthy working memory case plus lost continuity, stale semantic data, a scope breach, an episode without an outcome, an episode retrieved but not activated, an unapproved procedure, a retrieval failure, and unavailable evidence. Run: The recorded result for this article was: That pass proves the classifier follows its declared precedence. It does not prove a live memory backend is healthy. Separate memory health from task success A memory receipt can prove that an opaque item crossed its declared boundary. It cannot prove that a fact is true, that the recalled episode is the best precedent, or that an approved procedure will succeed in every environment. Keep a second, deterministic outcome receipt whenever possible. A support agent may correctly retrieve a customer’s current shipping preference and still fail to update the order. A coding agent may restore the exact active goal after restart and still omit the requested file. A recovery agent may activate the approved runbook and still produce a duplicate external effect. The operational state should reflect both ledgers: memory healthy, outcome verified: clear the memory related issue; memory healthy, outcome missing: investigate execution or destination verification; memory failed, outcome verified: record a degraded dependency; the run may have succeeded by fallback; memory failed, outcome missing: fix the first failed memory layer before trusting a retry; evidence unavailable: stay uncertain rather than manufacturing green. This separation also limits data collection. Health evidence can retain hashes, IDs, versions, timestamps, scopes, booleans, and verdicts. Prompt text, personal facts, episode content, tool arguments, and secrets do not need to leave the host merely to show that a contract passed. Choose the smallest contract that can work For a new agent, begin with the outcome and work backward: 1. If information is needed only during the current decision cycle, keep it in working memory. 2. If a fact must cross sessions, add semantic memory with source, scope, update, and invalidation rules. 3. If a past attempt should influence a later choice, add episodic memory only when the attempt has an outcome receipt. 4. If behavior itself must change, treat that change as procedural memory and put promotion, approval, tests, and rollback around it. Do not add a memory type because a framework offers a class with that name. Add it when an observable task boundary requires it. Do not call it healthy because the store responds. Call it healthy when the correct evidence was written, recalled in the right scope, still current, activated at the intended decision, and passed the invariant specific to that type. Sidewisp is currently in private preview. Its intended health model includes missing memory reads or writes, failed persistence, stale synchronization, and lost decisions, but production agent health collection and runtime adapters are not shipped today. The receipt in this article is a design you can run locally now; it is not a claim that Sidewisp currently monitors or repairs your agents.