Working memory is what an agent is actively thinking about. Episodic memory is what happened to a specific user at a specific time. Semantic memory is what is true in general.

Most agents have semantic memory partially baked in. The model's training data is a giant semantic memory of the world. What's missing is personal semantic memory: facts about this specific user, this team, this codebase that the model never saw during training.

That gap is what a personal-semantic memory layer fills. The gap is bigger than it looks.

What is semantic memory?

The cleanest definition comes from Endel Tulving's 1972 chapter "Episodic and Semantic Memory," published in Organization of Memory. Tulving proposed splitting long-term memory into two systems with different jobs.

Semantic memory holds the facts and meanings a person knows. In Tulving's framing, it functions like "a mental thesaurus": the structured knowledge of words, verbal symbols, their meanings and references, and the rules for manipulating them.

Episodic memory, by contrast, holds personal experience tied to a specific time and place. Tulving described it as storing "temporally dated episodes or events, and the temporal-spatial relations" among them.

Knowing what a cat is sits in semantic memory. Remembering the cat that jumped on the keyboard last Tuesday sits in episodic memory.

Tulving was careful to call the distinction "an orienting attitude or a pretheoretical position." Even in 1972 he argued the two systems were interdependent. That qualifier matters for agent design, because the line between "the user prefers Python" (semantic) and "the user said they prefer Python on March 4" (episodic) blurs the moment a system has to decide what to store.

Semantic vs working memory

A second distinction worth being precise about. Semantic memory is durable. Working memory is active.

Working memory is the small, volatile state the agent is currently reasoning over. The current task, the recent turns, the scratchpad. It dies when the session ends.

Semantic memory is what survives across sessions. The user's preferred language. The project's deploy command. The team's code review conventions. None of this changes turn-by-turn. All of it has to be available next session.

The CoALA framework (Sumers et al., 2024) makes the same split for language agents. CoALA models a language agent as working memory plus long-term memory, where long-term memory is itself divided into semantic, episodic, and procedural components. Working memory is the scratchpad. Semantic memory is where the durable facts live.

What the model already knows, and what it does not

Frontier LLMs already encode an enormous amount of semantic knowledge in their parameters. Capitals, language rules, library APIs, common-sense relationships, historical dates. CoALA explicitly notes that semantic memory in a language agent can include "factual knowledge about the world," and that much of this knowledge is "embedded in the agent's code or the LLM's parameters."

That covers world knowledge. It does not cover personal knowledge.

Personal semantic memory is the set of facts that exist only because of this particular user, this particular team, this particular project. A frontier model trained six months ago has no way to know:

• The user's name, role, time zone, and preferred language.

• The team's primary cloud, framework, and deploy target.

• The project's database, schema, and naming conventions.

• The customer's renewal date, plan tier, and last support ticket.

These facts are stable enough to be semantic and specific enough to be useless to anyone else. They are exactly the layer most agents are missing.

Foundation models gave agents an encyclopedia. They did not give agents a notebook with the user's name on it.

The rest of this post is about that notebook.

How agents implement semantic memory today

Pattern 1. Instruction files and Skills

The simplest implementation writes facts directly into the system prompt. Anthropic formalized a richer version with Agent Skills.

A skill is a directory containing a SKILL.md file with YAML frontmatter (name and description) plus optional bundled resources. Skills load in three stages. The frontmatter is always loaded (about 100 tokens per skill). The body of SKILL.md loads when the skill is triggered (under 5K tokens). Bundled files load only when referenced.

The community-convention equivalents are AGENTS.md and CLAUDE.md for project-level facts, and .cursorrules for Cursor. They share a common pattern: a markdown file the agent reads at session start and treats as durable instructions.

This works well for facts the team is willing to write down once. It breaks down for facts that change frequently or facts specific to one user out of many.

Pattern 2. RAG over docs

Retrieval-augmented generation handles bulk text knowledge. Chunk a documentation corpus, embed the chunks, search at inference time. RAG is the right tool when the agent needs to cite a paragraph from a handbook.

It is the wrong tool for short, durable, user-scoped facts. Embedding a sentence like "the user does not use Vercel" into a million-document store and trying to retrieve it later by similarity search is brittle. Negation and short factual statements are exactly what dense retrieval struggles with.

Pattern 3. Knowledge graphs

Entity-relation stores fit semantic facts naturally. A graph node for the user, edges to preferences, projects, and team members. Graphs handle multi-hop questions ("what database does Alex's main project use?") better than flat vector stores.

The cost is operational complexity. Schema design, ingestion, and updates all become engineering surface area.

Pattern 4. Memory layers

A managed service whose job is exactly this: extract facts from conversation, store them durably, retrieve them at the right moment, reconcile them when they change. Mem0 and similar systems live here.

The memory-layer pattern treats facts as first-class entries with identifiers, scopes, metadata, and an update path. That last point is the one most other patterns fail at.

Comparison at a glance

For a deeper look at how memory can be organized, see our guide to structured vs. unstructured memory in AI agents.

