“Give the agent memory” sounds like one feature. It is closer to saying “give the application storage.” Storage for what—and how will it be used?
An agent may need to remember a fact, a past event, a reusable method, or the active state of the task in front of it. Those are different jobs. Treating all of them as interchangeable chunks in one vector database makes retrieval noisy and behavior unpredictable.
A useful model separates AI memory into four broad types: working, semantic, episodic, and procedural memory.
The four types at a glance
| Memory type | What it contains | Example |
|---|---|---|
| Working | Information needed for the current task | The file being edited and the current acceptance criteria |
| Semantic | Facts and relationships | The billing service uses PostgreSQL |
| Episodic | Events and outcomes | Last Tuesday’s migration failed because a lock exceeded the timeout |
| Procedural | Reusable ways of doing something | The team’s release verification checklist |
The categories overlap in real systems. Their value is not perfect classification. Their value is forcing us to ask what a memory means and how it should be retrieved.
Working memory: what matters right now
Working memory is the agent’s active scratch space. It includes the current prompt, recent messages, tool results, open files, and intermediate state needed to finish the task.
It is fast and immediately available, but temporary. When a context window fills up or the session ends, working memory disappears unless something deliberately promotes its useful parts into longer-term storage.
A larger context window increases working capacity. It does not create durable memory. If the agent can read 200,000 tokens today but none of the important conclusions survive until tomorrow, it still starts the next session without continuity.
Semantic memory: what is true
Semantic memory stores facts, concepts, and relationships without requiring the original event that taught them.
Examples include:
- The production region is
us-east-2 - Priya owns the identity service
- The mobile app uses the public v2 API
- The team prefers TypeScript for new services
Semantic memory is especially valuable when exact entities matter. A vector search may find text that resembles “production environment,” but structured relationships make questions such as “Which region hosts this service?” more reliable.
This is one reason a memory layer can benefit from both semantic search and a knowledge graph. Vector retrieval finds conceptually related context; graph relationships help locate precise facts. We explore that distinction in Vector Search vs. Knowledge Graph for AI Memory.
Semantic memory should be correctable. Facts change. People move teams, URLs are replaced, and a preferred framework becomes legacy. A useful system needs a way to update or supersede an old fact rather than returning every version as if they were equally true.
Episodic memory: what happened
Episodic memory preserves events with context: what happened, when, under which conditions, and with what result.
Examples include:
- A production deploy failed after a schema migration timed out
- The team evaluated two queue providers and rejected one because of regional availability
- An OAuth change caused existing sessions to fail during staging
- A customer reported a bug that was traced to string coercion
The event matters because it carries evidence and causality. “We use provider A” is semantic. “We tested provider B, saw a 14-minute recovery delay, and chose provider A” is episodic.
Agents need episodic memory to avoid repeating failed approaches and to answer “why” questions. It also provides the raw experience from which better facts and procedures can be derived.
But raw transcripts make poor episodic memory. A useful episode should identify the situation, decision, outcome, and relevant entities—not simply archive thousands of tokens of conversation.
Procedural memory: how we do it
Procedural memory contains repeatable methods, practices, and skills.
For a software team, that might include:
- How to cut a production release
- How to investigate an authentication incident
- How to write an architecture decision record
- How to validate a database migration
- How to hand off unfinished work
Procedural memory differs from a one-time episode. An incident may teach the team that every billing deploy needs a reconciliation check. The incident is episodic; the new deploy checklist is procedural.
Some procedures belong in version-controlled documentation or automation rather than AI memory. If a step must happen every time, encode it in a pipeline, test, or runbook. Memory is most useful for retrieving the right procedure and explaining why it exists—not replacing enforcement.
One project, four kinds of memory
Imagine an agent helping migrate an API from API keys to OAuth.
Its working memory contains the current code, requested change, and test output.
Its semantic memory says the service uses OAuth 2.1, the callback route belongs to the identity API, and a particular team owns the integration.
Its episodic memory recalls that a previous rollout broke existing sessions because token validation changed before the clients were migrated.
Its procedural memory supplies the team’s safe rollout pattern: feature flag, backward-compatible validation, staging proof, canary, then production.
The answer becomes useful because the agent retrieves more than text that sounds similar. It retrieves the right kinds of context for the decision.
How memories move between types
Strong memory systems do not merely accumulate records. They consolidate them.
An episode produces a fact:
The migration failed because the table was locked.
Repeated episodes reveal a pattern:
Large migrations regularly exceed the deployment lock timeout.
The pattern produces a procedure:
Run large migrations separately, monitor locks, and verify rollback before deploying application code.
That progression—from experience to knowledge to practice—is how an agent becomes more useful over time. Without consolidation, it simply becomes better at searching an ever-growing archive.
What should be persistent?
Not every item deserves long-term storage.
Persist information when it is likely to affect future work:
- A decision with consequences
- A stable fact or relationship
- A failure worth avoiding
- A reusable process
- A preference that changes how work should be done
Keep transient details in working memory when they matter only to the current turn. Saving every tool output, acknowledgement, and abandoned thought increases cost and reduces retrieval quality.
The companion question—what to retain, update, or delete—is covered in What Should an AI Remember—and What Should It Forget?.
Designing retrieval around memory type
Different questions imply different retrieval strategies.
- “Who owns the identity service?” favors structured factual lookup.
- “What happened during the failed rollout?” favors episodic search with time and project context.
- “How do we deploy this safely?” favors a trusted current procedure.
- “What file am I changing?” belongs in active working context.
A single similarity score cannot express all of those needs. Useful retrieval considers entities, recency, ownership, memory type, and whether newer information supersedes older information.
That is the difference between storing memories and operating a memory system.
Give your agents more than an archive
Persistent AI memory works when facts, experiences, and methods can be recalled in the situations where each is useful. Start your 14-day Nexus-Catalyst trial to give connected AI tools a shared, retrievable history.