What is GBrain? Inside Garry Tan's open-source AI memory system — the markdown brain, hybrid search, self-wiring graph, and dream cycle — plus an honest review of what it gets right and where it falls short.
Stay updated
Get notified when we publish new research on AI memory and agents.
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.
Garry Tan, who is YC president, released the personal memory layer behind his OpenClaw and Hermes agent workflows. Plenty of people keep notes repos. GBrain earns attention for the operating loop it wraps around them: read before responding, write after learning, consolidate overnight.
This post explains what GBrain is and how it works, then reviews it honestly: what it gets right, where it falls short, what day one actually looks like, and who should (and shouldn't) run it.
GBrain is a local-first memory layer for AI agents. Its source of truth is plain-text markdown in a Git repo. Around that repo, it adds local indexes, semantic retrieval, exact-match retrieval, typed entity links, agent tools, and background jobs that turn files into long-term working memory.
The GBrain GitHub repo describes it as the production brain behind Tan's own agent deployments. As of July 2026, the README lists more than 146,600 pages, 24,000 people, and 5,000 companies in his setup, and the project has moved fast — v0.41 at last check, with releases adding multimodal ingestion, session capture, and an autonomous "minions" job system. Those numbers will change. The pattern is the part worth studying.
If you want the review in one paragraph: GBrain is the most complete open-source reference design for agent memory available today, and it is genuinely opinionated software — local-first, markdown-owned, agent-operated. It is not a product you hand to a non-technical team, and it is young enough that you should expect breaking changes between releases. Run it if you are technical and want to own your memory layer. Skip it if you need a hosted service or multi-user governance.
| Dimension | Score | Notes |
|---|---|---|
| Architecture | ★★★★★ | Hybrid retrieval + typed graph + timeline is the right shape |
| Retrieval quality | ★★★★☆ | Graph layer adds +31.4 P@5 points over vector-only in its own benchmark |
| Setup experience | ★★★★☆ | 2-second local init; full agent-driven install takes ~30 minutes |
| Stability | ★★★☆☆ | Fast-moving v0.x project; expect breaking changes |
| Team/multi-user use | ★★☆☆☆ | Company-brain support is early; governance is not solved |
| Fit for non-technical users | ★☆☆☆☆ | Requires Git, a CLI, and an agent platform |
GBrain has a simple but opinionated architecture:
| Layer | What it does |
|---|---|
| Markdown repo | Human-readable source of truth for notes, people, companies, meetings, ideas, and tasks |
| Database index | Local query layer for fast search over the markdown brain |
| Semantic search | Finds conceptually related pages and chunks |
| Exact-match search | Catches exact names, dates, phrases, and entities |
| Rank fusion | Combines lexical and semantic results into a better ordered list |
| Knowledge graph | Tracks typed relationships like works_at, founded, invested_in, attended, and advises |
| Agent tools | Lets local agents query or update the brain |
| Background jobs | Enrich, repair, consolidate, and sync memory while the user is offline |
That structure is why GBrain goes beyond RAG over personal notes. RAG retrieves relevant chunks. GBrain tries to maintain a working memory system: it can synthesize answers with citations instead of returning raw chunks, and company-brain support adds scoped access for team memory.
The company-brain part deserves a pause. A personal brain and a company brain are different problems. Once a memory system spans a team, permissioning, provenance, stale information, and conflicting facts become product requirements, not nice-to-haves.
GBrain uses hybrid retrieval because no single search method is enough.
Exact-match search is good for names, emails, company names, dates, and phrases. Semantic search is good when the user asks conceptually similar questions in different words. Graph traversal is good when the question depends on relationships rather than document similarity.
The repo and technical writeups describe a layered retrieval stack: lexical search, semantic search, rank fusion, reranking, graph signals, and explainability commands such as gbrain search --explain.
The practical version:
Yash GoyalUser asks a question
-> lexical search catches exact matches
-> semantic search catches fuzzy matches
-> graph links catch relationships
-> ranking combines the signals
-> synthesis writes an answer with citations and gaps
This is the right shape for agent memory. An agent answering a real question needs the current answer, the evidence behind it, and a note about what's missing — "relevant chunks" alone leave it guessing.
The graph is the most interesting part of GBrain.
A flat vector store can tell you which pages are similar to a query. Two examples show where that breaks down:
GBrain automatically creates typed edges when pages are written. Examples include works_at, founded, invested_in, attended, advises, and mentions. That gives the memory system a shape closer to how work actually happens: people connect to companies, companies connect to meetings, meetings connect to decisions, and decisions connect to follow-ups.
The strongest design pattern in GBrain is the split between compiled truth and timeline.
A person page might look like this:
---
type: person
title: Alice Chen
---
Founder of Acme AI. Met through YC. Hiring infrastructure engineers.
Interested in agent memory and internal knowledge systems.
---
- 2026-04-05: Intro call about agent memory architecture
- 2026-04-19: Follow-up email about hiring infra engineers
- 2026-05-02: Mentioned Acme is testing company-wide AI workflows
Above the separator is compiled truth: the current working understanding. Below it is the timeline: dated evidence that explains why the brain believes that thing.
That split is underrated. Most memory systems store facts without preserving why the system believes them. When facts change, the agent has no clean way to update its belief. GBrain keeps the answer and the evidence in the same page but gives them different roles.
GBrain's most memorable feature is its background maintenance loop. It ingests and cleans up knowledge while the user is not actively chatting.
The public docs describe the brain ingesting meetings, emails, tweets, voice calls, and ideas, then enriching people and company pages, repairing citations, and consolidating memory overnight.
That sounds small until you compare it to normal AI usage. Most AI tools wait for the user to paste context again. GBrain flips the model: the system keeps working in the background so the next interaction starts with better context.
This is where the "agent memory" label becomes real — a folder of notes only becomes memory once something maintains it.
GBrain is especially relevant because it is built for agent workflows, not just human note search.
The repo positions it as the brain behind Tan's local agent workflows. It also exposes tools so coding agents and local agent clients can query, read, and write memory.
That matters because the integration point decides whether memory compounds. If the memory layer sits outside the agent loop, the user has to manually paste context. If the memory layer is inside the loop, the agent can read before acting and write after learning.
A simple brain-agent loop looks like this:
Signal arrives: meeting, email, tweet, note, voice call, calendar event
-> detect entities: people, companies, ideas, projects
-> read the brain before responding
-> answer with context
-> write new facts back to the brain
-> sync and index changes for the next query
This loop matters more than any individual database choice: an agent that reads before acting and writes after learning starts every session ahead of where the last one ended, which is what makes the memory compound.
The GitHub README points to BrainBench results on a 240-page rich-prose corpus: precision@5 of 49.1% and recall@5 of 97.9%, with the graph layer contributing a +31.4-point precision lift over the graph-disabled variant. The exact benchmark should be read in context — it is GBrain's own harness, published in the sibling gbrain-evals repo — but the direction is important: a +31-point lift means the graph layer is doing real retrieval work, well beyond what search alone manages.
That matches the intuition. The hard questions in real work are often relational — "what should I know before this meeting?" spans people, companies, timelines, obligations, and stale context, which nearest-neighbor search on its own can't traverse.
GBrain is unusual in that it is designed to be installed by an AI agent, not just used by one. The README's recommended path is to paste a single instruction into your agent:
Retrieve and follow the instructions at:
https://raw.githubusercontent.com/garrytan/gbrain/master/INSTALL_FOR_AGENTS.md
The agent clones the repo, creates the brain, asks for API keys, loads 43 skills, configures the dream cycle, and verifies the install. The README budgets about 30 minutes, and that matches reports from early users. It works with Claude Code, Codex, Cursor, and OpenClaw/Hermes deployments.
If you just want memory for a coding agent, the minimal path is two commands and needs no Docker or server:
gbrain init --pglite # 2-second local brain
claude mcp add gbrain -- gbrain serve # expose 30+ MCP tools to your agent
There is also a standalone CLI path (bun install -g github:garrytan/gbrain, then gbrain init, gbrain doctor, gbrain import ~/notes/) and a Postgres/Supabase path for larger setups.
Two practical notes from day one. First, the brain starts empty: gbrain import on an existing markdown folder (Obsidian and Logseq vaults work) is the difference between useful retrieval on day one and waiting weeks for the agent to write enough pages. Second, this is a fast-moving v0.x project with frequent breaking changes — pin a version if you need stability.
GBrain is designed for technical operators who already run local agent workflows and want control over the memory layer.
Good fit:
Poor fit:
None of that is a knock on GBrain. Tan built it for operators who work the way he does — markdown, Git, local agents — and the constraints follow directly from that choice.
GBrain overlaps with RAG, but treating it as RAG misses the main idea.
| Layer | Vector database | Basic RAG | GBrain-style memory |
|---|---|---|---|
| Storage | Embeddings and metadata | Chunks from documents | Markdown pages plus database indexes |
| Retrieval | Similar vectors | Similar chunks | Lexical search, semantic search, graph traversal, and synthesis |
| Updates | External pipeline | Usually pipeline-based | Agent can read and write memory |
| Evidence | Metadata or source chunk | Source chunks | Timeline entries and citations tied to pages |
| Structure | Mostly document or chunk level | Mostly document-centric | Entity-centric: people, companies, ideas, meetings |
| Time | Weak unless added separately | Often weak | Timeline entries and stale knowledge checks |
The difference is the unit of memory. In basic RAG, the unit is usually a chunk. In GBrain, the unit is closer to a living page about an entity or idea, with evidence below it and relationships around it.
GBrain validates a principle we care about at Gamgee:
Memory that compounds beats memory that just retrieves.
Retrieval is necessary, but it is not enough. A serious agent memory system needs to notice new information, connect it to old information, update current beliefs, preserve evidence, and know when the answer is stale.
That is why GBrain is interesting. It treats memory as infrastructure. The markdown files matter, but the operational system around them matters more: sync, ingestion, enrichment, citation repair, search explainability, graph wiring, and background consolidation.
GBrain gets a lot right, but it also makes the remaining problems easier to see.
| Problem | What it means | How GBrain handles it | What remains hard |
|---|---|---|---|
| Relationship | Facts connect to other facts | Typed links and graph edges | Rich multi-way relationships are still constrained |
| Temporal memory | What was true yesterday may later become stale | Timelines and stale knowledge checks | Deciding which fact supersedes which fact is hard |
| Consolidation | Contradictions must be merged or resolved | Background maintenance and citation repair | Conflict resolution still needs careful review |
| Decay | Memory that keeps growing can drown in noise | Staleness detection helps | Principled forgetting is still unsolved |
| Abstention | The system should know when it does not know | Gap analysis and explicit missing-context notes | Abstention needs retrieval confidence and source coverage, not just prompts |
| Verification | Answers need provenance | Citations and timeline evidence | Full answer-level provenance is still a bigger systems problem |
This is our main takeaway from GBrain. The next generation of agent memory will not be won by the biggest vector database. It will be won by systems that handle relationship, time, consolidation, decay, abstention, and verification as first-class primitives.
GBrain is strongest on relationship, temporal structure, and consolidation.
The entity pages and typed links make relationships visible. The compiled-truth-plus-timeline pattern gives the system a way to separate current belief from evidence. Background maintenance gives memory an operational rhythm instead of leaving it as a passive archive.
The incomplete parts are also clear. Forgetting is still difficult. A brain that keeps growing can become noisy, expensive, or stale. Abstention cannot be solved by telling the model to say "I don't know." It needs retrieval confidence, source coverage, and provenance. Company memory also raises permissioning and governance problems that personal memory can avoid for longer.
These gaps are worth knowing before you adopt it — and they are exactly the dimensions where the next generation of memory systems will compete.
GBrain's markdown pages with typed links are a graph, but work is often more naturally a hypergraph.
A single relationship might connect a person, a company, a meeting, a project, a commitment, a timestamp, and a source document. Flattening that into pairs works for many cases, but it loses some of the shape of the event.
That is why we are building Hypabase Memory around a more structured view of context: relationship-aware storage, temporal tracking, provenance, and safe retrieval for agent workflows that need to operate across teams.
GBrain proves the direction: serious AI memory turns out to be infrastructure — indexes, jobs, provenance, maintenance — rather than a prompt trick or a bigger context window.
Garry Tan, President and CEO of Y Combinator, built GBrain as the memory layer behind his own OpenClaw and Hermes agent workflows, then open-sourced it in April 2026. The code lives on GitHub under garrytan/gbrain, with benchmark scorecards in a sibling gbrain-evals repository.
The software is free and open source. Your real costs are model API usage — retrieval, enrichment, and the nightly dream cycle all call LLMs — plus optional hosted infrastructure like Supabase if you outgrow the local PGLite setup. Budget for API keys, not for licenses.
Paste the INSTALL_FOR_AGENTS.md URL from the repo into Claude Code, Codex, Cursor, or an OpenClaw/Hermes agent, and it runs the ~30-minute install for you. The minimal path is faster: gbrain init --pglite creates a local brain in about two seconds, no Docker or server needed.
Yes. GBrain exposes 30+ tools over MCP, so one command (claude mcp add gbrain -- gbrain serve) connects a local brain to Claude Code, and equivalent commands cover Codex and Cursor. The repo lists Claude Code, Codex, Cursor, and AlphaClaw as tested clients.
No. GBrain uses retrieval, but adds structure basic RAG lacks: markdown source files, hybrid lexical-plus-semantic search, typed graph relationships, compiled truth with timeline evidence, background consolidation, and agent writeback. RAG finds similar chunks; GBrain maintains a living memory system around them.
Yes, if you match its profile: technical, local-first, comfortable with a fast-moving v0.x project. Its hybrid retrieval and self-wiring graph lead the open-source field. If you need a hosted service, team governance, or release stability, look at managed memory products instead — see our comparisons of Mem0, Zep, Letta, and others.
Related: Karpathy's LLM Wiki: Why the Future of AI Memory Isn't RAG | Persistent Memory for AI Agents — A Landscape | How GBrain-style systems compare to Mem0, Zep, and Letta
Try Hypabase Memory if you are building agents that need structured context, temporal memory, and provenance instead of another pile of retrieved chunks.