Agent Memory in 2026: Dreaming, Memory Bank, and the Long-Context Shift

AI agent memory architecture changed materially in May 2026. Anthropic shipped “Dreaming” — an async hippocampal-consolidation process for Managed Agents — on May 6, and deepened coverage at Code with Claude London on May 19-20. Google launched Memory Bank, an identity-scoped persistence primitive, at I/O 2026. For the original Mem0/Letta/Zep/Graph-RAG framework comparison, see our April 14 deep dive on agent memory architectures. This post is the May 2026 update layer.

Three months ago, the memory architecture decision was mainly a capability question: which framework handles multi-hop reasoning, temporal recall, or cross-session coherence best? In May 2026, it is also a cost question. Claude Opus 4.7's 1M-token context at flat pricing can make “just stuff it in context” cheaper than a Mem0 + Pinecone stack for agents with under roughly 500K tokens of history and low call volume. The worked example in section 08 shows where that stops being true.

This guide covers what shipped (Dreaming, Memory Tool, Memory Bank, Mem0 ADK integration), how Anthropic's three memory surfaces differ, vector database pricing, episodic and knowledge-graph patterns from Letta and Zep, a worked cost example for long-context memory, a 10-scenario decision matrix, and the LangChain migration. For the broader agentic AI context, see our agent architecture patterns taxonomy.

Four memory-related developments landed between April 23 and May 24, 2026, plus a conference that added implementation detail. The April 14 comparison of Mem0/Letta/Zep/Graph-RAG still covers the frameworks themselves; what follows is what changed after it.

April 23, 2026 — Anthropic adds persistent memory to Claude Managed Agents as a public beta. This was the infrastructure move that preceded everything else: Anthropic made cross-session state persistence available for Managed Agents builds without requiring developers to implement their own external memory stores. Source: EdTech Innovation Hub, retrieved May 24, 2026.

May 6, 2026 — Anthropic ships Dreaming. The Dreaming feature for Claude Managed Agents launched — an async, between-session process that reviews agent session transcripts, pulls patterns out, merges duplicates, replaces stale entries, and writes new memory entries that future sessions can use. Dreaming is explicitly modeled on hippocampal memory consolidation (see section 02 for the technical deep-dive).

May 19, 2026 — Google launches Memory Bank at I/O Day 1. Google's Memory Bank launched as part of the Gemini Enterprise Agent Platform alongside ADK 2.0 (Agent Development Kit, GA the same day). Memory Bank provides identity-scoped persistence — an agent can remember a user's preferences, history, and key details across multiple sessions. See section 03 for the architecture breakdown.

May 19-20, 2026 — Code with Claude London deepens memory coverage. Anthropic ran sessions on multi-agent orchestration, outcomes, memory, Dreaming, advisor strategy, and Claude Managed Agents at Code with Claude London — the same event where self-hosted sandboxes and MCP tunnels launched. The memory sessions added implementation depth to the May 6 feature announcements.

Mem0 publishes Google ADK persistence integration. Mem0 confirmed that its persistent-memory layer now integrates with all three major agent stacks — Anthropic SDK, OpenAI Agents SDK, and Google ADK. This cross-vendor positioning is the defining business-model move for Mem0 in 2026: it is no longer tied to a single vendor's memory model.

Anthropic describes a “dream” as a read of an existing memory store plus past session transcripts, producing a new reorganized memory store. Per The New Stack's coverage: it is “a scheduled process that runs between agent sessions, reviews everything an agent did in its last job, pulls patterns out of those sessions, and writes new memory entries that the next session can use.”

SiliconANGLE reported: “Anthropic compares it to hippocampal memory consolidation, the way a human brain replays the day's events during sleep and decides what to keep.” The analogy maps onto the neuroscience: the hippocampus replays waking experiences during sleep to transfer important episodic memories to long-term cortical storage. Dreaming does the same for agent session data — the between-session window is when consolidation happens.

Operational characteristics: Dreams run asynchronously, typically taking minutes to tens of minutes depending on input size. The agent writes learnings as plain-text notes and structured “playbooks” that future sessions can reference. Every step is observable and auditable — writes appear in the session event stream. Dreaming is distinct from two other Anthropic memory surfaces developers need to distinguish:

• Anthropic Memory Tool — filesystem-based, mounted at /mnt/memory/ inside the agent container. Claude uses bash and code-execution tools to read and write memory files. Storage is client-controlled (local FS, S3, etc.). Beta header: context-management-2025-06-27. Every write creates an immutable version for audit and rollback. Per Anthropic's Memory Tool docs: “Claude can create, read, update, and delete files that persist between sessions, allowing it to build knowledge over time without keeping everything in the context window.”
• Anthropic persistent memory beta (April 23, 2026) — the platform-level cross-session state feature in Managed Agents, distinct from both the Memory Tool and from Dreaming.
• Dreaming — the async consolidation layer that operates on top of the persistent memory and session transcripts. Managed Agents only.