Vendor Comparison: Who Covers Which Memory Type

Different platforms cover different pieces of the episodic/semantic/procedural taxonomy, and not always in the way their marketing implies. Here's an honest breakdown:

If you're building a CTO-facing architecture proposal: Mem0 and LangMem are the two platforms with genuine, shipped coverage across multiple memory types today. IBM's content is a strong conceptual reference for the taxonomy itself, not a specific product to evaluate against the others. Letta's tiered model covers similar ground through a different mechanism (LLM-managed paging rather than extraction). Zep is the strongest option specifically when episodic/temporal reasoning through a knowledge graph is the primary requirement, with semantic memory well covered but procedural memory not a focus.

Privacy and PII Risk by Memory Type

Of the three AI agent memory types, semantic memory carries the greatest privacy and retention risk. It's built to be durable: a fact like a user's name, employer, or health condition, once extracted into semantic memory, persists indefinitely unless something explicitly updates or deletes it. Episodic memory, by contrast, is more naturally bounded to specific timestamped events and is more commonly pruned or decayed over time in production systems. Semantic memory's entire design goal, permanence across sessions, is also what makes it the layer where stale or sensitive personal information is most likely to sit unnoticed.

This is exactly why the update and delete primitives matter beyond convenience. A memory layer that can only add facts accumulates PII indefinitely with no mechanism to remove it on request. One that supports explicit update and delete operations gives both the system and the user a real path to correct or remove a durable fact, which matters for anything touching a "right to be forgotten" style request, not just for keeping facts current.

Failure modes worth flagging

Five failure modes show up consistently in agent semantic memory.

• Stale facts: The user changes jobs, switches stacks, or updates a preference. The old fact lingers because nothing told the system to retire it. The agent then suggests an outdated framework with full confidence.

• Confusion with episodic recall: A semantic fact is "the user prefers Postgres." An episodic fact is "the user mentioned Postgres on March 4." Storing them with the same shape and the same retrieval path turns durable preferences into noisy timestamped history.

• Overwrite vs update tension: Hard delete on contradiction loses the audit trail. Soft writes on every utterance create duplicates. Most teams oscillate between these two failure modes for a quarter or two before settling on a hybrid policy.

• Fact contamination across users: Without strict scope keys on every read, a fact stored under one tenant can leak into another tenant's prompt. This is one of the rare memory bugs that is both subtle and a security incident at the same time.

• System prompt drift: Hand-edited instruction files (CLAUDE.md, AGENTS.md, .cursorrules) accumulate facts the way any shared doc does. After a few months they are bloated, contradictory, and read on every turn whether the current task needs them or not.

The common thread is that semantic memory is not a write-once problem. It is a continuous extract, scope, update, and retrieve loop, and the systems that ship best are the ones that make every step explicit.

LangMem Comparison

LangMem, LangChain's memory SDK, is worth comparing directly since it takes a meaningfully different approach to the same problem.

LangMem organizes memory as configurable Memory Managers and Store Managers that sit on top of a LangGraph-backed store. It supports semantic memory (facts and profiles), episodic memory (past interactions, often surfaced back to the agent as few-shot examples), and procedural memory through a Prompt Optimizer that updates the agent's own instructions based on conversation outcomes, a genuinely distinct capability not every memory platform ships.

