What Is GBrain? Garry Tan's AI Agent Memory Tool, Explained
Last updated: July 14, 2026
GBrain is an open-source memory layer for AI agents — a persistent "brain" an agent can read from and write to, so it stops forgetting everything between sessions. Garry Tan, the president and CEO of Y Combinator, built it to run his own agents and released it under an MIT license. It has since become one of the more prominent projects in the agent ecosystem: roughly 26,000 GitHub stars, a very fast release cadence, and a growing role in the world around OpenClaw, the open-source agent framework we've written about before.
If the name keeps surfacing in your feed, the reasons are straightforward: a high-profile builder, a real problem — AI systems that wake up amnesiac every morning — and a project that ships fast enough to stay in the conversation. What's harder to find is a plain-English account of what GBrain actually does, how it works under the hood, and where its limits are.
That's this post. One thing to state clearly up front: WestStack has no affiliation with GBrain, Garry Tan, or Y Combinator. We build AI systems for wealth management firms, we evaluate tools like this as part of that work, and what follows is an independent look — including the parts a regulated firm should be skeptical about.
What GBrain actually is
Every AI agent has the same structural weakness: the model at its core retains nothing between sessions. Whatever it learned about your clients, your projects, or your preferences yesterday is gone today unless something outside the model stored it. GBrain is that something — a knowledge store the agent writes into as it works and reads from when it needs context, accumulating understanding over months instead of resetting every run.
What separates it from an ordinary search index or a standard RAG pipeline is what comes back when you ask a question. Search — keyword or vector — returns a list of documents that might contain your answer. GBrain's query path is built to return the answer itself: a synthesized response assembled from everything relevant in the store, with citations pointing back to the underlying pages, and — the underrated part — an explicit account of what it couldn't find. The project calls this gap analysis, and it changes the character of the tool: a system that says "here's what I know, here's where it came from, and here's what's missing" is doing something search never did.
The difference is easiest to see in a workflow every advisory firm knows. Ask a search tool "what do I need to know before tomorrow's review with the Hendersons?" and you get fourteen documents that mention Henderson, ranked by relevance — the reading and the assembling are still your job. Ask a memory layer like this and you get a brief: where the relationship stands, what's changed since the last review, the two action items still open from March, each point cited to its source note — plus a flag that nothing in the store addresses the estate-planning question raised in the spring. Knowing what the system doesn't know is often worth more than what it does.
This isn't a toy scale, either. Tan runs his own instance against a working corpus of roughly 147,000 pages spanning about 25,000 people and 5,000 companies — it's the memory behind agents he actually operates, which explains a lot about how pragmatic the design choices are.
How it works
Three mechanisms do most of the work, and they're worth understanding separately because each solves a different failure mode of AI memory.
The synthesis layer
Under the hood, retrieval is hybrid: semantic (vector) search and classic keyword search run together, their results are fused and re-ranked, so conceptual matches and exact names both surface. That part is table stakes in 2026. The differentiator is the step after retrieval — instead of handing the agent raw chunks, GBrain composes a cited answer in prose and appends the gap analysis described above. It exposes both modes separately: a raw search when you want the list, and a "think"-style query when you want the synthesized answer.
The self-wiring knowledge graph
Every time something is written into the brain, GBrain extracts typed relationships from it — who works at which company, who invested in what, who advises whom — and wires them into a knowledge graph automatically. Notably, it does this with pattern matching rather than extra model calls, so the graph builds itself on every write at effectively zero cost.
The graph is what lets it answer relational questions that similarity search fundamentally can't. "Which of our contacts are connected to this company, and through whom?" is a graph traversal, not a semantic match. On the project's own 240-page evaluation corpus, the published benchmarks report recall@5 of 97.9% and credit the graph signals with a 31.4-point precision improvement over the identical system with the graph disabled. Those are self-reported numbers on the project's own test set — treat them as a statement of what the design optimizes for, not an independent audit — but the architectural point stands: hybrid search plus a free knowledge graph answers a class of questions vector-only RAG misses.
The overnight enrichment cycle
Knowledge bases rot. Notes duplicate, citations break, and two entries quietly contradict each other. GBrain's answer is a scheduled background process — the project calls it the "dream cycle" — that runs maintenance while nobody is using the system: deduplicating pages that say the same thing, repairing citations, surfacing contradictions between entries, and preparing tasks for the next day. Treating knowledge hygiene as an automated, first-class job rather than a human chore is one of the quietly smart decisions in the design.
Two more properties matter for anyone evaluating it. First, it's MCP-native: GBrain ships a Model Context Protocol server exposing more than 30 tools, so it plugs directly into Claude Code, Cursor, Claude Desktop, ChatGPT, and other MCP clients. Second, it's local-first: it runs on your own hardware against your own database — an embedded zero-setup Postgres for personal use, or a full Postgres instance for larger deployments — with your own API keys, and the knowledge itself lives as plain markdown files in a git repository you control. Your accumulated memory is never hostage to a vendor.
The company brain angle
The most interesting recent direction is multi-user mode. Instead of one brain per person, a team shares a single institutional brain with per-person scoping: each user's access is tied to their login, and every query — search, listing, lookup — sees only what that user is permitted to see. The project describes this as a "company brain" for teams of roughly ten to fifty people, and says the access boundaries are fuzz-tested against leaks.
That framing isn't accidental. "Company brain" is one of Y Combinator's Requests for Startups — the list of ideas YC explicitly wants founders building. When the president of YC open-sources his own take on the memory layer underneath that idea, it tells you where a meaningful part of the industry believes agent infrastructure is heading: away from per-employee chatbots and toward a shared, permissioned institutional memory that every agent and every person in the firm works against.
An institution's accumulated knowledge, queryable by anyone with the right permissions and forgotten by no one — that is precisely the shape of the problem wealth management firms have. We'll come back to it.
An honest assessment
The genuinely strong parts:
- The synthesis-plus-graph combination is a real differentiator. Most memory tools are search with better marketing. Returning composed, cited answers with an explicit account of gaps — backed by a relationship graph that builds itself — is a different and more useful contract.
- Development pace. The project moves quickly, with steady releases and visible responsiveness to issues. It is clearly a living project, not an abandoned experiment.
- Local-first architecture. Your data sits in your database, as readable markdown in your git repo, under an MIT license. There is no vendor to be locked into and no SaaS boundary your knowledge has to cross.
The parts that warrant care:
- It's young and moving fast. The version line (0.41.x at the time of writing) turns over constantly. That's healthy for an open-source project, but it means guides go stale, behavior shifts between releases, and upgrades are your responsibility.
- Self-hosting is real operational work. A database, sync schedules, background enrichment jobs, embedding and reranking API keys, upgrade management — someone has to own all of it. "Free and open source" is the license, not the total cost.
- The benchmarks are the project's own. Useful signal, not independent verification.
- A regulated firm has open questions to answer before production use. The per-user access scoping is fuzz-tested, but the repo doesn't reference a third-party security audit. Auditability needs design: can you reconstruct after the fact why the system said what it said, and who saw it? And data governance is on you — retention, deletion, and the fact that the default configuration uses hosted embedding and reranking providers, meaning fragments of your data transit third-party APIs unless you deliberately configure local models.
None of this is disqualifying. It's the normal profile of an ambitious open-source project about eighteen months ahead of its enterprise packaging — impressive core ideas, sharp edges where a regulated buyer needs smooth ones.
What GBrain means for wealth management firms
Strip away the agent-ecosystem context and GBrain is a working prototype of something wealth firms have wanted for decades: institutional memory that doesn't live in one person's head.
Memory across advisors, not per advisor. Client context, meeting history, the reasoning behind decisions — today that knowledge sits in CRM fragments, inboxes, and the senior advisor's memory, and it walks out the door when they retire. A shared brain that accumulates this context, synthesizes it on demand ("brief me on this household before the 2 p.m. review"), and tells you what's gone stale is the compounding version of institutional knowledge.
Per-user scoping is the right shape for client data. In a firm, not everyone should see every household. A memory architecture where access is scoped per person against a shared store — rather than bolted on afterward — is at least the correct starting geometry for an industry built on confidentiality walls.
Local-first aligns with the compliance boundary. Client and portfolio data staying in infrastructure you control, in inspectable plain-text form, is a far better fit for a regulated firm than shipping your institutional memory to a third-party SaaS. It's the same principle that leads firms toward private deployments elsewhere in their AI stack — the direction we've argued for in personal AI infrastructure for wealth management.
And the honest gap: an open-source tool is a starting point, not a deployable system for a regulated firm. Between GBrain-as-cloned-from-GitHub and GBrain-as-production-infrastructure sits a security review, access design that maps to your actual permission structure, integration with the systems that hold real client data, and an audit trail your compliance function will accept. That connective layer — wiring AI tools securely into a firm's systems with access controls and audit trails — is the category of work WestStack does; our MCP integrations practice covers how we approach it.
FAQ
What is GBrain?
GBrain is an open-source memory system — a "brain" — for AI agents, storing what an agent learns as searchable, interconnected knowledge. Unlike plain search, it answers questions with synthesized, cited responses and flags what it doesn't know, rather than returning a list of matching documents.
Who made GBrain?
Garry Tan, the president and CEO of Y Combinator, built GBrain to serve as the memory layer for his own AI agents. It's published under his personal GitHub account as an open-source project rather than as a Y Combinator product.
Is GBrain free?
Yes — it's open source under the MIT license, and it runs on your own hardware and database. Running it isn't zero-cost, though: you supply the infrastructure, the operational attention, and API keys for embedding and reranking providers unless you configure local models.
Is GBrain safe for business data?
Its local-first design keeps your data in infrastructure you control, which is a strong starting point, and multi-user deployments scope access per person. But there's no published third-party security audit, and the default setup sends data fragments to hosted embedding providers — so a firm handling sensitive client data should do its own security review, access design, and governance work before production use.