Memory store never mounts in deployment-created sessions — CMA memory cookbook pattern breaks under scheduled deployments

The Managed Agents memory cookbook (managed_agents/CMA_remember_user_preferences.ipynb) demonstrates memory stores with directly-created sessions, and that works exactly as documented. The same pattern does not hold when the session is created by a scheduled deployment: /mnt/memory is absent from the container entirely.

This matters for the cookbook specifically because persistent cross-session memory and scheduled unattended runs are a natural pairing — a recurring agent that remembers what it saw last time is the obvious use case, and it's currently the one combination that doesn't work.

Expected

shared/managed-agents-memory.md:

Each attached store is mounted in the session container at /mnt/memory/<store-name>/.

API reference, CreateDeployment:

Optional session config (resources, vault_ids, etc.) is supported the same way as on CreateSession.

No documentation states any limitation on memory stores with deployments.

Actual

/mnt/memory does not exist. Not an empty mount point — no directory. Other mounts in the same container are fine (/mnt/skills, /mnt/session/*, /mnt/attach, and an rclone mount for /mnt/session/outputs), so mounting works generally; only the memory-store mount is missing.

Reproduction

Constant across all runs: same agent, same environment (config.type: "cloud"), same memory store, same resource object:

{"type": "memory_store", "memory_store_id": "memstore_...", "access": "read_write"}

Probe:

for i in $(seq 1 30); do [ -d /mnt/memory ] && break; sleep 3; done
ls -la /mnt/memory/ 2>&1; mount | grep -iE 'memory|rclone'

5/5 direct sessions mount. 3/3 deployment-created sessions do not.

Hypotheses ruled out by experiment

• The instructions field on the resource — present on our deployment resources, absent from the first working session. Tested both ways directly: mounts either way.
• access mode — read_only mounts correctly as ro.
• initial_events — the most promising theory, since deployments always start a session directly in running and the docs note that without initial_events "the sandbox comes up when the session first needs it". Tested by creating a session with initial_events via raw REST (the ant CLI has no flag for it): it mounted normally. So immediate-start is not the trigger.
• Provisioning latency — waits of 90s and 210s both failed.
• Self-hosted sandboxes — documented as not supporting memory stores, but this environment is cloud.

Two suggested changes to the notebook

1. mount_path is not evidence of a mount. The notebook does:

if resource.type == "memory_store":
    print(f"Mounted at {resource.mount_path}")

mount_path is derived server-side from the store's name and is returned identically whether or not the FUSE mount exists — we confirmed it is present in the session record for every failing session, and it appears even when not supplied at creation. As written, the cookbook would print Mounted at /mnt/memory/shopper-preferences for a session with no mount at all. A check against the filesystem (or a note that mount_path is the intended path rather than a confirmation) would be more robust.

2. A deployment example would have caught this. Every memory example uses a directly-created session, so this combination appears untested.

Impact

The filesystem mount is documented as the interface for memory stores. A scheduled deployment is the primary way to run an agent unattended. Right now those two can't be combined as documented, and there's no way to detect it from the API response — a client checking mount_path gets a success-looking value either way.

Workaround

The memory_list / memory_read / memory_write / memory_edit tools are present in the container and do work, so an agent can hydrate state from the store into the workspace and write back at the end. Viable for a once-daily run; expensive at higher frequency. (Noting that shared/managed-agents-memory.md says "there are no dedicated memory tools", which appears to be out of date.)

Environment

• Beta: managed-agents-2026-04-01
• Environment: config.type: "cloud", networking.type: "limited"
• CLI: ant v1.16.0 for deployment creation; raw REST for the initial_events test
• First observed 2026-08-13, reproduced 8 times, deterministic

Happy to supply session IDs / deployment IDs privately if that helps trace it.