Memory
Tiered, auditable memory shared across your Teammates — how recall works, what gets recorded, and how to browse it.
A memory system built for the platform
Every Teammate on your account draws on the same cross-conversation memory — something one Teammate learns can inform another. This is a platform capability, not something OpenClaw ships out of the box: it replaces OpenClaw's stock memory plugin entirely, so you get one consistent, auditable memory layer instead of per-agent memory that doesn't talk to anything else.
Three tiers, one memory
Memory moves through three tiers as it ages:
| Tier | What it holds |
|---|---|
| Hot | Raw thoughts and facts as they're captured, indexed for search right away |
| Warm | Session summaries — decisions and action items pulled out of a conversation, with entities (people, projects, tools) auto-linked |
| Cold | Nightly digests and weekly roll-ups, clustering warm-tier summaries into a longer-term record |
You don't manage the tiering yourself — memories move through it automatically as they age and get summarized.
How recall works
When a Teammate recalls something, the platform ranks candidate memories by blending four factors: how well it matches the query semantically, how recent it is, how important it was judged to be, and how often it's been recalled before. The highest-ranked memory wins.
Every recall is audited
Recall isn't a black box. Every time a Teammate pulls something from memory, the platform records a trace: the query, the candidates it considered, which one was selected, and how long it took. You can review these traces in the dashboard.
Contradictions and superseded facts
When a new memory contradicts an existing one, it's marked as superseding the old one rather than silently overwriting it — the older fact is kept, flagged as superseded, so you can still see what used to be true and when it changed.
Browsing memory in the dashboard
The dashboard gives you a memory browser, individual entity pages (a person, project, or tool with everything linked to it in one place), the recall traces described above, and an export option if you want your memory data outside the platform.
Connecting your own MCP client
Beyond the dashboard, you can connect any MCP-capable client — Claude, ChatGPT, Cursor, or something custom — directly to your memory. The server URL is:
https://memory.associatesai.team/mcp
Authentication is OAuth, and every client follows the same shape: give it that URL, and when it connects for the first time your browser opens to sign in with your dashboard account and approve access. There are no API keys to create or paste — access rides on your own login, and disconnecting the client (or revoking the token under API tokens) cuts it off.
Where to put the URL:
- Claude (claude.ai or the desktop app): Settings → Connectors → Add custom connector, paste the URL.
- Claude Code:
claude mcp add --transport http memory https://memory.associatesai.team/mcp - ChatGPT: add it as a custom connector / MCP server in ChatGPT's connector settings (requires a plan that supports custom connectors).
- Cursor and most other clients: add an MCP server entry of type HTTP/remote with the URL — no command, no environment variables.
Once connected, the client gets your team's memory tools:
| Tool | Purpose |
|---|---|
memory_search |
Semantic search across your memory, ranked the same way Teammate recall is |
memory_store |
Write a new memory (visible to you) |
memory_store_company |
Write a memory shared with your whole company — for team decisions and shared facts, never personal or sensitive details |
memory_forget |
Soft-delete a memory — kept for audit, no longer recalled |
memory_entity_search |
Find an entity (person, project, tool) and everything linked to it |
memory_recall_about_entity |
Pull recent memories about a specific entity |
You'll also see a few tools your Teammates use internally (raw message capture, prompt-time recall, session summarization) — they're harmless to call but not built for interactive use.
Read-only API
If you want to read memory data programmatically without a full MCP client, the API exposes it directly:
| Endpoint | Returns |
|---|---|
GET /api/v1/memory |
List memories |
GET /api/v1/memory/{id} |
A single memory |
GET /api/v1/memory/export |
Full export |
GET /api/v1/memory/entities |
List entities |
GET /api/v1/memory/entities/{id} |
A single entity and what's linked to it |
GET /api/v1/memory/recall-traces |
Recall trace history |
These endpoints are read-only — writing memory goes through memory_store via MCP, not the REST API. See API & MCP for how tokens and scopes work.