The core architectural difference from Mem0 is where the decision logic lives and what the storage layer assumes. LangMem is backend-agnostic by design: it expects you to bring a store (Postgres, a vector database, or LangGraph's own BaseStore) and provides the memory-management logic on top. Mem0 bundles extraction, deduplication, and a specific vector-plus-metadata storage model into one API, so there's less assembly required but less flexibility in swapping the underlying storage philosophy.

Latency is also a documented, meaningful difference between the two on the LoCoMo benchmark specifically: independent testing has put LangMem's p95 search latency at roughly 60 seconds, which makes it a reasonable fit for background or batch memory processing but a poor fit for latency-sensitive, interactive agents. Mem0's p95 search latency on the same benchmark is reported at roughly 0.2 seconds. If your use case is interactive rather than batch, that gap is likely to matter more than feature parity on the memory-type taxonomy.

Where Mem0 fits

Mem0 treats personal semantic memory as a first-class layer in its own data model. The docs call it user memory: long-lived knowledge tied to a person, account, or workspace, separated from short-lived session state and from in-flight conversation turns. The other patterns retrofit this separation. Mem0 starts there.

The mechanism is extraction-based, not summarization-based, and it's single-pass ADD-only. When a turn is added to Mem0, an extraction model pulls candidate facts out as atomic items and writes them as new memories. It does not overwrite or delete older memories during extraction: when information changes, the new fact is stored alongside the old one, preserving a full history rather than silently replacing it. Distinguishing which of two facts is current happens at retrieval time, not write time, through temporal reasoning that ranks more recent memories higher alongside semantic, keyword, and entity signals. The index holds distilled facts, not message blobs, but it's an accumulating record rather than a self-editing one.

The five failure modes named earlier map back to specific pieces of this design, though not all of them resolve the same way an UPDATE/DELETE model would:

Stale facts are addressed by recency weighting at retrieval, not by removal at write time. An older fact isn't deleted when a newer, contradicting one arrives; it's ranked lower, so the current fact surfaces first. The old fact still exists in the store, which preserves the audit trail but means an application that only reads top-ranked results should generally see the current state.

Confusion with episodic recall is handled by keeping the two as separate stores with a defined path between them. Mem0's own hierarchy splits episodic memory (summaries of past interactions) from semantic memory (durable facts, relationships, preferences, learned knowledge), so a preference doesn't get stored and retrieved with the same shape as a one-off event.

Overwrite vs update tension resolves differently under ADD-only than it would under a delete-based model: there's no overwrite, by design. Every stated preference becomes its own memory entry, and reconciliation is a retrieval-time ranking problem rather than a write-time deletion decision. This trades a completely clean current-state view for a complete history, which is a deliberate tradeoff, not an oversight, but it does mean an application built assuming old facts are removed should instead assume they're deprioritized.

Cross-user contamination is handled by mandatory scope keys, independent of the ADD-only vs. delete-based question. Every read filters on user_id, agent_id, or run_id. A fact stored under one tenant cannot surface in another tenant's prompt unless the call explicitly asks for it.

System prompt drift stops being a problem when facts live in a queryable store. Instead of every session reading a growing markdown file at startup, the agent calls memory.search with the current query and pulls back the few facts that rank highest for relevance and recency. The instruction file stays small. The knowledge layer scales.

How this pairs with other memory types

Semantic memory is one layer in a four-part cognitive map for agents. The other three are working memory, episodic memory, and procedural memory.

A complete agent memory architecture has all four:

• Working memory holds the active state of the current turn.

• Episodic memory holds time-stamped events: what the user did last Tuesday, what the agent decided last week.

• Semantic memory holds the durable personal facts: preferences, conventions, project state (this post).

• Procedural memory holds the workflows: how to deploy, how to triage, how to compose a release.

Each fits a different class of query. Conflating them is the source of most "the agent has the memory of a goldfish" complaints in production.

For a deeper comparison of these memory types, see our guide to semantic vs. episodic vs. procedural memory in AI agents.

Frequently Asked Questions

Q. Which AI memory platforms support semantic, episodic, and procedural memory?

Mem0 and LangMem currently ship the broadest coverage: Mem0 natively supports semantic and episodic memory, with procedural memory support still early-stage; LangMem supports all three, including a distinctive self-updating procedural layer. IBM's watsonx content documents the same three-part taxonomy conceptually, as an educational framework rather than a specific product feature set. See the comparison table above for the full breakdown, including Letta and Zep.

Q. What's the difference between semantic memory and episodic memory in AI agents?

Semantic memory stores durable, general facts, the user's preferred language, a project's deploy command, that stay true across sessions until something changes them. Episodic memory stores specific, timestamped events, what the user said on a particular date, what happened in a particular interaction. Semantic memory answers "what is true"; episodic memory answers "what happened, and when."

Q. Which type of AI agent memory poses the greatest privacy risk?

Semantic memory, because it's designed for indefinite persistence. A durable fact about a user, once extracted, stays in the store until explicitly updated or deleted, which makes it the layer most likely to retain sensitive personal information beyond when it's still relevant, unless the memory system has real update and delete primitives.

Q. How is Mem0's semantic memory different from LangMem's?

Mem0 bundles extraction, deduplication, and storage into a single opinionated API with sub-second retrieval latency. LangMem is backend-agnostic and gives you configurable Memory Managers on top of a store you choose, with broader native memory-type coverage including procedural memory, but with meaningfully higher search latency on standard benchmarks, making it better suited to background processing than latency-sensitive interactive agents.

Q. Who coined the terms semantic and episodic memory?

Endel Tulving, in his 1972 chapter "Episodic and Semantic Memory," published in Organization of Memory. He described semantic memory as a kind of mental thesaurus of facts and meanings, and episodic memory as the store of personally experienced events tied to a specific time and place. He also cautioned that the distinction was "an orienting attitude" rather than a hard boundary, a nuance that still shows up in how agent systems have to handle facts that sit between the two categories.

The shape of the choice

Foundation models give every agent a built-in semantic memory of the world. That's most of what's needed for general questions.

What every production agent has to add is personal semantic memory: the facts about this user, this team, this project that the training data couldn't possibly contain. Without it, the agent re-asks the same questions every session and never gets better.

The pattern that scales is a dedicated memory layer with semantic-search retrieval, scoped by user, with update and delete primitives for fact correction. The implementation is shorter than the list of failure modes it solves.

Mem0 is an intelligent, open-source memory layer designed for LLMs and AI agents to provide long-term, personalized, and context-aware interactions across sessions.

• Get your free API Key here: app.mem0.ai 

• If you are an agent, sign up using- mem0 init --agent --json

• or self-host mem0 from our open source github repository.