Reference
Memories
Memories are the operational context your agents keep between runs — written automatically as they work, and curated here so they remember the right things.
What memories are
A memory is a short piece of context an agent learned during a run — for example a customer's preference, a recurring instruction, or a fact worth carrying forward. Each memory has a key (a short machine-style label) and content (the text the agent reads back).
Agents write memories themselves as they complete runs, according to each agent version's memory policy. You do not create memories by hand on this page. You browse, correct and prune what the runtime has recorded.
Memories are operational context, not business records. Agents never own your business data — a memory is the agent's working notes, and is safe to edit or delete without losing anything authoritative.
Scopes
Every memory has a scope that decides which agents can read it back:
-
agent: belongs to one agent. Only that agent reads it. -
tenant: shared across all the agents in your organisation.
These are the only two scopes a memory row can hold, and the only two the scope filter offers. Which scopes a given run actually reads is set by that agent version's memory policy, not on this page.
How memories are used in runs
When an agent runs, the relevant memories are injected into its context before it reasons, following the read scopes in its version's memory policy. Memories therefore shape behaviour silently. A wrong or stale memory can steer an agent in future runs, which is why curating them matters.
Each row shows when it was written and links to its source run, so you can trace any memory back to the run that created it. An Expires column shows when the retention policy will prune it (or Never for memories with no expiry).
Curating memories
Three actions are available on each memory:
- Pin / unpin: a pinned memory is exempt from retention pruning, so it is kept indefinitely. Unpinning returns it to the normal retention policy.
- Edit: correct the content. The key, scope and provenance are kept exactly as the runtime recorded them and cannot be changed.
- Delete: remove a memory the agent should no longer see in future runs.
Use the search box to match across keys and content, and the scope, agent and Pinned only filters to narrow the list. Long content can be expanded with Show more.
Deletes are soft and reversible during the retention window, so a memory removed in error is not lost immediately.
Governance and access
The whole Memories surface (browsing, editing, pinning and
deleting) is gated by the
memories.manage permission, held by the
owner, admin and
operator roles. Memories are scoped to your
organisation, so another tenant's memory is simply not
found.
Editing or pinning a memory is a curation action, not an agent action: it does not pass through the approval gate. The runtime writes memories through its own memory policy, never through this page.