AI Agent Memory Systems Compared: Vertex AI, Azure Foundry, and GBrain in 2026

TL;DR

• Four names dominate the AI agent memory conversation in 2026: Vertex AI Sessions, Vertex AI Memory Bank, Microsoft (formerly Azure) Foundry Memory, and the open-source GBrain project. They are not competitors. They sit at different layers of a single pipeline: raw events, extracted memories, curated knowledge.
• Memory is not RAG. RAG retrieves static documents. Memory is written by the system itself, which means it can contradict itself, and something has to resolve that.
• The real decision points are not feature lists. They are: what counts as a memory, who writes it, how contradictions get resolved, whether the system scales to millions of identities, and whether you can see and delete what it knows.
• Standardized benchmarks like LoCoMo, LongMemEval, and BEAM now let teams compare architectures on the same ground truth, but vendor-reported scores still don’t tell you how a system will behave on your data.
• Memory poisoning, vendor lock-in, and “intelligent forgetting” remain unsolved problems across every platform on this list.

The Bug Your Agent Forgot By Wednesday

Your agent walks a support engineer through a nasty production incident on Tuesday. Root cause, ruled-out theories, the fix that finally worked. All of it, gone by Wednesday morning.

The engineer opens a new session. The agent has no idea who they are, what service they’re talking about, or that the connection pool was already cleared as a suspect the day before.

You’ve probably tried the obvious fix already: dump the old transcript back into the prompt.

It works, for about a week. Then token costs climb, responses slow down, and the model starts burying the one relevant line from Tuesday under a thousand irrelevant ones from three other conversations. This is the failure mode researchers now call context rot, and as the amount of information fed into an LLM grows, especially with irrelevant or misleading details, the quality of the model’s output significantly declines.

That’s the gap that turned AI agent memory systems comparison into a real infrastructure question rather than a side effect of a longer context window.

Four names keep coming up in that conversation: Vertex AI Sessions, Vertex AI Memory Bank, Azure (now Microsoft) Foundry Memory, and GBrain, the open-source project that came out of Y Combinator. People compare them like they’re rival products competing for the same job.

They aren’t. Each one answers a different question about what an agent is allowed to remember, and mixing them up is how teams end up building the wrong thing.

Memory is not RAG. A RAG corpus is authored somewhere else and read from at query time. Memory is authored by the system itself, based on what happened. That single difference is why memory systems have to deal with contradictions, and document stores don’t.

Memory Isn’t One Thing. It’s a Spectrum.

Short-term memory is the whiteboard

Short-term memory is everything the agent needs for the task in front of it right now: the current messages, the tool calls it just made, the intermediate results of a multi-step job. Long-term memory is the externalization of state into a durable storage system, while short-term memory lives in the “hot” path of your application and disappears when the task ends, the way a whiteboard gets erased after a meeting.

Long-term memory is what should survive the erase

Long-term memory keeps the handful of facts actually worth carrying forward: a user’s preferences, a decision that was already made, a procedure that worked last time. Semantic memory provides the facts, episodic memory offers lessons from experience, and procedural memory ensures smooth execution, and production memory systems increasingly treat those as three distinct categories rather than one undifferentiated blob.

Why memory and RAG keep getting confused

RAG (Retrieval-Augmented Generation, the technique of pulling documents into an LLM’s context at query time) and agent memory look similar on the surface. Both use vector search. Both add context the base model didn’t have. That’s where the similarity ends.

One of the most overlooked differences between agent memory and RAG is the write path. RAG is fundamentally read-only. You index documents once, then query. The data doesn’t change based on interactions.

Memory is different by design: when an agent stores a memory, the system must extract discrete facts, resolve entities, track temporal validity, update existing knowledge, not just append, and build relationships between entities.

Nobody expects a PDF to rewrite itself because a user had a conversation. But once a system starts authoring its own memories, contradictions aren’t a bug. They’re inevitable.

You told the agent you were vegetarian in March. You ordered a steak in July. Both statements are true, in their own moment. The hard part was never storing both. The hard part is deciding what gets kept, what gets overwritten, and what gets quietly retired.

A Pipeline, Not a Leaderboard

Think of agent memory as three stages: raw events, extracted memories, curated knowledge. Each of the four systems occupies a different stage.

