How Anthropic, Google, and OpenAI Each Implemented Agent Memory in 2026
Anthropic, Google, and OpenAI each shipped native agent memory in 2026 with different default architectures — filesystem, database, and vector store. Here's what each implies for developers.
By mid-2026, all three major model providers had shipped a native memory primitive for agents, and all three made a different default choice about where that memory lives. Anthropic mounted it as a filesystem inside the agent container. Google built it as an identity-scoped database primitive inside its enterprise agent platform. OpenAI wired it into the Responses API as a vector-store-backed retrieval tool. None of these are wrong. They reflect three different bets about how developers will compose memory with the rest of an agent's tool stack — and each has different implications for portability, latency, and how memory interacts with everything else the agent can do.
Anthropic's Memory Tool: memory as a filesystem
Anthropic brought persistent memory to Claude Managed Agents in public beta on April 23, 2026. The design choice is distinctive: memories are stored as files on a filesystem, mounted at /mnt/memory/ inside the agent's container. Developers can export, edit, and manage those files via API or directly in the Claude Console (EdTech Innovation Hub, Anthropic).
The reasoning behind the filesystem approach becomes clear once you consider what else lives in that container. Claude Managed Agents already have bash and code-execution tools. Mounting memory as files means Claude can grep its own memory, diff two versions of a file, write a script that reorganizes memory into folders, or pipe memory contents into another tool call — all using capabilities the model already has, rather than a bespoke memory API it has to learn separately. Memory becomes just another part of the filesystem the agent already reasons about.
The tradeoff is that filesystem-mounted memory is inherently scoped to the container it's mounted in. Portability across environments means exporting and re-importing files rather than pointing a different runtime at the same store.
Google's Memory Bank: memory as an identity-scoped database
Google took a different default. Memory Bank is an identity-scoped database primitive inside the Gemini Enterprise Agent Platform (state-of-agent-memory research summary, 2026). Rather than a container-local file store, memory is keyed to a user or agent identity and lives as structured records in a managed database.
That identity-scoping matters for a specific class of problem: multi-session, multi-surface continuity, where the same user identity might interact with an agent through a chat interface, a scheduled job, and an API integration, and all three need to read from and write to the same memory. A database primitive with identity as the join key handles that more naturally than a filesystem mounted per-container, because there's no single container the memory is tied to — it's tied to the identity instead.
The tradeoff mirrors the benefit: identity-scoped memory implies a managed database dependency and a query interface rather than raw file access, which is a different integration surface for developers who want to inspect or migrate memory directly.
OpenAI's file_search: memory as retrieval
OpenAI's default is file_search, a vector-store-backed retrieval tool inside the Responses API (same source). This is the most conventional of the three architectures in the sense that it maps directly onto retrieval-augmented generation: content gets embedded, stored in a vector store, and pulled back in via similarity search at inference time.
The implication for developers is that OpenAI's approach treats memory as a special case of document retrieval rather than a distinct primitive. That's a reasonable fit for agents whose memory needs look like a knowledge base — prior conversations, uploaded documents, structured notes — where semantic similarity is the right retrieval mechanism. It composes cleanly with other Responses API tools because it's exposed the same way any other tool call is exposed.
The tradeoff is that vector-store retrieval is inherently approximate and similarity-driven. It's well suited to "what's relevant to this query" but says less about temporal ordering, explicit edits, or the kind of file-level manipulation Anthropic's filesystem mount supports natively.
Three architectures, side by side
| Vendor | Primitive | Where memory lives | Access pattern | What it implies |
|---|---|---|---|---|
| Anthropic | Memory Tool | Filesystem at /mnt/memory/ inside the agent container | File read/write, exportable via API or Console | Composes with bash and code-execution; portability means moving files |
| Memory Bank | Identity-scoped database in Gemini Enterprise Agent Platform | Query by identity across sessions and surfaces | Strong for cross-surface continuity; managed database dependency | |
| OpenAI | file_search | Vector store, accessed via Responses API | Similarity-based retrieval, tool-call interface | Fits RAG-shaped memory; less native for explicit edits or ordering |
These aren't competing implementations of the same feature. They're three answers to overlapping but distinct questions: how does an agent keep state inside one container, across one user identity, or across a document-like corpus.
Dreaming: an async consolidation primitive, not a storage layer
Anthropic shipped a second, distinct memory-adjacent primitive on May 6, 2026: Dreaming. It's not a place to store memory — it's a process that runs asynchronously between agent sessions, reviewing session transcripts and memory stores, extracting patterns, merging duplicate entries, and surfacing new insights (OpenTools.ai).
This addresses a problem that filesystem or database storage alone doesn't solve: memory that accumulates without consolidation gets noisy. An agent that writes a new file or record every session ends up with redundant, contradictory, or stale entries unless something periodically reviews and merges them. Dreaming does that review offline, between sessions, rather than making the agent do it inline during a live request — which keeps consolidation cost off the response-latency path.
Early adopters cited include Netflix, Rakuten, Wisedocs, and Ando, with reported results including a 97% reduction in first-pass errors and a 30% speed increase in document verification workflows. Those numbers are workflow-specific to document verification use cases and shouldn't be generalized past that context, but they illustrate the category: consolidation is a distinct problem from storage, and treating it as a separate, asynchronous primitive is a genuine architectural choice, not just a marketing wrapper on the Memory Tool.
Where a third-party or embedded memory layer still fits
Platform-native memory is scoped to its platform. Anthropic's Memory Tool runs inside a Claude Managed Agent container. Google's Memory Bank is scoped to the Gemini Enterprise Agent Platform. OpenAI's file_search lives inside the Responses API. None of the three is designed to be the memory layer for an agent that needs to move between model providers, run offline, or maintain state before an agent runtime even starts.
That gap is exactly why third-party and embedded frameworks have kept growing alongside the platform primitives rather than being displaced by them. Mem0, a third-party memory framework, reports 41K GitHub stars and 14M downloads as of May 2026, and has published integrations with the Anthropic SDK, the OpenAI Agents SDK, and Google's ADK (source). Developers aren't locked into a single vendor's native primitive; a portable memory layer can sit underneath whichever model or agent framework is calling it.
Feather DB fits the same gap from a different angle: it's an embedded, single-file, zero-server vector database (pip install feather-db, MIT-licensed) that runs alongside the OpenAI SDK, Anthropic SDK, Gemini, LangChain, LangGraph, CrewAI, and MCP, rather than requiring a specific vendor's agent runtime to exist first. Because it's a single .feather file with no server process, memory can be created, tested, and version-controlled locally, then deployed wherever the agent runs — independent of whether that agent is calling Claude, Gemini, or GPT models in a given session. On LongMemEval_S, Feather DB paired with GPT-4o scored 0.693 against a full-context GPT-4o baseline of 0.640, which is a data point specifically about retrieval quality on long-horizon conversational memory, not a claim about replacing any platform's native tool.
The practical pattern emerging in 2026 is not platform memory versus embedded memory — it's platform memory for agents that live entirely inside one vendor's runtime, and an embedded or portable layer for agents that need memory to survive a provider switch, run without a managed backend, or exist before the agent framework is even chosen.
FAQ
Can I use Anthropic's Memory Tool with a non-Claude model?
No. The Memory Tool is a feature of Claude Managed Agents specifically, mounted inside that agent's container. It's not a portable API you can point another model provider's runtime at. That's the main reason cross-provider frameworks like Mem0 and embedded databases like Feather DB exist alongside it — they're designed to work the same way regardless of which model is calling them.
Is Google's Memory Bank the same thing as a vector database?
Not exactly. Memory Bank is described as an identity-scoped database primitive within the Gemini Enterprise Agent Platform — its defining feature is scoping by identity across sessions, not the underlying storage mechanism. OpenAI's file_search, by contrast, is explicitly vector-store-backed. The two solve different retrieval problems even though both are called "memory."
Does Dreaming replace the need for a vector search or retrieval layer?
No. Dreaming is a consolidation process — it reviews and merges what's already stored, running asynchronously between sessions. It doesn't perform retrieval itself. An agent still needs a storage and retrieval mechanism (the Memory Tool's filesystem, in Anthropic's case) for Dreaming to consolidate against.
If I'm already using a platform's native memory tool, do I still need something like Feather DB?
It depends on whether the agent needs to stay inside one vendor's runtime. If it does, the native primitive is usually the simplest path. If the agent needs to run across multiple model providers, operate offline, or keep memory portable independent of any single agent framework, an embedded layer like Feather DB is designed to sit underneath that switch rather than compete with the native tool.
If you're building an agent that needs memory to outlive a single provider's runtime, Feather DB is free and open source under MIT — pip install feather-db and try it against your own long-horizon memory workload.