Memories

A memory is something your team has settled or learned that should outlast the conversation it came from: a decision, a convention, a lesson, a known risk. Once it's recorded, Dev and your agents can find it in every later session, so nobody has to re-explain why things are the way they are, and an agent starting fresh works to the same rules as the person who made the call.

You'll find a project's memories under Knowledge → Memories in the project sidebar.

What a memory is

A memory is a short, named record with a title, an optional one-line summary and the full text. Each one has a type, a state, tags, the person or agent who recorded it, and a link to the session it came from.

Memories are for things that stay true: what you decided and why, how you do things here, what to watch out for. Work that still has to happen belongs on a task instead, an open question goes on Still to Discuss, a goal belongs in Goals, and longer documents such as plans, guides, decision records and reference material belong in artifacts (see Documents and artifacts).

Every memory has one of four types:

A decision about how the system is built is a decision; tag it architecture to keep those easy to find.

Memory states: In discussion, Decided, Superseded, Retracted

Each memory shows its state on the Memories page:

• In discussion: recorded, but the team hasn't committed to it yet. It remains open for discussion.
• Decided: the team has committed, and the project treats it as settled.
• Superseded: a newer version has replaced it. The card links to the version that replaced it, and the new version links back.
• Retracted: withdrawn because it was wrong or has stopped applying. It stays in the memory's history, but Dev and your agents don't use it to answer questions.

Superseded and retracted memories are hidden by default. Turn on Superseded & retracted on the Memories page to see them.

How memories get recorded

There is no create button on the Memories page. Memories are recorded while the work is happening:

• Dev proposes them in a session. When the conversation settles something worth keeping, Dev offers to record it as a memory and writes it when you agree, or straight away if you ask it to.
• Your agents record them. Your connected Pi, Claude Code or Antigravity CLI can record a memory when it learns something durable about the project, such as a convention it was told to follow.
• Automations propose them. A memory created during an automation waits in Review for a Maintainer to accept. Reviewed Contributors also propose new memories rather than adding them directly.

Find a memory on the Memories page

The Memories page lists the project's memories, newest first. To narrow it down:

• Search memories… matches titles and text.
• The type menu (All types) shows one type only.
• The sort menu switches between newest and oldest first.
• Superseded & retracted also shows memories that aren't current.
• The signal menu (Any signal) shows only memories DevSpec has flagged: Flagged only or Possibly stale.
• Click a tag on any card to show only memories with that tag. Clear filters resets everything.

Each card shows the type, state, version (for example v2), who recorded it and when, the title and summary, and its tags. Source session opens the conversation it came from, and Replaced v1 or Superseded by newer version takes you along its history. A Change proposed chip means someone has asked for it to change and the change has not yet been accepted.

If DevSpec has flagged a memory, the question appears on the card above the summary, with the reason. You can answer it there, or work through all open questions on the Review page.

Dev can search memories for you too. Ask it what the team decided about something.

Open, edit and correct a memory

Click a card to open the memory viewer. It shows the full text, tags, who recorded it and where, and Show history, which lists every version and change with who made it.

From the viewer you can:

• Edit: change the Title, Summary or Text, then press Review changes to see exactly what will change. Add an optional note under Why the change?, then Save as a new version. The earlier wording stays in the memory's history. If someone changed the memory after you opened it, nothing is saved and you're asked to load the latest version first.
• Mark decided: move a memory that's In discussion to Decided.
• Discuss: open a session about the memory. The person who recorded it is added and notified; you can invite Dev or an agent into the conversation when you need help.
• Retract: withdraw the memory. DevSpec asks you to confirm with Retract it.

Discuss and Retract are also on each card on the Memories page.

To replace a memory with a new version that says something different, ask Dev in a session or ask your agent. The old one becomes Superseded and links to its replacement.

Who can change memories

Anyone on the project can read memories, search them and press Discuss. Contributors and Maintainers can add memories directly; Reviewed Contributors propose them for a Maintainer to accept. Viewers cannot change them.

Editing depends on whose knowledge it is. Contributors can edit their own and other Contributors' records directly. An edit to a Maintainer's decision waits as a proposed version, alongside the unchanged current text. Descriptive records such as insights and risks can be corrected without treating them as decisions to overrule.

Removing someone else's decision, or work that would undo it, needs the appropriate OK. For a Contributor's decision, that comes from its owner or a Maintainer. For a Maintainer's decision, it comes from its owner or the project lead. Editing a decision does not make you its owner.

A ruling that a flagged record is Still accurate applies directly for a Maintainer; Contributors and Reviewed Contributors propose that ruling. See Review for how to give an answer and Organizations, members and roles for project roles.

Protect a decision you want the project to follow

Decisions and conventions that someone asked for, or adopted, guide later work. If new work would undo one, the question appears with the decision and in Review, showing whose OK is needed.

A decision an agent recorded without anyone asking is background knowledge until a person adopts it. Adopt as my decision makes it your decision without changing who originally recorded it. Use it when you have read the record and want the project to follow it.

A record can also say Decided, not yet implemented, with a link to the work that will deliver it. That distinguishes what the team chose from what the product already does.

Link the explanation without repeating it

Reads together with connects a memory to another memory or an artifact that helps explain it. Ask Dev or your agent to link the records and give a reason. Both records show that reason and a link to the other, so a short decision can stay short while its full guide or background remains easy to find.

If two records actually describe the same outcome, ask Dev or your agent to resolve them as duplicates instead. Preserve useful detail in the record you keep; the duplicate is retired with its history intact. See Review.

How Dev and your agents use memories

Dev receives relevant project context and searches for more when it needs it. It reads the memories that bear on the question so its answers follow what your team decided. Your agents can search memories too, and look up the project's decisions and conventions before they change code.

These searches return current memories. Superseded and retracted memories are left out unless someone asks for a memory's history, so an old decision doesn't creep back into new work.

What memories cost

Browsing and opening memories is free. Searches are charged as Running your project. When Dev records a memory for you, that's part of Dev's reply, which is charged like any other.

DevSpec also checks your descriptive memories (insights and risks) when related work is implemented, to spot ones that the shipped change may have made out of date. It checks decisions and conventions an agent recorded on its own the same way, until someone adopts them; one a person asked for or adopted is never flagged. These checks are background work charged to your organization's balance, shown on your transactions as Running your project. See Review for what they raise, and Billing, usage and limits for how charges work.