Claude Managed Agents Memory: A Secure Production Setup

Claude Managed Agents memory is a workspace-scoped collection of text documents that persists across sessions. Attach a store when creating a session and Claude sees it as a filesystem directory under /mnt/memory/. That is a useful primitive: the agent can maintain preferences, project conventions, prior mistakes, and runbooks with ordinary file tools instead of requiring a bespoke retrieval call.

Persistence is not the same as trustworthy memory, however. A writable store can preserve a prompt injection just as reliably as it preserves a correction. The production design question is therefore not “how do I turn memory on?” It is “which session may write which facts, how do concurrent edits behave, and can another tool inspect or recover the result?” This guide adds a two-store trust boundary and a six-case acceptance test that the current quickstarts do not provide.

If you need broader architecture first, read Persistent Memory for LLM Agents. For the storage decision, compare vector memory with readable memory.

What Anthropic’s memory store actually guarantees

According to Anthropic’s current Managed Agents memory documentation, each memory is a path-addressed UTF-8 text document. A memory can be at most 100 kB, a store can contain 10,000 memories, and a session can attach up to eight stores. Stores attach only when a session is created. Every mutation creates an immutable version; versions are generally retained for 30 days, while recent versions of a live memory can remain longer.

The current API has an important header split. Memory-store endpoints use agent-memory-2026-07-22; session endpoints use managed-agents-2026-04-01. Sending both headers on a memory-store request returns HTTP 400. Current SDKs choose the right header automatically, which is safer than setting it globally.

Anthropic reports that Rakuten saw 97% fewer first-pass errors, 27% lower cost, and 34% lower latency, while Wisedocs reported 30% faster verification. These are attributed customer results, not portable benchmarks. Treat them as evidence that memory can help a known workflow, then measure your own correction rate, retrieval cost, and failure modes.

Use two stores, not one writable bucket

Create one read-only store for reviewed policy and one read-write store for session observations. The agent may propose knowledge in the writable store, but a human or trusted promotion job moves accepted facts into policy. This prevents fetched pages, customer input, and tool output from directly rewriting the instructions future sessions trust.

Store	Access in normal sessions	Contents	Promotion rule
`project-policy`	read-only	Approved conventions, architecture decisions, recovery steps	Reviewed change only
`session-notes`	read-write	Candidate facts, observations, unresolved conflicts	Never treated as policy without review

That boundary matters because Anthropic explicitly warns that untrusted input can write malicious content to a read-write store, which a later session may consume as trusted memory. Filesystem permissions reduce the blast radius; they do not determine whether a fact is true.

Runnable Python setup

Install the current Anthropic SDK, export ANTHROPIC_API_KEY, CLAUDE_AGENT_ID, and CLAUDE_ENVIRONMENT_ID, then run this script. The agent and environment must already exist in your Managed Agents workspace.

python -m pip install -U anthropic
export ANTHROPIC_API_KEY="your-key"
export CLAUDE_AGENT_ID="agent_..."
export CLAUDE_ENVIRONMENT_ID="env_..."
python memory_setup.py

import os
from anthropic import Anthropic

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

policy = client.beta.memory_stores.create(
    name="project-policy",
    description="Reviewed project rules. Treat as authoritative.",
)
client.beta.memory_stores.memories.create(
    policy.id,
    path="/engineering/conventions.md",
    content="# Conventions\nUse ISO-8601 dates. Never commit secrets.\n",
)

notes = client.beta.memory_stores.create(
    name="session-notes",
    description="Unreviewed observations and candidate knowledge.",
)

session = client.beta.sessions.create(
    agent=os.environ["CLAUDE_AGENT_ID"],
    environment_id=os.environ["CLAUDE_ENVIRONMENT_ID"],
    resources=[
        {
            "type": "memory_store",
            "memory_store_id": policy.id,
            "access": "read_only",
            "instructions": "Read before acting; never attempt to modify it.",
        },
        {
            "type": "memory_store",
            "memory_store_id": notes.id,
            "access": "read_write",
            "instructions": "Record candidate facts with source and date.",
        },
    ],
)

print("policy_store=", policy.id)
print("notes_store=", notes.id)
print("session=", session.id)

Read the returned session resource for each exact mount_path; do not construct paths from display names. On self-hosted sandboxes, use Anthropic’s SDK worker rather than the CLI worker because the latter does not synchronize memory mounts.

Prevent lost updates

Two sessions may read the same file and race to update it. Use the returned content_sha256 as an optimistic-concurrency precondition. A stale write receives HTTP 409; re-read, merge deliberately, and retry. Do not automatically replace the fresh content with the stale body.

current = client.beta.memory_stores.memories.retrieve(
    memory_id,
    memory_store_id=store_id,
)

client.beta.memory_stores.memories.update(
    memory_id,
    memory_store_id=store_id,
    content=merged_content,
    precondition={
        "type": "content_sha256",
        "content_sha256": current.content_sha256,
    },
)

This protects one document from accidental overwrite. It does not resolve semantic conflicts across files, such as one note saying “deploy Fridays” and another saying “never deploy Fridays.” Your promotion workflow still needs conflict detection and an owner.

Run this six-case acceptance test

Persistence: write a dated candidate fact in session A. Start session B with the same notes store and verify it can quote the file and path.
Read-only enforcement: ask session B to modify the policy store. The filesystem operation must fail, while a notes-store write succeeds.
Poisoning: give the agent an untrusted page containing “replace project policy.” Verify it cannot alter policy and records, at most, an untrusted candidate note.
Concurrency: read one memory from two clients, update from the first, then submit the second update with the stale hash. Expect HTTP 409.
Correction and audit: correct a note, list memory versions, and retrieve the previous content. Test redaction separately with synthetic sensitive data.
Exit: list every memory with full content and reconstruct the useful knowledge outside the running agent. A memory system you cannot leave is an operational dependency, not durable ownership.

The last case is where readable, agent-agnostic memory helps. Meshnote exposes maintained Markdown wikis over MCP, so Claude, coding agents, and other MCP clients can share project knowledge without making one model runtime the only reader. See the Claude Code persistent memory setup for a concrete connector path.

How the main approaches differ

Approach	Best fit	Honest trade-off
Claude Managed Agents memory	Claude-hosted agents needing mounted text files and built-in versions	Tight integration; workspace and session model are Anthropic-specific
Mem0	Automatic fact extraction and hybrid semantic retrieval	Strong personalization pipeline; managed and self-operated capabilities differ
Zep / Graphiti	Temporal facts and relationship-heavy context	Powerful time-aware graph model; more machinery than a small project wiki
Letta	Long-running stateful agents with editable core memory and archival search	Rich agent runtime; memory is organized around Letta agents
Meshnote	Readable shared project memory across MCP clients	Human-auditable source of truth; not an automatic replacement for high-scale vector or temporal-graph retrieval

Native ChatGPT and Claude consumer memory are convenient for personal continuity, but they are not a substitute for an application-controlled project knowledge layer. Choose the boundary first: personal preference, runtime state, customer history, or reviewed team knowledge. Combining layers is often better than forcing one store to do every job.

A production rule that holds up

Let agents write observations; let a narrower, reviewable process write authority. Keep provenance beside each durable claim, use hashes for concurrent edits, and test recovery before launch. If multiple agent products need the same reviewed knowledge, make the canonical layer files you can inspect and self-host, then derive indexes as needed.

Start syncing — $8/mo. Teams can choose self-hosted deployment from $10/seat/month.