An agent session ends, and its conversation ends with it. The design system keeps the rules and the pages keep the results, but the reasoning in between is lost: what was decided, what was tried and rejected, what is still open. Memory is our attempt to keep that part on the site, so the next session can read it before it starts.
Memory is a feature. It is on by default and listed as Experimental on the Features screen in the Delta dashboard. We consider it early work, and we are still learning how agents use it.
What goes in
Memory is a list of short entries. Each one has a date and an author, and can be marked open. An open entry is a loose end: a question waiting for your answer, a step not finished, a redirect still to set. It stays in the open list until it is closed, and a closing note can be attached.
On this site, the entries so far record things like a rejected illustration treatment and why it was rejected, a redirect that still needs a server rule, and which page got which drawing. They were written by the agent during build sessions, and we have found them useful when picking the work up again.
Memory is not the design notes. The notes in the design system hold standing rules for how the site looks and behaves. Memory holds the state of the work: decisions, rejected options, and loose ends.
How the agent uses it
At the start of a session, the agent’s orientation includes every open entry and the five most recent entries. Older entries are available on request.
Memory has two logging modes. In Automatic, the default, the memory-logging rule asks the agent to record what a session decided before it reports the work as done, and to mark unresolved items open. In By request, the agent writes an entry only when you ask for one. To be certain that a specific decision is logged, ask for it in either mode.
“Log that we rejected the pixel texture on the pricing band, and why.”
“What is still open on this site?”
“Close the redirect item. It is done.”
The agent edits an entry, deletes one, or clears the whole log only when you ask it to.
Where it lives
Entries are stored in their own table in the site database, apart from posts and apart from the design system. Memory entries are not included in snapshots, and restoring a snapshot does not change them. There is no limit on the number of entries.
Anyone who can edit posts can read and write Memory through a connected agent. Memory also has its own screen in the Delta dashboard: open Features and select Configure on the Memory card. The screen sets the logging mode. It does not list entries. To read them without an agent, open the Front panel on any page of the live site and choose the Memory tab: it shows what the agent decided on this site and what is still open.
Known limits
Every open entry travels with the agent’s orientation in full, so a long open list costs the agent context on every session. Short entries, one decision each, closed when done, keep that light. There is no export yet, and the Front panel shows the log but does not edit it. We expect both to change as we learn what people need from it.
For developers
The abilities are delta/append-memory, delta/list-memory, delta/close-memory, delta/update-memory, delta/delete-memory, and delta/clear-memory, in the category delta-memory. The feature switch gates all six. Update, delete, and clear are marked requiresConfirmation. The capability is edit_posts.
delta/get-design-context carries a digest under memory: open, recent (five), total, and updatedAt. delta/list-memory pages the full history newest first, and always returns the open entries beside the page. One entry holds up to 100,000 characters. The table is {prefix}21press_delta_memory.