Project memory
The notes your agent keeps between sessions, the seven facets memory is filed under, what belongs in it, and how to keep it worth reading.
Updated October 20, 2026
Memory is the project's notebook: durable facts that survive the end of a chat window. Your agent writes and reads it, and the Memory tab shows you everything in it.
The seven facets
Every entry is filed under one, which is what makes memory retrievable rather than a pile of notes.
| Facet | What goes in it |
|---|---|
brand_voice | Voice decisions made in conversation, as distinct from the voice fields in project context. |
domain | Facts about the site itself: platform, constraints, who can publish. |
keyword_target | Confirmed target terms, with the reasoning. |
topical_map | Choices about what the site should cover and in what structure. |
decision | A strategic call and why: what is in scope, what is deliberately not being touched. |
work_history | What was done and what happened. |
deliverable_pointer | A thing produced elsewhere, with its type, target and status, plus a URL to where it lives. |
What belongs in memory
Durable context a future session would otherwise have to be told again. The test is whether it will still be true next month.
A decision, with its reason, is the highest-value entry there is. "We are not writing comparison pages this quarter because legal has to review competitor claims" saves an argument every time someone opens the project.
What does not
Anything the product already records. Run data, scores, prompt lists and optimization logs live in the project. Copying them into memory produces a second version that goes stale.
Whole documents. Store the pointer, never the document. A brief, a draft or a template belongs in project files.
Secrets. Model keys live in the encrypted key store. Nothing credential-shaped should be pasted into a note.
Anything that will be false next week. That is a chat message, not a memory.
Reinforcement, not duplication
Storing the same fact again reinforces the existing entry and bumps how often it has been seen, rather than adding a near-duplicate. An entry seen many times is one the project keeps running into, which is a reasonable proxy for how load-bearing it is.
Keeping it useful
Memory rots like any other note store. Two habits keep it readable:
- One fact per entry. A transcript pasted into one note is not retrievable.
- Delete rather than correct. When something stops being true, remove it. A correction sitting next to the thing it corrects means the next session reads both and has to guess.
The Memory tab is editable, so pruning is a normal part of running a project rather than something only the agent does.
Read the Memory tab before a client call. It is the shortest honest summary of what has been decided and done on the project, and it is already written.
Questions about project memory
- Can one project read another's memory?
- No. Memory is scoped to a project, so a client's context cannot reach another client even on the same account.
- What happens if the agent stores the same fact twice?
- It reinforces the existing entry rather than creating a duplicate, and the entry carries how often it has been seen.
- Should I put a draft in memory?
- No. Memory holds the pointer to a deliverable, never the document. A whole document belongs in project files.