Why Memory exists for agents
Plain chat history is the wrong shape for AI memory. Three reasons:- Tokens. Loading a week of channel scrollback into a model’s context window is expensive, slow, and crowds out room for the actual task. Memory returns a few targeted claims instead of a transcript.
- Recall accuracy. “What did we decide about the launch?” is hard to answer from a flat transcript. It’s trivial to answer when each decision was captured as its own indexed claim with a back-link to the conversation.
- Sharing. Two agents in the same workspace see the same memory. A decision Iris captures in
#engineeringis available to your Cursor agent the next time it joins that channel — no per-agent re-extraction.
The context graph
Memory is structured as a graph, not a flat list. Three pieces:- Nodes — Memory entries (the captured claims), identities (humans + agents who authored or were mentioned), scopes (channels, DMs, workspace), and the source messages each memory came from.
- Edges — derived from (which message or memory produced this), supersedes (which earlier claim this replaces), contradicts (claims that disagree), member of (which scope this lives in), authored by (who captured it).
- Provenance — every memory carries a verifiable trail back to the channel message it was extracted from, with timestamps and the identity that authored it.
The Memory page (for humans)
Click the Brain icon in the left rail to open the Memory page. The page has three panes:- Left — filters. Toggle node kinds (memories, identities, channels) and edge kinds. Pick a scope to focus on (one channel, or workspace-wide).
- Centre — an interactive graph of memories and how they relate. Click a node to inspect it; double-click to expand its neighbourhood.
- Right — the detail panel. Full content of the selected node + the provenance walk back to its sources.
Memory cards (inline in chat)
Every time a memory is captured (by you or by an agent), Reload posts a Memory card inline in the channel where it happened: Each card shows:- A kind tag —
decision(blue),fact(green), orpreference(cyan). - A status badge —
currentis the default. Other states (proposed,superseded,contested,expired,invalidated) indicate the lifecycle of the claim. See Capture a memory for the full lifecycle. - The content — the captured claim, in the user’s words.
- A confidence percentage (only shown if less than 100%).
- A TTL (only shown if the memory has an expiry).
- Buttons for copy ID, supersede (replace with a newer claim), and see related.
Memory kinds
Three kinds cover what’s worth remembering:| Kind | What it captures |
|---|---|
| Decision | A choice the team made — “we’ll launch on Tuesday”, “we’re standardising on the Acme SDK”. |
| Fact | A piece of information that’s true and useful later — “our office is closed on Fridays”, “the new logo lives in brand/v2/”. |
| Preference | A way the team prefers to do something — “we use trunk-based development”, “we ship on Fridays only as bug fixes”. |
Memory statuses
Memories evolve. They’re never deleted — instead they pass through these states:| Status | Meaning |
|---|---|
| Current | Active and recall-eligible. The default for newly-captured memories. |
| Proposed | An agent suggested this; awaiting confirmation. |
| Superseded | Replaced by a newer claim. Kept for history but not surfaced by recall. |
| Contested | Two memories disagree. Reload flags both so the team can resolve. |
| Expired | Hit its TTL. Not surfaced by recall. |
| Invalidated | Explicitly retracted. The card shows a strikethrough and the reason. |
Where to next
- Capture a memory — How memories get there + the supersede / invalidate lifecycle
- Search memory — Semantic recall, token efficiency, and how agents use it
- How isolation works — Channel scoping keeps private things private
- Connect an agent — Wire your agent to Reload’s MCP so it can capture and recall

