Memory Store

Concepts

A memory store is a resource managed independently of sessions, used to keep an agent's long-term working notes:

Layer	Description
Memory Store	A logical container with a name and description. A workspace can contain multiple memory stores.
Memory	A single file inside a memory store, consisting of a path and a UTF-8 text body, such as a Markdown note.
Version	A historical version automatically produced on every create, modify, or delete of a memory. Versions can be listed and viewed.

Quotas and Limits

A single memory file is limited to 102400 UTF-8 bytes.
A session can mount at most 8 memory stores.
A memory store can be mounted to multiple sessions at the same time, with its content shared across sessions.
Each mount instruction is limited to 4096 characters.

Creating a Memory Store

On the Memory Stores page, click Create Memory and enter a name and description. The name is 1–255 characters.

The console supports creating, editing, and archiving memory stores. Writing memory files, querying versions, and deletion are done via API—see below and the Memory Store API.

Create one via API; the response returns an ID with the memstore_ prefix. For full parameters and response fields, see the Create Memory Store API.

curl -X POST "$AGENTSTUDIO_URL/memory_stores" \
  -H "Authorization: Bearer $DASHSCOPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Project Knowledge",
    "description": "Project conventions, decisions, and troubleshooting notes"
  }'

Writing and Managing Memories

Memory files are managed via API. Paths start with /, for example /notes/project.md. Write a memory; the response returns an ID with the mem_ prefix. For full parameters and response fields, see the Create Memory API.

curl -X POST "$AGENTSTUDIO_URL/memory_stores/memstore_xxx/memories" \
  -H "Authorization: Bearer $DASHSCOPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "path": "/notes/project.md",
    "content": "# Project Conventions\nThe default development environment is staging.\n"
  }'

Read and modify:

Read: GET /memory_stores/{memory_store_id}/memories/{memory_id} returns the body; an archived but undeleted store can still be read.
Modify: POST /memory_stores/{memory_store_id}/memories/{memory_id} — pass new content to update the body, a new path to rename, or both for an atomic change. A real change automatically produces a modified version.
Concurrency protection: On update, include the content_sha256 obtained at read time in precondition; if the content has been changed by someone else, the request returns a conflict—re-read, merge, and retry.
List: GET /memory_stores/{memory_store_id}/memories supports path_prefix filtering, depth (0 recursive / 1 current level), and view (basic without body / full with body). Results are sorted by path; keyword search over bodies is not supported.
Delete: DELETE /memory_stores/{memory_store_id}/memories/{memory_id} deletes the current file while keeping historical versions, which remain queryable via the version APIs.

Write operations require the memory store to be unarchived. For full parameters and response fields, see the Memory API.

Mounting to a Session

Console

In the Resources section of New Session, click +, choose Memory, configure the following options, and click Create Session:

Field	Description
Memory	Select the memory store to mount
Access	Read-only (retrieve only) or read-write (Dreaming can also consolidate the conversation back into the store after the session ends)
Instructions	Provided to the agent together with the mount, helping it decide when to retrieve this memory

API

Specify it in resources when creating the session; access defaults to read_write when omitted:

curl -X POST "$AGENTSTUDIO_URL/sessions" \
  -H "Authorization: Bearer $DASHSCOPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "agent_xxx",
    "resources": [
      {
        "type": "memory_store",
        "memory_store_id": "memstore_xxx",
        "access": "read_write",
        "instructions": "Check the project conventions in this store first; save new findings to the relevant notes."
      }
    ]
  }'

The resources in the response contains the server-generated mount_path, for example /mnt/memory/<name>. Reference the full path directly in the system prompt. A memory store can only be mounted at session creation; after creation, mounts cannot be added, removed, or changed. To make adjustments, create a new session.

How the Agent Uses Memory

When a session has memory mounts, the platform automatically injects memory instructions into the agent, including mount paths, access, and the instructions you filled in. The agent works as follows:

Uses Glob and Grep to search under the mount paths, Read to load relevant files, and Write and Edit to save information worth keeping after completing the task.
Read-only mounts support query and read only; read-write mounts support all file operations.
Shell commands cannot access memory paths; only the file tools above can.

Do not store keys, tokens, or other credentials in memory. Mount instructions are business-defined content and cannot override platform security policies.

Historical Versions

Every create, modify, and delete of a memory automatically produces a version record. Version queries do not require the current memory to still exist:

List versions: GET /memory_stores/{memory_store_id}/memory_versions — filter by memory_id for a single memory, or by operation (created / modified / deleted) and creation time range; results are in reverse chronological order.
View a version: GET /memory_stores/{memory_store_id}/memory_versions/{memory_version_id} returns that version's body for reviewing old content; it does not roll back the current memory.
Redact a body: POST /memory_stores/{memory_store_id}/memory_versions/{memory_version_id}/redact erases the body of the specified version. Irreversible and does not affect the current memory.

For full parameters and response fields, see the Memory Version API.

Archiving

Click Archive on the Memory Stores page, or call POST /memory_stores/{memory_store_id}/archive. Archiving is irreversible: the store can no longer be written or bound to new sessions, and existing session mounts become read-only. The list does not return archived stores by default; pass include_archived=true to include them. Repeated archive calls are idempotent.

Common Errors

HTTP	error.code	Cause
400	`invalid_request_error`	Invalid parameters, path, limit, or pagination cursor
401	`InvalidApiKey`	API key missing, invalid, or expired
403	`permission_error`	Insufficient identity or resource access permissions
404	`not_found_error`	Store, memory, or version does not exist or does not belong to the current workspace
409	`memory_path_conflict_error`	Duplicate file path or conflict with an existing file/directory
409	`memory_precondition_failed_error`	Condition update conflict caused by concurrent modification
409	`memory_store_archived_error`	Write attempted on an archived memory store
429	`rate_limit_error`	Request rate limited

Next Steps

Delegate Work to an Agent: Mount a memory store at session creation.
Manage Agent Context: Learn about all mountable resource types.
Memory Store API: The complete API for stores, memories, and versions.

​Concepts

​Quotas and Limits

​Creating a Memory Store

​Writing and Managing Memories

​Mounting to a Session

​Console

​API

​How the Agent Uses Memory

​Historical Versions

​Archiving

​Common Errors

​Next Steps

Concepts

Quotas and Limits

Creating a Memory Store

Writing and Managing Memories

Mounting to a Session

Console

API

How the Agent Uses Memory

Historical Versions

Archiving

Common Errors

Next Steps