Harvey's reported 6x task-completion lift after enabling Dreaming on production legal agents is the headline outcome metric — but it carries a critical caveat: this is vendor-reported data from a single production deployment, not an independent third-party reproduction. Treat it as an indicative signal, not a guaranteed performance benchmark. Per The New Stack, retrieved May 24, 2026.

Google's Memory Bank launched at I/O 2026 Day 1 (May 19) as part of the Gemini Enterprise Agent Platform, alongside ADK 2.0 GA. The architectural position is distinct from every other memory primitive in Google's stack — understanding the difference matters for teams building on Google Managed Agents.

Per Google Cloud's Memory Bank docs: “For long-term memory across sessions, Google provides additional tools like Memory Bank which scopes memories to a specific identity, allowing an agent to remember a user's preferences, history, and key details across multiple sessions.”

Where it fits in the Google Managed Agents memory stack:

• Session State — turn-scoped within one session. Persists files and state across calls within a session via the Interactions API's previous_interaction_id. Ephemeral once the session ends.
• Memory Bank — identity-scoped, cross-session persistence. A user's preferences, facts, and history are stored against that user's identity and retrieved on future sessions. Available via a dedicated ADK quickstart.

The practical implication for the Google Managed Agents API: Memory Bank is the right tool for multi-session, multi-user agents (e.g., a customer service agent that remembers previous interactions). Session State is the right tool for within-session continuity. Mixing them up is a common build error.

Mem0 has also published an ADK integration pattern that layers Mem0's memory model on top of Google ADK agents — giving teams who prefer Mem0's graph-enhanced memory model an escape hatch from the native Memory Bank primitive. This cross-vendor integration confirms that Mem0 is positioning itself as the persistent-memory middleware for all three major agent stacks, not just a framework-specific tool.

The agent API you build on now sets your default memory model. That choice decides how memory is stored, who controls it, how it is retrieved, and which security surface you are responsible for.

The practical implication: a team choosing between these three APIs is also implicitly choosing between a filesystem memory model, an identity-database memory model, and a vector-store memory model as their default starting point. Switching later requires rebuilding the memory layer, not just swapping an API key. Teams uncertain about vendor lock-in should evaluate Mem0 as an abstraction layer above all three.

For a comprehensive view of how memory fits into the broader agent architecture, see our complete guide to AI agent memory systems.

Vector retrieval remains the dominant pattern for agent long-term memory at scale, and no May 2026 release changed that. What has changed is pricing and the scale at which each option is economical. The chart below compares the three managed services at 10 million vectors. For the 8-vendor head-to-head with performance benchmarks, see our vector DB comparison guide; for the RAG-context selection guide, see vector databases for RAG applications.

Key pricing notes as of May 24, 2026 (verify before committing — vector DB pricing changes frequently):

• Pinecone Serverless: ~$70/month at 10M vectors of 1,536 dimensions; $0.33/GB/month storage; Read Units $16/M on Standard, $24/M on Enterprise. HNSW indexing adds ~1.5x storage overhead.
• Weaviate Cloud: The old $25/month Serverless tier was retired (October 2025 restructure). Flex starts at $45/month, with vector dimensions from $0.00465 per million and storage from $0.12 per GiB, per Weaviate's pricing page as checked on October 3, 2026.
• Qdrant Cloud: ~$65/month at 10M vectors. Above 60-80M queries/month, self-hosted Qdrant on a fixed-cost VPS consistently undercuts Pinecone Serverless by 3-10x according to LeanOps' 2026 cost comparison, retrieved May 24, 2026.

A common error: OpenAI's text-embedding-3-large native dimension is 3072, not 1536. Matryoshka shortening to 1536 is the common pgvector pairing, since a 3,072-dimension vector column is above pgvector's 2,000-dimension index limit, but it is explicit shortening, not the native default. Cohere embed-v4's default is 1536.

Chroma (free and open source in embedded mode), Milvus (self-hosted or on Zilliz Cloud) and pgvector (Postgres infrastructure cost only) have no comparable list price at this size, so they are left out of the chart. pgvector stores vectors of up to 16,000 dimensions but indexes only up to 2,000 for the standard vector type and 4,000 for halfvec, per the pgvector README (checked October 3, 2026). Milvus adds GPU indexes (CAGRA) and DiskANN for collections above 100M vectors.

