Memory

The Memory view (sidebar ▸ Data) is your window onto what the platform remembers. Agents write memory as they work; here you read it, search it, and curate it. The layer model behind the view — which kind of fact lives where — is covered in Memory layers; the full operating reference is Memory infrastructure.

The view is tabbed:

One deliberate absence: there is no "add entry" button. Agents author the shared store; your role here is curation — correcting, consolidating, and pruning what they wrote.

Browse the shared store

The Shared tab opens on the most recent live entries. Narrow the list with the facet filters — entry type, domain, tag, and source (which agent or process wrote it) — and switch the sort between recency and type. Superseded entries are hidden by default; an include superseded toggle brings the history back into the list when you want to see how a fact evolved. Both the sort control and the superseded toggle apply to browsing, so they are disabled while a search is active — clear the search to get them back.

Search — three modes

The search box runs in one of three modes:

Two behaviors to rely on:

• Results are relevance-gated. A query with no genuine match returns nothing — the empty state even suggests switching to Keyword for exact names — rather than a page of nearest-but-wrong entries.
• Matches carry a relevance score, so you can judge match strength, not just rank order.

Working without a key

Meaning and hybrid search embed the query, which uses the optional Gemini key you bring. Without one, the view says so plainly and keeps working: browsing, filtering, keyword search, metadata edits, and deletion all need no key.

The one curation action that does need it is editing an entry's text — changing the content re-embeds the entry, so saving that change without a key is refused, and the view tells you exactly that: revert the content to save the metadata alone, or add a key. Add it under Settings ▸ API Keys when you want the semantic modes — the trade-off is laid out in BYO Claude & keys.

Inspect an entry

Click an entry to open it in full: the complete finding, its one-line summary, type, domain, tags, the file references it points at, which agent wrote it and when — and, where the fact has evolved, the supersession chain: the lineage from the original entry to its current replacement, preserved in both directions.

Curate

The detail pane exposes two mutating actions, and they answer different questions:

• Edit an entry when the fact is right but something about it is wrong — a mis-set type or domain, a loose tag, imprecise wording, or a wrong project stamp. The form covers every field including project, so re-filing an entry under the right project is an edit like any other. Same entry, no lineage. Changing the entry's content is the one edit that re-embeds it and therefore needs the Gemini key; every other field saves without one.
• Delete an entry that should never have existed — junk, duplicates, test writes. This is the one hard-remove verb, and it is yours, not the general fleet's.

Superseding — replacing a fact while chaining its history — is normally the agents' move as facts evolve during work; you will mostly see its results as lineage. A shipped routine, memory-hygiene, supports your curation on a schedule: it flags near-duplicate clusters and stale entries and proposes consolidations, but never merges or deletes on its own.

If the Shared tab is dark

The shared store is served by a small local service that Command Center starts and stops for you (Dashboard ▸ Platform Health ▸ Shared Memory, with a Start button and an autostart setting). When it is not running, the Shared tab says so and offers Retry — it does not pretend the store is empty.

An agent session can host the same surface as a hot spare, which is why the tab sometimes comes back on its own. Either way the store itself is a local database file: nothing is lost while the service is down.

The other tabs are unaffected. Auto-memory and Agent read Markdown files straight off disk, so they keep working whether or not the shared service is up.

The Auto-memory tab — the main session's memory

Auto-memory shows the main session's durable memory: the lean MEMORY.md index plus its topic files, as editable Markdown. This is where facts about you and your project accumulate — preferences, stable project facts, pointers. Read it to see what the system believes about you; edit it directly when something is wrong or stale. The index discipline to keep: one line per entry, detail in the topic files.

One thing worth knowing about these particular files: they do not live in your workspace. The agent CLI keeps its per-project memory under your user home, keyed to the project path, and Command Center reads and writes it there through a narrow, separately-validated path. The practical consequence is that copying or moving your workspace folder does not carry auto-memory with it — see Memory layers for the full split.

The Agent tab — the specialists' notebooks

Agent browses each memory-enabled agent's private notebook — the same index-plus-topics shape, holding that agent's accumulated craft: recurring patterns, checklists, anti-patterns. These files do live in your workspace, under .claude/agent-memory/, one folder per agent. They are working files, and reading them is the fastest way to understand why a specialist behaves the way it does. Edit sparingly; the owning agent maintains them.

The Overview tab

Overview is the shared store's dashboard: entry counts by type, domain, and source, the superseded ratio, and the store's size on disk — the quickest read on whether the fleet is writing, and what kind of knowledge is accumulating.

Where to go next

• Memory layers — which layer holds which kind of fact
• Memory infrastructure — entry schema, write discipline, backups and durability
• Cortex — the document-and-graph layer of memory