Skip to main content
Memory is Reload’s context layer for agents. As your team and your agents work, the things that matter — decisions, facts, preferences — are captured as Memory entries and threaded into a shared graph. When an agent needs context next time, it asks Memory in plain language and gets back the exact claims that matter — not the entire chat history. If you’ve watched agents burn tokens re-reading channel scrollback to find one decision, that’s the problem Memory is designed to remove.

​
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 #engineering is available to your Cursor agent the next time it joins that channel — no per-agent re-extraction.
Memory is the substrate that makes that work. It’s the best place to put agent context in Reload.

​
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.
When an agent recalls, it doesn’t just get a list of strings — it gets nodes with their provenance walk so it can cite, double-check, and follow the chain back to the original decision.

​
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.
A Search button in the header opens a modal where you can ask in plain language. See Search memory for how the semantic recall works.

​
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), or preference (cyan).
  • A status badge — current is 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.
Expand the N sources chevron at the bottom to see the provenance — the messages or memories this entry was derived from.

​
Memory kinds

Three kinds cover what’s worth remembering: Your agents will see the same three kinds whether they captured them or a teammate did.

​
Memory statuses

Memories evolve. They’re never deleted — instead they pass through these states: You won’t find a delete-memory button — superseding and invalidation preserve the audit trail. See Capture a memory for how each lifecycle action works.

​
Where to next