Managed Agents API requests require the
managed-agents-2026-04-01 beta header, except memory store endpoints, which use agent-memory-2026-07-22 instead. The SDK sets the correct beta header automatically. See Beta headers.Don’t combine
agent-memory-2026-07-22 with managed-agents-2026-04-01 on a memory store request: sending both returns a 400 error. If your code sets beta headers explicitly, replace managed-agents-2026-04-01 with agent-memory-2026-07-22 on memory store calls rather than adding a second value. Session endpoints, including attaching a memory store to a session, still use managed-agents-2026-04-01.On July 22, 2026, the managed-agents-2026-04-01 header adopts the same list behavior on GET /v1/memory_stores/{memory_store_id}/memories; sending agent-memory-2026-07-22 opts you into that behavior now. Page cursors from requests made without the header aren’t valid with it, so restart from the first page.Overview
A memory store is a workspace-scoped collection of text documents for agents. When you attach a store to a session, it is mounted as a directory inside the session’s sandbox. The agent reads and writes it with the same file tools it uses for the rest of the filesystem, and a note describing each mount is automatically added to the system prompt, telling the agent where to look. The agent toolset is required for these interactions; make sure to enable it during agent creation. Each memory in a store is addressed by a path and can be read and edited directly through the API or the OMA Console, allowing for tuning, importing, and exporting. Every change to a memory creates an immutable memory version, giving you an audit trail and point-in-time recovery for everything the agent writes.Create a memory store
Give the store aname and a description. The description is passed to the agent, telling it what the store contains.
id (memstore_...) is what you pass when attaching the store to a session.
Seed it with content (optional)
Pre-load a store with reference material before any agent runs:Attach a memory store to a session
Memory stores are attached in the session’sresources[] array when the session is created. Unlike file resources, memory stores can only be attached at session creation time; adding or removing one from a running session is not supported.
Optionally include instructions to provide session-specific guidance for how the agent should use this store. It is shown to the agent alongside the store’s name and description, and is capped at 4,096 characters.
You can configure access as well. It defaults to read_write (shown explicitly in the following example), but read_only is also supported.
- Shared reference material: one read-only store attached to many sessions (standards, conventions, domain knowledge), kept separate from each session’s own read-write store.
- Mapping to your product’s structure: one store per end user, per team, or per project, while sharing a single agent configuration.
- Different lifecycles: a store that outlives any single session, or one you want to archive on its own schedule.
How the agent accesses memory
Each attached store is mounted inside the session’s sandbox as a directory under/mnt/memory/. The directory name is the store’s display name sanitized to a filesystem-safe slug (lowercased; non-alphanumeric runs become a single hyphen), so a store named “Demo Memory” mounts at /mnt/memory/demo-memory/. The exact path is returned in the mount_path field on the session’s memory-store resource; read it from there rather than constructing it yourself. The agent reads and writes the store with the standard agent toolset. Writes under the mount path are persisted back to the store and stay in sync across sessions that share it; writes to any other path under /mnt/memory/ land in container-local scratch and are lost when the session ends. A short description of each mount (display name, mount path, access mode, store description, and any instructions) is automatically added to the system prompt.
access is enforced at the filesystem level: a read_only mount rejects writes, while writes to a read_write mount produce memory versions attributed to the session.
The agent’s reads and writes appear in the event stream as ordinary agent.tool_use and agent.tool_result events for whichever tool touched the mount.
View and edit memories
Memory stores can be managed directly through the API. Use this for building review workflows, correcting bad memories, or seeding stores before any session runs.List memories
List the memories in a store. Results are returned in a stable, server-defined order.path_prefixscopes the list to one directory. It must end with/and matches whole path segments, sopath_prefix=/notes/returns/notes/todo.mdbut not/notes-archive/todo.md.depthcontrols how deep the listing goes belowpath_prefix: omit it (or pass0) to list the whole subtree, or pass1to list only the immediate children. Other values return a400error.
Read a memory
Fetching an individual memory returns the full content.Create a memory
memories.create creates a memory at a given path. Create does not overwrite; to change an existing memory, use memories.update.
Update a memory
memories.update modifies an existing memory by ID. You can change content, path (a rename), or both. The example renames a memory to an archive path:
Safe content edits (optimistic concurrency)
To avoid clobbering a concurrent write, pass acontent_sha256 precondition. The update only applies if the stored content hash still matches the one you read; on mismatch, re-read the memory and retry against the fresh state.
Delete a memory
Audit memory changes
Every mutation to a memory creates an immutable memory version (memver_...). Use the version endpoints to audit who changed what and when, to inspect or restore a prior snapshot, and to scrub sensitive content out of history with redact.
Versions belong to the store (not the individual memory) and survive even after the memory itself is deleted, so the audit trail stays complete. Versions are retained for 30 days; however, the recent versions are always kept regardless of age, so memories that change infrequently might retain history beyond 30 days. The live memories.retrieve call always returns the latest version; the version endpoints give you the retained history.
There is no dedicated restore endpoint; to roll back, retrieve the version you want and write its content back with memories.update (or memories.create if the parent memory has been deleted, because versions outlive their parent).
Past memory versions might be deleted after 30 days. To preserve memory history for longer, export versions through the API.
List versions
List version history for a store, newest first. The example filters to a single memory’s history:Retrieve a version
Fetching an individual version returns the same fields as the list response plus the fullcontent body.
Redact a version
Redact scrubs content out of a historical version while preserving the audit trail (who did what, when). Use it for compliance workflows such as removing leaked secrets, PII, or user deletion requests. A version that is the current head of a live memory cannot be redacted. Write a new version first (or delete the memory), then redact the old one.Manage memory stores
In addition tocreate, memory stores support retrieve, update, list, archive, and delete.
List stores
List stores in the workspace. Archived stores are excluded by default; passinclude_archived: true to include them.
Archive a store
Archiving makes a store read-only and prevents it from being attached to new sessions. Archiving is one-way; there is no unarchive.memory_stores.delete.
Best practices for memory management
When a store reaches its 2,000-memory limit, writes to new memories fail: both directmemories.create calls and the agent’s file writes to unmapped paths. Existing memories remain readable and editable. The following practices help you stay well under the limit and recover gracefully if you reach it.
- Use focused stores. Rather than one large general-purpose store, use smaller purpose-built stores: one per user, one for shared domain knowledge, and one for project-specific context. Each store has its own 2,000-memory limit, so keeping stores scoped reduces the chance any single one fills up.
-
Condense or prune before the store fills up. Delete stale or redundant memories with
memories.delete. You can also run a dreaming session, which consolidates fragmented content into a separate new output store rather than modifying the original. Switch your sessions over to that output store, then archive or delete the original. -
Attach a new store when it makes sense. If a store has grown beyond its useful scope, attach a fresh one for new content and attach the original with
read_onlyaccess. The agent can read from both while only writing to the new one. -
Limit write access where appropriate. Sessions that only read shared reference material don’t need
read_write. Keeping write access scoped to sessions that actually add new memories makes it easier to track where growth is coming from.