Anthropic now ships two agent-memory features with almost the same name. One is the memory tool. The other is memory stores. They are not two brands of the same thing, and picking between them by asking "which one remembers better" is the wrong question — they sit at different layers of the stack and answer different problems. The deciding question is who runs your agent loop, and who should own the bytes.

Here's the one-screen answer: the memory tool is an interface Claude calls and you implement — memory as an API surface, portable, backed by any storage you like. Memory stores are managed, versioned state Anthropic hosts and the agent reads as a mounted filesystem — memory as infrastructure, with a built-in audit trail, available only inside Managed Agents. Run your own loop or need it on Bedrock/Vertex? Memory tool. Already on Managed Agents and want zero-infra, auditable, shared memory? Memory stores.

The memory tool: an interface you back yourself#

The memory tool is a client-side tool on the Messages API. You declare it with no schema of your own:

tools=[{"type": "memory_20250818", "name": "memory"}]

Claude then issues commands against a /memories directory — view, create, str_replace, insert, delete, rename — and your code executes them. Anthropic defines the interface; you define where the files actually live. That's the whole point: the bytes can sit on local disk, in S3, or in a database, and the choice is a storage-backend decision you own end to end.

Because the storage is yours, three things follow. It runs anywhere the Messages API runs — including Amazon Bedrock and Google Vertex, where the managed-agents surface doesn't exist. You control encryption, residency, and per-user isolation. And you're on the hook for the security: every path Claude hands you is model output, so you resolve it, confirm it stays inside the memory root, and reject traversal (.., symlinks, absolute paths) before touching the filesystem. The Python and TypeScript SDKs give you BetaAbstractMemoryTool / betaMemoryTool scaffolds so you're implementing the handlers, not the plumbing. If you've already wired the memory tool into an agent, this is the model you're living in.

The memory tool is the cross-session complement to context editing, which prunes stale tool results within a run. Editing keeps the live transcript lean; the memory tool is where the agent writes down what should outlast the transcript.

Memory stores: managed, versioned state you rent#

Memory stores live one layer up, in Managed Agents — the surface where Anthropic runs the agent loop and hosts a per-session container. A store is a workspace-scoped collection of small text documents. You create one with the SDK (client.beta.memory_stores.create(...), beta header managed-agents-2026-04-01) and attach it to a session at creation time:

session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=env.id,
    resources=[{
        "type": "memory_store",
        "memory_store_id": store.id,
        "access": "read_write",          # or "read_only"
        "instructions": "User preferences and project context. Check before any task.",
    }],
)

Anthropic then mounts the store into the container as a filesystem at /mnt/memory/<store-name>/, and drops a note into the system prompt so the agent knows it's there. From the agent's side there is no special "memory tool" — it just uses bash, read, write, and glob on a directory. You can attach up to 8 stores per session (only at session-create), and a read_only mount is enforced at the filesystem level.

What you're renting is the operational shape the memory tool leaves to you:

The tradeoffs are the mirror image of the memory tool's freedom. Memory stores are Managed Agents only — first-party API and Claude Platform on AWS, not Bedrock, Vertex, or Foundry — and they're not supported with self-hosted sandboxes, where egress is yours and there's nowhere for Anthropic to host the mount.

How to actually choose#

Both are file/document stores addressed by path. Neither does semantic search — if your agent needs to recall by meaning, you still want an embedding index alongside either one, which is a separate decision between sqlite-vec, LanceDB, and Qdrant. And both persist and replay their contents into future runs, so neither should ever hold a secret — a key written once leaks into every later session. Use a vault or a host-side custom tool for credentials.

Past that, the fork is clean:

The names invite you to compare them as rival memory systems. They aren't. One is the notebook you carry and fill in yourself; the other is a version-stamped vault mounted into the room Anthropic runs for you. Pick by whose room your agent is standing in.