The useful types of agent memory are working, short-term, long-term, episodic, semantic, procedural, source, and retrieval memory. The labels matter only when they change behavior: what gets written, how it is scoped, how it is retrieved, how it is inspected, and how it is deleted.
Last updated: June 20, 2026.
Why classify agent memory at all?
Memory types keep teams from storing every fact the same way. A current project rule should not age like a chat aside. A source document should not be treated like a preference. A retrieval trace should be stored for debugging, not fed back into the next answer as if it were a fact.
LangChain’s memory concepts use short-term and long-term memory categories, and LangChain’s agent-memory writing also names semantic, episodic, and procedural memory patterns. Research surveys such as A Survey on the Memory Mechanism of LLM-based Agents organize memory by lifetime, structure, and retrieval mechanism. For product teams, the taxonomy should be practical rather than academic.
What are the core memory types?
| Type | What it stores | Example | Key control |
|---|---|---|---|
| Working memory | Current task state | ”The user is editing pricing copy” | Prompt assembly |
| Short-term memory | Thread state over a bounded session | ”The last three tool calls failed” | Compaction |
| Long-term memory | Durable facts across sessions | ”Use pnpm in this repo” | Write policy |
| Episodic memory | Events and decisions | ”The team delayed SSO on June 20” | Timestamp and source |
| Semantic memory | Stable facts | ”The MCP endpoint is engine.answeragent.ai” | Scope |
| Procedural memory | How work should be done | ”Run tests before closing issue work” | Priority |
| Source memory | Documents, tickets, pages, transcripts | ”This answer cites ticket AE-527” | Provenance |
| Retrieval memory | Query, candidates, ranks, answer path | ”This answer retrieved three policy chunks” | Inspection |
The type is not just a label. It decides whether the record should be retrieved often, shown to a user, updated by supersession, or deleted with derived artifacts.
What is working memory?
Working memory is the immediate state inside a task. It includes the user’s latest request, tool output, scratch decisions, and current constraints. It is usually not durable by default.
Treat working memory as the model’s current workbench. It should be small, relevant, and easy to replace. If every scratch note becomes long-term memory, the system creates bloat and future retrieval noise.
What is short-term memory?
Short-term memory is state inside a conversation or thread. It may survive compaction or summarization, but it is still tied to a bounded session. Claude Code and other coding agents often use compaction or context files to keep a long task moving, but that is not the same as shared source-aware memory.
Read Claude Code loses context after compaction for the specific failure mode.
What is long-term memory?
Long-term memory is durable and intentionally written. It should store facts that are likely to matter later, such as project rules, user preferences, decisions, source summaries, or customer context. It should also include scope and source lineage.
The OpenAI conversation state guide is a reminder that applications manage state. Long-term agent memory is an application data layer, not an assumption that the model will remember.
What are episodic, semantic, and procedural memory?
Episodic memory stores events: meetings, decisions, support cases, incidents, and sessions. Semantic memory stores facts: names, policies, product details, and domain knowledge. Procedural memory stores process: commands, preferences, review rules, and workflow expectations.
These three types are common because they map to different retrieval intents. “What happened?” asks for episodic memory. “What is true?” asks for semantic memory. “How should I do this?” asks for procedural memory.
What is source memory?
Source memory is the trust layer. It stores the document, ticket, page, transcript, or artifact that backs a memory. Without source memory, the agent can produce a plausible answer but cannot prove where it came from.
The Model Context Protocol architecture distinguishes resources and tools. A source-aware memory server can expose resources for schemas or content and tools for search, ask, write, and retrieval. That source surface is what makes memory inspectable.
What is retrieval memory?
Retrieval memory is the trace of what happened during a retrieval event: query, filters, candidate ids, scores, rank, citations, and final answer path. It is not usually user knowledge. It is operational memory for debugging.
This is the backbone of Inspectable Agent Memory and the Memory Failure-Mode Catalog. If a user asks why the agent answered with an old policy, retrieval memory lets you inspect whether the old policy was retrieved, ranked, and included.
How should memory type affect deletion?
Deletion should target source and derived artifacts. If a user asks to delete a personal preference, delete or disable the semantic memory, derived embeddings, and retrieval paths that expose it. If a source document is removed, derived summaries and indexes must stop serving it.
For source memory, deletion needs a source artifact handle. For procedural memory, deletion may be a rule update. For retrieval memory, retention may be an audit policy rather than a recall policy.
What should you read next?
Use the Agent Memory Glossary for short definitions, Memory needs a write path for architecture, and Portable Agent Memory for migration behavior.