The useful idea behind a three-tier memory model is simple: keep the right information available at the right horizon. The production reality is more rigorous. Memory is not a pyramid. It is a governed system of context, retrieval, persistence, reflection — and deliberate forgetting.
The source infographic gets the operational instinct right: agents become more useful when they can preserve context, retrieve relevant knowledge and carry durable information across sessions. But it collapses two different questions into one: how long information should persist and what kind of memory it is. Production architectures should model those as separate dimensions.
Working context can be ephemeral even when the underlying session history is persisted.
Semantic, episodic and procedural memory describe content types — not fixed retention durations.
Durable storage is useless without a retrieval policy, write policy, provenance and forgetting policy.
The three layers remain useful when reframed as operational storage and retrieval horizons rather than as a psychological taxonomy.
Instructions, recent turns, tool outputs and task-local state that the model needs now. It should be aggressively curated because context capacity is finite and irrelevant tokens dilute attention.
Information likely to matter again soon: project facts, temporary preferences, task summaries, recent decisions, open commitments and structured state. This layer is best understood as retrievable working knowledge, not “semantic memory by definition.”
Stable information worth carrying across long horizons: explicitly saved preferences, durable facts, validated procedures, important histories and learned patterns. Persistence should be selective, attributable and reversible.
A user preference can be durable semantic memory. A successful workflow can become durable episodic or procedural memory. A temporary project fact can also be semantic but short-lived. Retention and memory type are orthogonal.
Facts, concepts, entities, relationships and preferences — “what is true or believed to be true.”
Past events, outcomes and action traces — “what happened.”
Rules, methods and learned operating instructions — “how to act.”
Receive user input, environment state, tool outputs and agent actions.
Identify scope, type, expected lifetime, sensitivity, confidence and likely future utility.
Persist only what passes policy. Attach provenance, timestamp, ownership, expiry and confidence.
Fetch memories based on task relevance, identity scope, recency, confidence and permission — not semantic similarity alone.
Summarize repeated episodes, merge duplicates, promote stable patterns and resolve contradictions.
Remove stale, low-value or revoked information. Preserve correction history where auditability requires it.
Use the controls to see how retention, sensitivity and repeatability change a reasonable storage decision. This is a transparent heuristic demo — not an automated policy engine.
Production systems should additionally consider jurisdiction, organizational policy, user consent, data classification, source reliability and access boundaries.
A production agent needs a memory control plane that decides what may be written, how it is indexed, what can be retrieved, what enters model context, how conflicts are resolved and when information must be deleted.
Messages, files, tools, events, application state.
Utility, consent, sensitivity, scope, volatility, provenance.
Recent messages, run state, summaries, checkpoints.
Profiles, facts, preferences, task records, provenance metadata.
Episodes and notes indexed for keyword / semantic retrieval.
Documents, databases and knowledge bases that are not “user memory.”
Instructions, policies, skills and operating playbooks.
TTL, revocation, supersession, legal holds, audit policy.
Scope filters + relevance + recency + confidence + permission.
Prefer newer, more authoritative, explicitly corrected evidence.
Budget tokens; select minimum sufficient evidence for the run.
Instructions + selected context + tools + current task.
Detect useful patterns, failures, corrections and candidate updates.
Reference pattern, not a prescriptive vendor stack. Some systems combine components; others separate them for latency, security or observability.
An agent that remembers can become more helpful — and more invasive, more confidently wrong, harder to audit and easier to poison. The memory layer needs explicit controls.
| Risk | Failure mode | Production control |
|---|---|---|
| Stale truth | Old facts survive after circumstances change. | Timestamps, TTL, supersession rules, confidence decay, refresh-on-use. |
| Contradiction | Multiple memories disagree and retrieval hides the conflict. | Source ranking, contradiction detection, explicit version history. |
| Memory poisoning | Untrusted content becomes persistent operating knowledge. | Trust boundaries, write authorization, source provenance, quarantine for inferred memory. |
| Privacy overreach | The system stores information that was useful once but should not persist. | Data minimization, opt-in persistence, sensitive-data policy, user deletion. |
| Scope leakage | Memory crosses users, organizations or projects. | Namespace isolation, tenant-scoped keys, access control, retrieval filters. |
| Over-personalization | Past behavior narrows future choices or creates awkward assumptions. | Uncertainty language, editable preferences, use memory only when task-relevant. |
Teams often begin with a vector database because retrieval is tangible. The harder design work comes earlier: what may become memory, under what scope, with what expiry, and how the user can correct it.
# illustrative record — vendor neutral { "scope": "user:123 / project:alpha", "memory_type": "semantic", "horizon": "durable", "content": "Prefers aisle seats on flights over 4h", "source": "explicit_user_statement", "confidence": 1.00, "created_at": "2026-09-04T19:10:00Z", "expires_at": null, "sensitivity": "low", "user_editable": true, "supersedes": null }
Of the memories written, how many were actually worth persisting?
valuable_writes / all_writesOf the facts or episodes that should have been saved, how many were captured?
captured_worthy_items / all_worthy_itemsWhen memory is queried, how much of the returned set is task-relevant and authorized?
relevant_authorized_items / retrieved_itemsHow often does outdated or superseded memory influence a response or action?
stale_influences / memory_assisted_runsDoes memory improve task quality, latency, user effort or cost compared with a memory-disabled baseline?
Δ outcome versus controlled baselineHow quickly does a user correction stop an obsolete memory from influencing behavior?
time_to_effective_supersession“Book me a flight to Paris next Friday.” Keep as active task context.
Known travel preferences only if relevant, authorized and current.
Current flight schedules and prices come from live tools — not memory.
Use aisle preference to rank options, but do not let an old preference override explicit new instructions.
If the user explicitly updates a durable preference, write a superseding memory with provenance.
This page deliberately refines the source infographic rather than reproducing it. The central correction — separating retention horizon from memory type — is consistent with current agent frameworks and cognitive-architecture literature.
Research note. No single three-tier memory model is an industry standard. “Short / mid / long-term” is best treated as a useful engineering metaphor. Implementations vary by model, orchestration framework, data sensitivity, latency budget and product requirements. Where vendor documentation differs, the page favors the underlying architectural principle rather than implying a universal API.
We design production AI systems where context, retrieval, memory, evaluation and human authority are engineered as one operating model.