Vertex AI Sessions: the transcript

Sessions is the floor everything else stands on. A session contains the chronological sequence of messages and actions for an interaction between a user and your agent, scoped to that session, and events, such as user messages, agent responses, or tool actions, are saved to the memory bank using AppendEvent.

By itself, Sessions doesn’t decide what matters. It just makes sure nothing that happened gets lost before something smarter can look at it. If you already run your own extraction and consolidation logic, Sessions can be the reliable transcript layer underneath it and nothing more.

Vertex AI Memory Bank: automated extraction at user scale

Memory Bank picks up where Sessions leaves off. It is a fully managed, cloud-native service that handles sophisticated, persistent memory for conversational agents, going beyond simple storage by providing intelligent memory management, consolidation, and retrieval capabilities.

The extraction isn’t instant. Memory generation uses LLM-based extraction from conversation history, and memories are remotely generated asynchronously, so the agent doesn’t need to wait for memories to be generated. Every memory is also tied to a specific person: memories are scoped to a specific user_id, ensuring privacy and isolation, so each user has their own isolated collection of memories, preventing cross-user contamination.

Contradictions get handled automatically, too. Memory Bank consolidates newly extracted information with existing memories, allowing memories to evolve as new information is ingested, recognizing when new information refines or updates existing facts, rather than just stacking duplicate statements on top of each other.

Google prices this by volume rather than by seat: Memory Bank, part of Agent Engine, follows an event-based model at $0.25 per 1,000 session and memory events. That structure only makes sense if you’re operating at a scale where nobody could manually review what’s being remembered anyway.

Microsoft Foundry Memory: three memory types, deliberately kept separate

Azure AI Foundry has since been folded into the broader Microsoft Foundry brand, and its memory layer takes the most structured approach of the four. Instead of one memory type, it maintains three: user profile memory for durable preferences and personal context, chat summary memory for prior conversation continuity, and procedural memory for reusable how-to routines.

Procedural memory is the interesting one. It’s the difference between an agent that knows who you are and one that’s learned how your team actually gets work done. That distinction matters more the longer an agent runs in production, because facts about a user go stale slowly, but a workflow that changed last quarter needs to be forgotten fast.

Developers get two ways in: calling search_memories with the latest messages, which returns both user profile and chat summary memories most relevant to the given items, or working through low-level CRUD-style memory item operations when finer control is needed.

Two caveats matter for anyone evaluating this seriously. First, memory is currently in public preview, and pricing and billing for memory and the Memory Store API can change during preview. Second, virtual network integration isn’t supported for memory stores yet, which is a real constraint for regulated deployments that require VNet isolation. Microsoft has also started publishing guidance on treating memory as an attack surface, not just a convenience feature: procedural memory needs the strictest treatment because it can change how the agent performs future workflows or uses tools, and the key design pattern is routing, not just blocking.

GBrain: memory you can actually read

GBrain is the outlier, and deliberately so. It’s a markdown-first, Postgres-backed knowledge brain that converts a git repo of Markdown files into a hybrid-searchable memory for AI agents, exposing CLI/MCP tools so agents can read and write memory. That two-directional read/write exposure is conceptually close to how a well-designed agent API works, giving an agent structured access in both directions rather than a one-way retrieval call. Retrieval combines multiple techniques rather than betting on one: hybrid retrieval combining keyword search, vector search, and reciprocal rank fusion, plus a compiled “truth” header and append-only timeline per page, with nightly dream cycles for entity enrichment.

The origin story matters for understanding what it’s built for. Every night while Garry Tan sleeps, an AI agent reads his meetings, emails, and tweets, files them into a knowledge base, and rewires the links between them; he open-sourced it in April 2026, days after Andrej Karpathy seeded the idea publicly, and it became the reference design for the whole “company brain” movement. The scale it runs at in production is notable for a system built by one person for personal use: the production brain behind Garry’s actual agents currently holds 146,646 pages, 24,585 people, 5,339 companies, and 66 autonomous cron jobs.

But an honest review found a real limitation baked into that design. GBrain’s overnight maintenance keeps the brain organized. It does almost nothing to keep it true. That gap, between tidy and trustworthy, is the most interesting thing about it. One engineer who tried adapting it for a team rather than a single person put it plainly: it felt “way too focused on single player.”

