Your AI agent forgets everything the moment a session ends. It processed 200 purchase orders last week and made the same mistake on number 201 that a human corrected on number 3. It asked the same clarifying question it asked yesterday. A user said “use the same shipping address as last time” and the agent had no idea what that meant.
This is the agent memory problem, and in the last two weeks, every major infrastructure vendor decided it was time to fix it.
On March 31, Microsoft published a reference architecture for user-scoped persistent memory in Azure AI Foundry, built on Cosmos DB, with per-user isolation enforced through Entra ID. On March 24, Oracle announced its Unified Memory Core as part of a broader agentic AI database release, arguing that agent memory is a data management problem that belongs inside the transactional database. Mem0, a YC-backed startup with $24.5 million in funding and roughly 48,000 GitHub stars, became the exclusive memory provider for AWS’s Agent SDK, according to StackOne’s 2026 agent tools landscape report.
Behind these headline announcements, at least six open-source frameworks are competing for the same architectural space. The question is no longer whether agents need persistent memory. The question is where it should live, who should own it, and what happens when it goes wrong.
Why Context Windows Are Not Memory
The most common misconception about agent memory is that larger context windows solve the problem. They do not.
Claude’s 200,000-token context window and Qwen’s 262,000-token window support complex interactions within a single session. But context windows reset when the session ends. They are working memory, not long-term memory. As Vectorize.io’s 2026 framework comparison puts it: “Raw chat logs are noise, not knowledge. What an agent needs is extracted, structured understanding that compounds over time.”
The distinction matters because enterprise agents are not chatbots. They run procurement workflows, manage customer relationships, coordinate security operations. A procurement agent needs to remember that vendor X requires a specific PO format, that approvals over $50,000 need different routing, and that Q4 budget reviews always slip by two weeks. This is institutional knowledge — the kind of accumulated understanding that makes human employees effective over months and years.
Without persistent memory, every agent execution restarts from zero. Teams compensate by stuffing context into system prompts, which burns tokens and does not scale. The alternative — building custom memory infrastructure from scratch — is what Microsoft, Oracle, and the startup ecosystem are now trying to eliminate.
Two Competing Architectures: Platform-Managed vs. Database-Native
The most significant architectural disagreement in the agent memory space is where memory should live. Microsoft and Oracle represent opposite ends of the spectrum.
Microsoft: Memory as a Platform Service
Microsoft’s Azure AI Foundry approach treats persistent memory as a first-class component of the agent platform. The reference architecture uses Azure Cosmos DB as the durable store, with each user’s context isolated and managed independently. Per-user memories are partitioned by the oid (Object ID) claim from Microsoft Entra ID tokens, meaning the same identity layer that authenticates human users now governs what an agent remembers about each of them.
The design separates ephemeral session state (managed by the Foundry runtime) from durable user memory (stored in Cosmos DB). Microsoft explicitly frames this as “curated, long-lived signals — such as preferences, recurring intent, or summarized outcomes from prior interactions — rather than raw conversational transcripts.”
The architecture also introduces an MCP-Memory server — an MCP (Model Context Protocol) server that hosts tools for extracting structured memory signals from conversations, generating embeddings, and persisting user-scoped memories. This means memory extraction is delegated to the model itself, which evaluates new inputs against existing stored state and decides what to keep.
The implicit bet: memory should be managed by the agent platform, with the database as a storage backend.
Oracle: Memory as a Database Problem
Oracle’s counter-argument is that agent memory is fundamentally a data management problem, and the database is the right place to solve it.
Oracle’s Unified Memory Core, announced on March 24, is a single ACID-transactional engine that processes vector, JSON, graph, relational, spatial, and columnar data without a sync layer. As VentureBeat reported, the product targets a specific failure mode: “Agents built across a vector store, a relational database, a graph store and a lakehouse require sync pipelines to keep context current. Under production load, that context goes stale.”
Maria Colgan, VP of Product Management at Oracle, told VentureBeat: “By having the memory live in the same place that the data does, we can control what it has access to the same way we would control the data inside the database.”
Oracle also shipped an Autonomous AI Database MCP Server that lets external agents connect directly, with Oracle’s row-level and column-level access controls applying automatically. The company’s architectural pitch to enterprises is that memory governance should inherit from existing database security policies rather than requiring a separate governance layer.
Holger Mueller, principal analyst at Constellation Research, told VentureBeat the argument is credible “precisely because other vendors cannot make it without moving data first.” Not everyone agrees. Steven Dickens, CEO of HyperFRAME Research, told the same outlet that “vector search, RAG integration and Apache Iceberg support are now standard requirements across enterprise databases.”
The Gap Between Them
Microsoft’s approach gives platform teams control over memory lifecycle but introduces dependency on the Foundry runtime. Oracle’s approach inherits existing database security but requires enterprises to consolidate their data tier. Neither solves the problem for teams running multi-cloud or framework-agnostic agent stacks.
That gap is where the startup ecosystem lives.
The Open-Source Memory Stack
At least six open-source frameworks are competing to provide agent memory as a standalone capability, independent of any single cloud platform.
Mem0 is the most widely adopted, with roughly 48,000 GitHub stars and a multi-store architecture combining vector search, graph relationships, and key-value storage. Backed by a $24.5 million Series A led by Basis Set Ventures in October 2025, Mem0 provides user-level, session-level, and agent-level memory scopes. Its integration as the exclusive memory provider for AWS’s Agent SDK gives it enterprise distribution that most open-source projects lack.
Letta (formerly MemGPT) takes a fundamentally different approach, treating the LLM like an operating system managing its own memory. There is a “main context” (the active prompt, analogous to RAM) and a “recall storage” (long-term, analogous to disk). The agent itself decides what stays in working memory versus what gets paged out. This OS-inspired tiered architecture is designed for long-running agents that need unbounded memory without hitting context window limits. Letta has roughly 21,000 GitHub stars.
Zep (and its Graphiti subproject) emphasizes temporal knowledge graphs — entity relationships that change over time. When Alice was the budget owner until February and then Bob took over, Zep’s temporal graph can represent that transition as a time-bounded fact rather than overwriting one with the other. This matters for enterprise workflows where historical accuracy is as important as current state. Zep has roughly 24,000 GitHub stars across its projects.
Cognee focuses on knowledge-graph-first RAG workflows with roughly 12,000 stars. Hindsight, a newer entrant, is growing quickly with a multi-strategy hybrid architecture designed for institutional knowledge.
The Vectorize.io comparison draws a useful distinction between two classes of memory problem: personalization (remembering who the agent is talking to) and institutional knowledge (remembering how to do the job). Mem0 and Zep are strongest on personalization. Letta handles both through its tiered architecture. Cognee and Hindsight emphasize institutional knowledge. No single framework does everything well.
The Governance Problem Nobody Has Solved
Persistent memory introduces governance problems that ephemeral sessions avoid entirely. If an agent remembers user preferences across sessions, who owns that data? How long should it be retained? What happens when a user requests deletion under GDPR or CCPA?
Microsoft’s architecture addresses isolation through Entra ID partitioning. Oracle inherits row-level security from the database. But AI-360’s analysis of Oracle’s release identifies a harder problem: memory poisoning. If an agent’s memory can be updated by external inputs, an attacker who corrupts the memory store can influence every subsequent interaction without touching the model itself.
The DasRoot.net technical analysis of long-running assistant architectures highlights the operational dimension: persistent memory requires fault tolerance, backup and recovery, and consistency guarantees that ephemeral sessions never needed. An agent that loses its memory mid-workflow is potentially worse than one that never had memory at all — it has partial context that may be stale or contradictory.
For regulated industries (healthcare, finance, government), memory adds another compliance surface. Agent memory stores are subject to the same data residency, retention, and audit requirements as any other data store containing personal information. None of the current frameworks ship with built-in compliance certification, though Microsoft’s Cosmos DB backend and Oracle’s database both inherit their parent platforms’ compliance posture.
What This Means for Builders
The agent memory space in April 2026 looks like the container orchestration space looked in 2015: multiple competing architectures, no consensus on where the abstraction layer belongs, and every major vendor placing a different bet.
If you are building agents on Azure, Microsoft’s Foundry persistent memory architecture is the lowest-friction path. If your data tier is Oracle, the Unified Memory Core eliminates a sync layer. If you are multi-cloud or framework-agnostic, Mem0 is the most proven standalone option. If your agents need unbounded long-running memory, Letta’s OS-inspired tiered architecture is purpose-built for that use case.
The deeper question is whether agent memory will consolidate into platform services (the way container orchestration consolidated into Kubernetes) or remain a fragmented stack where teams assemble their own combination of vector stores, graph databases, and memory extraction pipelines. The answer probably depends on whether any single architecture proves clearly superior under production load — and as of this week, that experiment is just beginning.