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 has four tabs:

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.

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: keyword search, browsing, filtering, and every curation action need no key at all. Add the key 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

Three verbs, three intents:

• Edit an entry in place when the fact is right but a field is wrong — a mis-set type or domain, a loose tag, imprecise wording. Same entry, no lineage.
• 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.
• Re-stamp an entry's project when it was filed under the wrong one.

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.

The Auto tab — the main session's memory

Auto 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.

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 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