HNSW vs IVF — don't conflate them. HNSW (Hierarchical Navigable Small World) is a graph-based ANN index with logarithmic search — the dominant choice for ≤100M vectors at interactive latency. Tunable via M (max connections per node), ef_construction (build-time quality), and ef_search (query-time quality). IVF (Inverted File) is a partition-based index tuned via nlist / nprobe — useful for batched workloads but different algorithm entirely. DiskANN (Microsoft) targets disk-resident billion-scale collections.

Hybrid search (BM25 + vector) is now standard across Pinecone, Weaviate, Qdrant, Milvus, and pgvector. Pure vector search misses exact-match terms (product SKUs, error codes); pure BM25 misses semantic synonyms. For a deeper implementation guide, see self-hosted RAG on Postgres + pgvector.

Vector retrieval handles semantic similarity well. It does not handle multi-hop relational reasoning (“find all suppliers of suppliers of company X who are also customers of company Y”) or temporal recall (“last week we tried approach A and it failed — why?”). Those are knowledge-graph and episodic memory problems respectively.

Knowledge graphs. Neo4j (Cypher query language) is the commercial baseline — graph-native storage, ACID-compliant, with a Vector Index (HNSW) added for hybrid retrieval-augmented graph traversal. For agents that need multi-hop reasoning over structured relationships, Neo4j + vector index is the combination that production architectures converge on. Other viable options: Memgraph (in-memory, Cypher-compatible), AWS Neptune (Gremlin + SPARQL + openCypher), ArangoDB (multi-model: document + graph + key-value).

Zep's Graphiti engine is a temporal knowledge graph with timestamped node and edge updates — purpose-built for agent memory where “yesterday vs today” matters. Per vendor-published benchmark data (treat as indicative): Zep scores approximately 63.8% on LongMemEval (GPT-4o), around 15 points higher than Mem0's 49.0%, largely attributed to Graphiti's temporal reasoning capability. Source: Atlan’s 2026 memory framework comparison, retrieved May 24, 2026.

Episodic memory via Letta (the MemGPT lineage). MemGPT is the research lineage (Berkeley 2023); Letta is the commercial spin-out that commercialized those patterns. The MemGPT/Letta architecture uses explicit memory management functions: core_memory_append, core_memory_replace, archival_memory_search, and conversation_search. Letta's three-tier model is deliberately inspired by OS memory management — core memory (always in-context, like RAM), archival memory (external searchable vector store, like disk), and recall memory (conversation history).

Letta scores approximately 83.2% on the LoCoMo long-conversation memory evaluation according to vendor-published benchmarks — strong performance on “agent remembers we tried X yesterday and it failed” tasks. This is vendor-published data; treat it as directionally informative rather than independently verified. For the full Mem0/Letta/Zep comparison, the April 14 deep-dive on agent memory architectures remains the definitive framework reference.

What changed in spring 2026 is the price of long context. Two releases weakened the cost case for explicit episodic memory at small scale:

Claude Opus 4.7 (April 16, 2026) introduced a 1M token context window at flat pricing: $5 input / $25 output per Mtok. There is no surcharge above 200K tokens like prior generations. This makes long-context retrieval — where you simply include all accumulated session history in every call — roughly cost-competitive with maintaining a Mem0 + Pinecone stack for agents with fewer than ~500K tokens of accumulated history, at low call volume (section 08 works through the numbers). For context on how Opus 4.7's context window performs at scale, see our long-context vs explicit retrieval analysis.

Gemini 3.5 Flash (GA May 19, 2026) offers the cheap-1M-context alternative: $1.50 input / $9.00 output per Mtok, with $0.15/Mtok for cached input. It is the default backing model for Google's Managed Agents API. At those price points, single-user agents with infrequent calls may find Gemini 3.5 Flash + full context cheaper than any managed vector store option.

GPT-5.5's 1.05M context window carries a long-context surcharge above 272K input tokens (2x input, 1.5x output for the full session) — so do not treat all 1M+ context models as equivalent in economics. On Anthropic's pricing page (checked October 3, 2026), every Claude model from the 4.6 generation on bills the full 1M window at the standard per-token rate, so the flat-pricing advantage is not unique to Opus 4.7.

The crossover analysis from the Opus 4.7 cost strategy guide: for agents with fewer than ~500K tokens of accumulated history and fewer than 10 sessions, long-context can undercut Mem0 + Pinecone on total cost. Above 1M tokens of history the record no longer fits in the window at all, so explicit memory becomes mandatory regardless of price.

For the broader context-window competition, the context-window arms race guide covers how long-context competes as a product surface.

