What Is AI Agent Memory? Working, Episodic, Semantic and Procedural Memory

Useful memory includes short-lived task state, events, facts, relationships and reusable procedures.

Working thesis: Agent memory is an operational system for retaining and transforming state, not just a vector store of old chats.

Four useful types of agent memory

These labels are useful design categories, not a guarantee that every memory provider implements them as separate stores. The important question is what can be retained, who can see it and how it becomes eligible for future context.

Why this matters for AI agents

An AI agent does not work from organizational reality directly. It works from the instructions, tools, memory, retrieved material and task state that reach its context window. That makes context selection part of the system architecture rather than a cosmetic prompt decision.

For one-off assistance, an imperfect context set may produce an inconvenient answer. For long-running or tool-using agents, the same weakness can persist across steps, be written into memory, propagate to another agent, or influence an external action. The engineering target is therefore not maximum information. It is sufficient, current and applicable information for the task at hand.

This is also why raw retrieval metrics tell only part of the story. A system can retrieve text that is semantically relevant yet still be wrong for the current project, user, environment or point in time. Conversely, an important constraint may have low lexical similarity to the user’s request but still be essential to safe execution.

A concrete example

A support agent may need working memory for the current ticket, episodic memory for prior escalations, semantic memory for configuration and procedural memory for the approved escalation process.

A practical architecture

1. Working. Keep the stage contract explicit so inputs, outputs and metadata remain inspectable.
2. Episodic. Keep the stage contract explicit so inputs, outputs and metadata remain inspectable.
3. Semantic. Keep the stage contract explicit so inputs, outputs and metadata remain inspectable.
4. Procedural. Keep the stage contract explicit so inputs, outputs and metadata remain inspectable.
5. Governance. Apply ownership, scope, lifecycle and approval before this state can be reused.

Design principles

• Attach retention policies to memory classes.

• Use provenance for agent-created memories.

• Treat shared memory as a governance problem.

• Keep provenance, lifecycle state and permissions attached as context moves across tools and handoffs.

• Evaluate context quality against the task outcome, not only similarity scores or token counts.

How AuzzurA approaches this

AuzzurA treats memory as one input to a broader context workflow. Memory can preserve experience, while people still need a clear path to review, scope and reuse what becomes trusted team knowledge.

Questions to ask before implementing this pattern

• What exactly are we persisting: raw source, memory, candidate knowledge or approved knowledge?
• Who owns an item, and who can change its status?
• How is scope represented across organization, team, project, environment, user, agent and task?
• How do we know when an item is stale, superseded or in conflict?
• Can we reconstruct which context reached a participant during a specific run?
• What learning from the run should return to shared context, and what review is required before reuse?

These questions tend to outlast individual model, vector-store and graph-engine choices because they define the organizational semantics around those components.

Sources and further reading

• Rethinking Memory in AI
• IBM — What Is AI Agent Memory?
• LangChain — How to Give Your Agent Memory
• AIM: A Privacy-Aware Interoperable Memory Framework for Multi-Agent Multi-User LLM Systems