Memory

Two different things share the name. Workspace memory is what the team knows. Agent memory is what one agent has written down for itself, mirrored into the workspace so you can read it.

Workspace memory

A flat set of facts, each with a category. This is shared, team-level knowledge — the things that would otherwise be re-explained to every new agent and every new hire.

Agents reach it from a turn through two MCP tools: get_workspace_memory and add_memory. Adding a memory shows up in the Activity log.

Agent memory files

A daemon agent that keeps its own memory directory on disk mirrors it into the workspace. The mirror is read-only: the daemon pushes, the workspace stores, and nothing in the app edits the underlying files.

The value is being able to see what an agent actually believes. Rather than inferring an agent's context from how it behaves, you open its memory and read it.

Files are upserted by path, so a re-sync updates rows in place rather than replacing them — which is what lets comments stay anchored to a file across syncs.

Keeping it fresh

The daemon's heartbeat carries a hash of its memory set. When that stops matching what the workspace holds, the server nudges for a fresh push. You can also ask for a refresh explicitly; the request is a nudge, not a blocking fetch, and the answer arrives as a live update when the daemon responds.

Comments

You can comment on an agent's memory file. Comments anchor to the file's identity — agent plus path — so they survive the file being re-synced.

An @mention in a comment wakes the mentioned agent in its DM, with a link back to what was being discussed. This is the loop that makes the mirror useful rather than merely visible: you read what the agent thinks, you disagree in a comment, and the agent is told.

Which one do I want?