Three kinds of memory an agent actually needs.
Not all agent memory is the same shape. Borrowing from cognitive-science terminology, most durable agent memory splits into episodic memory (what happened), semantic memory (facts and preferences), and procedural memory (how to do something). Modeling them as distinct record shapes makes recall more precise than one undifferentiated memory blob.
AI agent memory architecture typically divides into episodic memory (records of specific events and interactions), semantic memory (durable facts and preferences independent of any one event), and procedural memory (reusable steps or SOPs for completing a task).
What this guide covers
The practical decision points.
Episodic: what happened
A specific run, conversation, or tool call, tied to a time and context — "the agent summarized Q4 revenue on this date, for this user."
Semantic: what is true
Durable facts and preferences that outlive any single episode — "this customer’s renewal date," "this user prefers email over Slack."
Procedural: how to do it
A reusable sequence of steps or an approved SOP an agent can follow again — "the approved refund-processing checklist."
Architecture sketch
How the three types combine
An episode can produce or update a semantic fact. A procedure can be invoked during an episode. All three are Records that can be queried, filtered, and connected, not separate storage systems.
Implementation example
Model each memory type as a distinct label
Using distinct labels keeps recall precise: searching EPISODE for "what happened" won’t be diluted by FACT or PROCEDURE records, and vice versa.
from rushdb import RushDB
db = RushDB("RUSHDB_API_KEY")
db.records.create(label="EPISODE", data={
"agent_id": "agent-42",
"occurred_at": "2026-06-30T10:00:00Z",
"summary": "Summarized Q4 revenue for the board deck.",
})
db.records.create(label="FACT", data={
"subject": "customer-882",
"key": "renewal_date",
"value": "2026-09-01",
})
db.records.create(label="PROCEDURE", data={
"name": "refund-processing-checklist",
"steps": ["Verify order", "Confirm policy window", "Issue refund", "Log outcome"],
"approved": True,
})Modeling each type as a Record
None of these require a special memory API — they are ordinary RushDB Records with labels that match their role. The distinction is a modeling choice, not a different storage mechanism.
EPISODE Records: timestamped, tied to a specific run or conversation
FACT Records: subject + key + value, optionally with a superseded_by relationship for updates
PROCEDURE Records: named, versioned, with an approved flag before an agent can rely on them
How they connect
An EPISODE can link to the FACT it created or the PROCEDURE it followed. That relationship is what turns "the agent did something" into "the agent did something, following this approved process, which produced this durable fact" — a chain that is queryable and explainable after the fact.
Measuring what a memory system actually stores
Because each memory type is an ordinary Record, analyzing memory usage is a SearchQuery, not a separate feature. Group EPISODE records by agent or day, count active vs. superseded FACT records, or find which PROCEDURE records are used most often — all with select and groupBy over the same labels. RushDB does not ship a built-in memory-scoring or importance-ranking feature; this is a pattern you build with existing query primitives.
Decision table
One memory blob vs typed memory records
The alternative to distinct memory types is storing everything as undifferentiated text and letting semantic search sort it out at recall time. That works until precision matters.
A query for "what should I do" can surface event summaries instead of the actual procedure.
Querying PROCEDURE specifically returns approved steps, not narrative history.
An old episode summary can contradict a newer fact with no clear precedence.
FACT records can be explicitly superseded, so the current value is unambiguous.
Hard to tell whether something is a one-off event or a standing rule.
The label itself tells you: EPISODE is what happened, FACT is what is true, PROCEDURE is how to do it.
One broad semantic search over everything, hoping ranking sorts it out.
Scope search to the relevant label(s) first, then rank by meaning within that scope.
Related RushDB docs
Read the primitives behind the guide.
These docs links are the implementation references for the concepts explained on this page.