Introduction
Agent Memory is a multi-tenant, persistent memory service for AI agents — remember, recall, learn and forget across runs over REST, SDKs and MCP.
Agent Memory gives your AI agents a memory that survives the end of a conversation. Instead of re-reading every file and re-learning every decision on each run, an agent stores what matters while it works, recalls it at the start of the next task, and gets better as real outcomes come back.
It is built as a multi-tenant service from the ground up: every memory lives inside a tenant and a workspace, isolation is enforced in the database, and every credential is bound to the agents it may act as.
What you can do with it
- Remember — store decisions, corrections, preferences, approved patterns and references as an agent works.
- Recall — get back a ranked, token-budgeted context block assembled from every memory type, ready to drop into a prompt.
- Learn — consolidate a finished run into durable facts, an episode and reusable procedures; report the run's real outcome so useful memories are reinforced.
- Forget — delete a memory and its derived copies, with an erasure status you can check, and a guard that stops you from silently breaking memories that depend on it.
- Govern — per-memory visibility (private to an agent, per end user, workspace-wide or tenant-wide), a change feed, provenance and "how do you know this?" explanations.
Ways to connect
The same memory contract is exposed on every surface, so behaviour is identical whichever one you pick.
REST API
Node SDK
Python SDK
MCP server
Core concepts at a glance
| Concept | What it is |
|---|---|
| Tenant → Workspace → Application → Run | The scoping hierarchy. A workspace is the shared memory pool; applications carve out app-specific memory inside it; a run groups one task's entries. See Scoping. |
| Session memory | Short-lived, per-run scratch memory (48 hours). See Memory types. |
| Workspace memory | Durable, searchable facts with embeddings, provenance, trust and lifecycle. |
| Episodes | One record per consolidated run: what happened, its outcome and a summary. |
| Procedures | Learned "how-to" patterns distilled from successful runs. |
| Memory blocks | Small, hand-curated text blocks (conventions, persona, project notes) that are always included in context. |
| Consolidation | The end-of-run step that turns session entries into facts, an episode and procedures. See Runs and consolidation. |
| Receipts | Every recall returns a receiptId naming exactly what was delivered, so outcomes and feedback credit the right memories. See Learning loop. |
| Visibility | private, agent, user, workspace (default) or tenant — who may recall a memory. See Identity and visibility. |
How an agent uses memory
The recommended pattern is a loop, not a lookup:
- Start of a task — search memory with the task's key terms before acting.
- During the task — store something the moment it becomes durable: a decision, a correction from the user, a rule that was broken, a pattern the user approved.
- End of the task — consolidate the run so its entries become durable workspace memory.
- When the result is known — report the outcome (build, tests, deploy, user verdict) with the recall's receipt.
Idle runs are consolidated for you
If an agent forgets to consolidate, the platform's background worker consolidates runs that have been idle for a while (30 minutes by default), so learnings are not lost.