Semantic Memory in AI Agents
Semantic memory is an agent's store of facts about the world. How it differs from episodic memory, why contradiction handling is the hard part, and how to implement supersession properly.
Semantic memory is an AI agent's store of facts about the world, held independently of when or how the agent learned them. The client is incorporated in Delaware. The user prefers TypeScript. The API rate limit is 1,000 requests per minute. These are claims about how things are, not records of things that happened.
The term comes from cognitive psychology, where Tulving distinguished semantic memory from episodic memory in the early 1970s. In AI it entered common use through the CoALA framework, which names semantic memory as one of three long-term memory types available to a language agent, alongside episodic and procedural.
Semantic versus episodic memory
The cleanest test is whether the entry survives losing its timestamp.
| Semantic | Episodic | |
|---|---|---|
| Content | The migration requires Postgres 15+ | The migration failed on Tuesday |
| Claims | How the world is | What happened |
| Timestamp | Metadata | Part of the meaning |
| When outdated | Should be superseded | Should decay |
| Volume growth | Bounded by domain | Unbounded by usage |
Strip the date off "the migration requires Postgres 15+" and it still means what it meant. Strip the date off "the migration failed" and you have lost the point.
That difference determines the correct handling, and it is where most implementations go wrong. Semantic facts should be replaced when better information arrives, with the old value retained so you can explain why an answer changed. Episodic events should fade unless something makes them durable. Systems that store both in one undifferentiated vector store apply one policy to both and get one of them wrong.
Why contradiction handling is the hard part
Storing facts is easy. Reconciling them is not.
Write "the client is based in London" on Monday. Write "the client relocated to Dubai" on Friday. Query on Saturday. What comes back?
A naive vector store returns both, ranked by similarity to the query, and similarity has no opinion about recency. Your agent then produces a confident answer that is either right or wrong depending on embedding geometry. This is the most common failure in production memory systems and it does not show up in demos, because demos do not run long enough to accumulate contradictions.
Handling it properly means three things:
Detection. Recognising that a new fact addresses the same subject and predicate as an existing one. Harder than string matching, because "based in London" and "relocated to Dubai" share no keywords.
Supersession. Marking the old fact as replaced rather than deleting it, with a pointer to what replaced it. Deletion loses your ability to answer "what did the system believe last month", which auditors ask about.
Provenance. Recording where each fact came from, so a human can adjudicate when detection is ambiguous. Automated reconciliation will get some calls wrong. The requirement is that a person can see why.
A useful stress test for any memory vendor: write two contradicting facts, query, and ask them to explain the result. The answer tells you more than any benchmark.
Implementation approaches
Text with metadata. Facts as strings with subject, predicate, source, timestamp, and supersession pointer. Simple, auditable, requires you to build detection.
Embeddings with structured fields. Vector search for retrieval, structured metadata for reconciliation. The common production pattern. Retrieval is fuzzy; conflict resolution is not.
Knowledge graph. Facts as typed edges between entities. Contradiction detection becomes a structural question rather than a semantic one, which is genuinely better. The cost is extraction: getting reliable triples out of conversational text is its own hard problem.
Most systems end up hybrid, and that is fine. What matters is that reconciliation runs on structure rather than on similarity scores.
Retrieval strategy
Semantic memory retrieval is more forgiving than episodic, because relevance to the query is usually the right selection criterion. Similarity search works reasonably well here in a way it does not for episodes.
Two adjustments worth making. Filter out superseded facts before ranking rather than after, or a stale value will occasionally outrank its replacement. And retrieve fewer than you think you need: ten facts in a prompt where three would do costs tokens, adds latency, and gives the model more opportunity to pick the wrong one.
Related reading
- What is an AI memory layer?
- Episodic memory in AI agents
- Procedural memory in AI agents
- CoALA explained
OctaMem implements semantic memory as a distinct layer with supersession and provenance rather than as tagged entries in a shared store. Docs
Frequently asked questions
What is semantic memory in AI?
An agent's store of facts about the world, held independently of when they were learned.
What is the difference between semantic and episodic memory in AI?
Semantic memory holds facts; episodic memory holds specific events the agent participated in. Facts should be superseded when they change. Events should decay unless consolidated.
Is semantic memory the same as a vector database?
No. A vector database is a storage and search primitive. Semantic memory is a category of content with specific requirements around supersession and provenance that a vector database does not provide on its own.
Is RAG semantic memory?
Not quite. RAG retrieves from a human-authored corpus on a release cycle. Semantic memory accumulates from interaction and revises continuously.
How do you handle facts that contradict?
Detect that they address the same subject, supersede the older one while retaining it, and record provenance so a human can adjudicate.