Running it isn’t free even though the license is: running a GBrain-style memory layer costs roughly $4 per user per month for a small team and $8 to $15 per user per month with heavier use, once you account for embeddings, storage, and the models doing the nightly maintenance work.

Comparing Vertex Sessions to GBrain is like comparing a write-ahead log to a wiki. Both hold information. Neither one is trying to do what the other does.

How the Four Actually Stack Up

Here’s how the four systems compare across the dimensions that actually determine fit, not just the dimensions that make a good marketing slide.

Feature-by-Feature Comparison

The Five Questions That Actually Decide This

Feature checklists are a distraction. These five questions aren’t.

What counts as a memory? An event, an extracted fact, a typed profile field, or a Markdown page in a graph. The answer decides how the system stores, scopes, and deletes information, and it’s why comparing these four on a spec sheet misses the point.

Who writes the memory? Automatic extraction scales to millions of users but trades away visibility. Human or agent curation gives you control at the cost of ongoing maintenance work. There’s no universally correct answer, only the right one for your user count and your risk tolerance.

How does it handle contradictions? This is where most comparisons stop too early. A customer who preferred email in January and demands phone-only contact by June isn’t lying either time. Memory Bank and Foundry Memory try to resolve this automatically through consolidation. GBrain leaves it to whoever’s curating the brain. Neither approach is wrong, but picking the wrong one for your context is how agents start confidently repeating stale information.

Can it support many users, or is it built for one? Multi-tenant systems need strict identity isolation so memory scoping does not let one user’s context leak into another user’s response. GBrain assumes one brain, owned by one person or one trusted team. That single assumption rules it out for a SaaS product with ten thousand end users and rules it in for an internal team that wants to see exactly what their agent knows.

Can you see, audit, and delete what it knows? This is the compliance question hiding inside a technical one. Can a memory expire automatically? Can an admin audit the store? Managed platforms offer TTLs and delete APIs. GBrain’s answer is more direct: the memory is a file. You can open it.

Matching the System to the Problem You Actually Have

Running a consumer or SaaS product with a large, growing user base? Memory Bank or Foundry Memory. Manual curation isn’t an option at that scale, and automatic extraction with user-level isolation is the only approach that holds up.

Already committed to the Microsoft ecosystem? Foundry Memory’s typed categories, especially procedural memory, fit naturally into agents that need to learn how your organization works, not just remember facts about individual users. Weigh its preview status and the current VNet limitation against your regulatory timeline before committing production traffic to it.

Building for yourself or a small, trusted team? GBrain’s transparency is the actual feature. Being able to open a file and see exactly what your agent believes is worth more than automated extraction when the team maintaining it is small enough to actually do the maintaining. If you’d rather not run your own Postgres instance and Git repo to get there, a managed alternative like Cognis, Lyzr‘s production-grade memory layer for AI agents, which gives every agent the ability to recall what matters, update knowledge on the fly, and stay consistent across every conversation, session, and deployment, covers similar ground as an installable Python library rather than a self-hosted stack.

Already built your own extraction and consolidation logic? Sessions is probably enough. Paying for a smarter memory layer on top of a pipeline you’ve already built is redundant, not additive.

If you’re still deciding how memory fits into your broader agent stack rather than which vendor to pick, it’s worth reading through how agents must retain both short-term conversational state and long-term organizational knowledge, since persistent memory allows an underwriting agent that misclassifies a claim today to avoid repeating the same mistake tomorrow, before locking in an architecture.

What Nobody Has Actually Solved

The category moved fast in 2026. It didn’t move fast enough to close these gaps.

There’s no neutral scoreboard, but there’s finally a shared one

For years, every vendor measured memory quality its own way, which made comparison meaningless. That’s changing: the most significant development in AI agent memory research is the emergence of standardized benchmarks that enable comparison of fundamentally different memory architectures on the same evaluation set, with three benchmarks, LoCoMo, LongMemEval, and BEAM, now defining the measurement landscape. That’s real progress. It still doesn’t tell you how a system behaves on your users, your domain, your edge cases.

Graph memory stopped being optional