The 500K-token rule of thumb leaves out the variable that decides the bill: how many calls re-read the history, and how many of those reads hit the prompt cache. Here is the arithmetic for one agent on Claude Opus 4.7, at the rates on Anthropic's pricing page as checked on October 3, 2026: $5 per million input tokens, $6.25 per million for a five-minute cache write and $0.50 per million for a cache hit, with the full 1M window billed at the standard rate.

The inputs are an illustrative example. The full-context design sends the whole memory history on every call and caches it, so the first call of each session writes the cache and every later call in that session reads it. The retrieval design sends 8,000 tokens of retrieved memory per call, uncached, plus a $50 monthly floor for the vector store, which is the minimum usage charge on Pinecone's Standard plan (Pinecone pricing page, checked October 3, 2026). The memory library is assumed self-hosted at no fee. Output tokens are the same in both designs, so they are left out, as are embedding costs.

Full context per month = sessions × history × $6.25/M + (calls − sessions) × history × $0.50/M. Retrieval per month = calls × 8,000 × $5/M + $50.

Three things follow. Long context wins when sessions are few and short: in scenario A the cache writes are most of the bill and there is no fixed fee to cover. It stops winning as history grows, even at low volume (scenario B), because every session start writes the whole history again at $6.25 per million. Without cache hits it loses at almost any volume: at 300K tokens each uncached call costs $1.50 against $0.04 for a retrieval call, so the $50 floor is covered after 35 calls ($50 ÷ $1.46 = 34.2).

Two counting errors make full context look cheaper than it is. First, measure history with the model's own token counter: Anthropic's pricing page notes that Claude 4.7 and later models use a tokenizer that produces about 30% more tokens for the same text. Second, the five-minute cache lapses between sessions, so a user who returns once a day pays a cache write every day. The one-hour cache write costs $10 per million on Opus 4.7, which only pays off when calls cluster within the hour. Run the two formulas on your own session logs before choosing a design, and check retrieval quality at your history length separately: cost is only half of the decision.

The following matrix maps agent use-case dimensions — data type, query pattern, scale, latency, and budget — to specific recommended architectures. For the agentic RAG retrieval patterns that complement this matrix, see our agentic RAG patterns guide. For common retrieval failure modes to avoid, see RAG anti-patterns and failure modes.

Two maintenance items affect every production agent memory implementation in 2026: the security surface introduced by writable memory, and the LangChain deprecation that has left thousands of published guides pointing at dead APIs.

Memory poisoning. OWASP's Top 10 for LLM Applications 2025 lists LLM04 Data and Model Poisoning and LLM08 Vector and Embedding Weaknesses as the primary memory-relevant attack vectors. Memory poisoning includes three categories: prompt injection via retrieved document (a malicious document in the vector store causes the agent to execute unintended instructions); embedding-collision attacks (adversarially crafted inputs that appear semantically similar to legitimate queries but retrieve poisoned content); and direct memory-store tampering for agents with explicit write tools like Letta's core_memory_append or Anthropic's filesystem Memory Tool.

Practical mitigations: validate and sanitize all retrieved content before injection into the agent context; implement read-only memory paths where write access is not required; use the Memory Tool's immutable versioning for audit trails; monitor the session event stream for unexpected memory write patterns. For common RAG failure modes that overlap with memory security, see the RAG anti-patterns guide.

LangChain memory is deprecated. As of 2026, BufferMemory, ConversationBufferMemory, ConversationSummaryBufferMemory, and VectorStoreRetrieverMemory from langchain.memory are the old API. Per a 2026 LangChain-memory breakdown: “A significant change in 2026 is that LangGraph is now the only officially supported way to do memory” in the LangChain ecosystem. The LangChain memory overview docs confirm the migration path. Many published tutorials — including results on the first page of Google for “LangChain memory” — still reference BufferMemory as current. If your team is following any guide written before mid-2025 for LangChain memory, it is almost certainly pointing at deprecated code.

The LangGraph memory model uses a clean thread/store separation: short-term memory is thread-scoped (agent state persisted via a checkpointer to a database, fully resumable across interruptions); long-term memory is store-scoped (vector or graph backend, queryable across threads). The thread/store distinction maps directly onto session-scoped vs cross-session memory — the same architectural separation that Anthropic's three-surface model and Google's Session State/Memory Bank primitives encode.

For teams using LlamaIndex, the memory modules available include ChatMemoryBuffer, ChatSummaryMemoryBuffer, VectorMemory, and SimpleComposableMemory for chaining — none of these carry the deprecation risk of the LangChain legacy APIs.

For the full glossary of agentic memory terms, see our agentic AI glossary. For AI transformation advisory that includes agent memory architecture reviews, see our AI transformation services.