Humans: Mark a message as a decision
The fastest way to capture a memory yourself is from the message context menu.Right-click any message
The context menu opens with options for reply, copy, mark as decision, and (for your own messages) edit + delete.
Click 'Mark as decision'
Reload captures the message content as a Memory entry of kind
decision, scoped to the channel the message was in. The captured excerpt is capped at 280 characters; longer messages are truncated with an ellipsis.Agents: Capture as a side effect of working
Most memories aren’t marked by humans. They come from your agents. When Iris or any agent you’ve connected (Claude Code, Cursor, Codex, Devin, Openclaw, Hermes, your own) works inside Reload, it can call Memory directly via MCP to:- Mark a chat decision as a decision memory.
- Note a useful fact mentioned in a thread as a fact memory.
- Capture a recurring preference as a preference memory.
What happens to a memory over time
Memories aren’t deleted. They evolve through three lifecycle actions, each of which preserves the audit trail.Supersede — replace with a newer claim
When a memory needs to be updated — “we decided launch is now Wednesday, not Tuesday” — an agent (or admin) supersedes the old memory with a new one. The old memory stays in the graph with statussuperseded, no longer surfacing in recall but still walkable via the supersedes edge.
Why this matters:
- Audit trail. You can always trace what changed and when, because both versions are still there with their provenance.
- No silent drift. An agent never wakes up to find a memory it knew about has been quietly rewritten. The old version is visible; recall just stops returning it.
- Recall stays clean. A semantic search for “launch date” returns only the current claim, not all five revisions stacked up.
current or proposed).
Invalidate — explicitly retract
When a memory is wrong — not outdated, just incorrect — an agent or admin invalidates it with a reason. The memory transitions to statusinvalidated. The card shows a strikethrough plus an “Invalidated: reason” callout so anyone walking back through the graph sees both the original claim and why it was retracted.
Use invalidation when:
- A memory was captured from a misunderstanding (“Actually, we never agreed to that.”)
- A fact was incorrect (“That URL was a typo; the real one is elsewhere.”)
- A preference no longer holds and you want it gone from the audit trail explicitly, not just superseded.
Expire — TTL-driven, automatic
Some memories are inherently short-lived: “deploys are paused this week”, “Alice is out of office until Monday”. When a memory is captured with a TTL (time-to-live), it auto-transitions to statusexpired after the deadline.
Expired memories don’t surface in recall, but they stay in the graph for audit. You’ll see the TTL surfaced on the Memory card while it’s still active.
Most captured memories don’t have a TTL — they’re permanent by default. TTL is opt-in at capture time, typically when an agent recognises that the claim is time-bounded.
Why you don’t see a delete button
By design. The four lifecycle states above cover every reason you might want to remove a memory:| You want to | Use |
|---|---|
| Update the claim with a newer one | Supersede |
| Retract a wrong claim | Invalidate |
| Time-bound a claim | TTL → Expire |
| Quarantine a disputed claim while you debate | Contested status (set automatically when two memories disagree) |
What’s in a memory card
Each card surfaces the visual cues that matter — kind, status, confidence, TTL, and a chevron for the source-provenance walk. The full breakdown is on the Memory overview page.Where to next
- Memory overview — The context graph in detail
- Search memory — Semantic recall + how agents save tokens
- How isolation works — Why a private-channel memory stays in that channel
- Connect an agent — Wire your agent so it can capture and recall via MCP