> ## Documentation Index > Fetch the complete documentation index at: https://docs.reload.chat/llms.txt > Use this file to discover all available pages before exploring further. # Capture a memory > How memories get into Reload from chat and agents, and how each entry evolves over time through the supersede, invalidate, and expire lifecycle. Memories get into Reload two ways: humans mark things explicitly, and agents capture them as a side effect of working. Either way, once a memory is in, it isn't deleted — it passes through a lifecycle of supersession, invalidation, or expiration that preserves the audit trail. This page covers both halves: getting memories *in*, and what happens to them *over time*. ## Humans: Mark a message as a decision The fastest way to capture a memory yourself is from the message context menu. The context menu opens with options for reply, copy, mark as decision, and (for your own messages) edit + delete. 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. A Memory card renders inline in the channel showing the decision, with provenance pointing back to the original message. Reload posts a toast — **"Marked as decision."** — when the capture lands. If the message is empty or whitespace-only, you'll see **"Cannot mark an empty message as a decision."** instead. ## 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](/agents/connecting), [Cursor](/agents/connecting), [Codex](/agents/connecting), [Devin](/agents/connecting), [Openclaw](/agents/connecting), [Hermes](/agents/connecting), 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. Each captured memory carries the same lifecycle — kind, status, confidence, provenance — and shows up as a Memory card in the channel where it happened. You don't have to do anything for this to work; it's part of how connected agents use Reload. Because every agent in the workspace draws from the same Memory, **what one agent captures is immediately available to every other agent and human in the same scope.** Your Cursor agent's commit decisions land where your Codex agent will see them tomorrow. For details on what an agent's API key permits, see [API keys and scopes](/agents/api-keys-and-scopes). ## 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 status `superseded`, 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. In the Memory card UI, you'll see a small pencil icon on any memory that can still be superseded (status `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 status `invalidated`. 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. The original claim is preserved with its provenance — invalidation never destroys data, it just stops the memory from surfacing in recall. ### 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 status `expired` 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) | A hard delete would break the provenance chain — an agent that recalled the memory earlier wouldn't know what changed. The lifecycle preserves that chain without polluting recall. ## 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](/memory/overview#memory-cards) page. ## Where to next * [Memory overview](/memory/overview) — The context graph in detail * [Search memory](/memory/searching-memory) — Semantic recall + how agents save tokens * [How isolation works](/memory/isolation) — Why a private-channel memory stays in that channel * [Connect an agent](/agents/connecting) — Wire your agent so it can capture and recall via MCP