Manage memories

A memory is a durable note your agents can draw on — a convention, a gotcha, a decision worth remembering. Memories are scoped, and the workspace and project ones travel with your synced repository so they are versioned alongside your workflows and scripts.

The Memory page lives under Intelligence → Memory. Its List view holds your memories and one editor both creates and edits them; Governance sets the per-scope review policy, and each memory’s versions and snapshots live in its detail drawer. Proposed memories are decided elsewhere — in the one decision queue at Inbox → Decisions (see Work the inbox).

Write a memory

1. Open Intelligence → Memory.
2. Click New memory. An editor opens with a full Markdown editor — write the note with headings, lists and code as you would any Markdown.
3. Choose the memory’s scope:
   • Workspace — shared across the workspace.
   • Project — attached to one project (pick the project below).
   • Personal — yours alone.
4. Choose the memory’s kind (semantic, episodic, procedural, profile preference or scratchpad).
5. Click Save.

Edit a memory in place

The same editor edits an existing memory — there is no separate edit form.

1. On the List tab, click a memory to open its detail drawer.
2. Click Edit. The editor reopens, seeded with that memory’s text, scope and kind.
3. Change the text or fields and click Save. The change is written back to the same memory in place and a new version is recorded.

Note

Editing the body never changes the memory’s pinned or archived state — Pin and Archive stay separate actions in the detail drawer.

Review proposed memories

Your agents and the workspace’s internal LLM can propose memories — a new note, or an edit to an existing one. Proposals do not change anything on their own; they wait for a person to decide. They are decided in the Inbox, in the one decision queue that also carries agent approvals, skill proposals and governor proposals — not on the memory page itself.

1. Open Inbox → Decisions. Each pending memory item shows its action, source, proposed scope and kind, and the reason for the proposal.
2. When a proposal edits an existing memory, the item shows a side-by-side Current vs Proposed diff so you can see exactly what changes.
3. Click Approve to apply the proposal (it creates or updates the memory) or Reject to discard it.

Note

The Generate outcome candidates button mines your recent task outcomes into fresh review items, so you can curate memories from work that already happened instead of writing them from scratch. The new items land in this same inbox for you to approve or reject.

Review closeout memories

When a task finishes, SupaCloud proposes a short closeout memory — a pointer at the work it just did. These land in Inbox → Decisions as legible cards. Nothing is written to durable memory until you approve.

1. Open Inbox → Decisions.
2. Turn on Show closeouts only to filter the queue to closeout proposals (newest completion first). Each carries a Closeout: Standard badge.
3. A card shows the task’s Completion facts — its pull request, branch and cost — and the proposed memory text.
4. Approve to file the closeout memory (and, when the task is linked to an issue, close or transition that issue in the same step), or Reject to discard it.

Open any closeout memory’s detail drawer to see two extra panels: Completion facts (branch / PR / cost) and Context usage (which tasks saw this memory, linking back to each task).

Govern memories per scope

A workspace owner or admin sets, per scope, how new memories are governed in the Governance view of Intelligence → Memory:

• On new memory — Require review (the safe default: proposals queue for a human) or Auto-publish (new memories of that scope go live immediately).
• Retention (days) — how long memories of that scope are kept before they may be archived; 0 keeps them forever.

Set this independently for Workspace, Project and Personal scopes.

When a scope requires review, every new memory of that scope is queued for a decision instead of going live — whether you write it in the editor or an agent proposes it. Editing a live memory of a require-review scope likewise queues the change; the live memory is untouched until a person approves it.

Inspect versions and snapshots

Open a memory’s detail drawer (click it on the List tab) to see everything about a single memory in one place:

• Its scope, kind, source, importance, salience and when it was last used and updated.
• Its links to related memories, entities and runs.
• Its version history — every saved revision of the memory, newest first.
• A snapshots inspector (expandable) showing the context snapshots a past task or council run selected — useful to understand why a memory was used.

Pin, archive and edit the memory from the drawer’s footer.

How memories travel with repo-sync

Workspace and project memories are part of repo-sync: they serialise into the synced repository (under memories/), alongside your workflows, scripts, resources and apps, and sync in both directions like any other repo-managed item. A memory edited in the repository flows back into SupaCloud on pull, and one written in the UI is written out on push.

Note

Personal memories are never serialised to the repository — they stay private to you. Only workspace- and project-scoped memories are shared and synced.

See also

• Runs and tasks
• Approve or reject agent actions