Graph memory in AI agents was largely experimental in 2024. By 2026, the production pattern had changed: memory systems are moving beyond pure vector similarity. Vector memory retrieves semantically similar facts. Graph-style memory retrieves facts through entities and relationships. Both are useful; neither is sufficient alone. Every system on this list except plain Sessions has, or is building toward, some version of that combination.

Memory poisoning is not a hypothetical

When an agent writes its own memories, a single bad conversation can leave a permanent mark. A prompt injection that would have been a contained, one-off failure in a stateless system becomes a persistent liability once the resulting bad information gets stored and retrieved in every future session. The more automatic the extraction, the more the inputs and updates need governance, not less.

Portability is basically nonexistent

Move your agent from one cloud to another and its accumulated memory generally doesn’t come with it. There’s no shared interchange format across Vertex, Foundry, and the open-source ecosystem. Human-readable formats like GBrain’s Markdown files have a real, if narrow, advantage here: at minimum, you can read what you’re leaving behind.

Forgetting is still a blunt instrument

A time-to-live counter treats a fact mentioned once two years ago the same as a preference reinforced weekly. Human memory doesn’t work that way, and neither should a system built to imitate judgment. Relevance, recency, confidence, and change all need to factor into what gets forgotten, and none of the four systems here have fully solved that yet.

Frequently Asked Questions

What is the difference between short-term and long-term AI memory?

Short-term AI memory is session-scoped, lives in the context window, and resets when the conversation ends. Long-term AI memory lives in external stores, vector databases, knowledge graphs, and persists across sessions and agents. The deeper distinction is governance: short-term memory tolerates unverified information because it disappears with the session, while long-term memory needs review before it becomes part of what the agent believes permanently.

Is RAG the same as agent memory?

No. An AI memory system is stateful persistence: it stores context, user history, learned facts, prior decisions, across sessions and recalls it on demand. RAG answers “what does the document say?” Memory answers “what has the agent learned?” RAG is read-only by design; memory has to write, update, and reconcile.

What is Vertex AI Memory Bank?

Vertex AI Memory Bank is a fully managed, cloud-native service that handles sophisticated, persistent memory for conversational agents, going beyond simple storage by providing intelligent memory management, consolidation, and retrieval capabilities. It extracts facts from conversation history asynchronously and scopes them to individual users.

Is Azure/Microsoft Foundry Memory available for production use?

Not yet at full stability. Memory is currently in public preview, and pricing and billing for memory and the Memory Store API can change during preview. Teams evaluating it for regulated workloads should also account for the current lack of VNet support for memory stores.

How do AI agents handle contradictory memories?

It depends on the system. Managed platforms like Memory Bank and Foundry Memory try to consolidate conflicting facts automatically, recognizing when new information should update or replace an older statement rather than sit alongside it. Curated systems like GBrain leave that judgment call to whoever maintains the knowledge base, which trades automation for a human check on what’s actually true.

What is memory poisoning in AI agent systems?

Memory poisoning happens when incorrect or maliciously injected information gets written into an agent’s persistent memory and then reused across future sessions, turning what would have been a one-time mistake into a recurring one. Microsoft’s own guidance treats this as a security problem requiring different levels of validation depending on how broad a memory’s scope is, with procedural memory needing the strictest controls because it can change how an agent behaves in future tasks.

What is GBrain?

GBrain is Garry Tan’s open-source AI memory system for agents. It stores knowledge as markdown files, adds search and graph structure around those files, and gives agents a persistent brain they can read before responding and update after learning something new. It’s designed around one person or one team owning and curating the brain, rather than serving isolated memories to a large, anonymous user base.

The Real Question Isn’t Which One Wins

It’s not “which memory system is best.” It’s what your agent actually needs to remember, how much control you’re willing to give up for scale, and who’s accountable when the memory is wrong.

Vertex AI Sessions preserves what happened. Memory Bank decides what mattered. Foundry Memory organizes that into categories an enterprise can govern. GBrain turns it into something a human can open and correct.

Before you pick one, write down the actual failure case you’re trying to prevent. Is it a user re-explaining their preferences for the tenth time? A workflow that keeps breaking the same way? A compliance officer asking what your agent knows about a specific customer, and needing an answer today?

That failure case, not a comparison table, is what should decide the architecture.

Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here