A memory store is a project-owned set of files that outlives sessions and machines. Agents read and write it with the storage_* tools at /memory/<store-name>/<path>; it is not mounted on the machine’s file system.

​
Managed Agents API

/v1/memory_stores follows the Anthropic shape:
  • A memory is a BMA memory file; its id is derived from the path, so moving a memory changes its id.
  • Updates are unconditional unless you send precondition: {type: "content_sha256", ...} (stale → 409). DELETE accepts expected_content_sha256.
  • Store name is stored as a slug; store metadata is not persisted.
  • Attach stores to a session with resources on POST /v1/sessions. A session that attaches nothing inherits the agent’s stores. A store attached by a session only shows that session’s sessions/<session_id>/ directory to its tools, so one project-wide store can serve many sessions safely.

​
Native API

Attach stores in the agent config:
read_write adds storage_write. Writes require both the attachment and the store’s agent_access to be read_write. Files keep only their current contents (no history); replacing or deleting through the API requires the expected digest.

​
Limits

  • Memory files carry no media type; mime_type in /v1 is derived from the extension.
  • Self-hosted deployments need a filesystem shared by the API, every worker and maintenance (BMA_MEMORY_DIR).