GBrain: Open-Source Memory for Your AI Agents

Background and Context

Anyone who runs an AI agent for long enough meets the same problem. The agent forgets who you are, or it remembers something and cannot say where the fact came from. Many products keep memory inside their own black box. If you switch tools, you teach the agent everything again. If the memory is wrong, you have little power to fix it. GBrain is built for this exact gap. Its aim is simple: give the agents you already use a memory that you control.

GBrain is an open-source project from Garry Tan, President and CEO of Y Combinator. It is written mainly in TypeScript, licensed under MIT, and free to self-host. The team also offers an optional paid hosted service at gbrain.io. The repository describes the project as Garry's opinionated brain for OpenClaw and Hermes Agent. It is not another chatbot. It is a memory layer that sits next to an agent, in the space between agent frameworks and personal knowledge bases. The repository has more than 32,000 stars on GitHub, which shows that many developers care about this problem.

The author also gives scale figures for his own deployment. He says it is the production brain behind his OpenClaw and Hermes setups. It holds 155,795 pages, 24,589 people and 5,340 companies, and 66 scheduled jobs run on their own. These numbers come from the author, not from a third-party benchmark. Treat them as a sign of scale, not as proof of performance for your own data.

Deep Analysis

The most distinctive design choice in GBrain is that it manages memory as explicit facts. Each fact carries its own source. Each fact can also be corrected or retracted. Compare this with systems that quietly compress a conversation into vectors that nobody can read again. With GBrain, a user can look back and ask why the memory looks the way it does now. That audit path is the core of the project. How does GBrain let several agents share one memory? The GBrain memory is stored once and reached through shared interfaces. A second agent, such as Codex or Claude Code, can read the same facts that a first agent wrote. You do not need to explain who you are again after you change clients. Other harnesses connect through MCP, the protocol agents use to reach outside tools. Capability is added in layers. You can start with keyword search that needs no API key. Later you can add semantic search, synthesis and background enrichment. Skills belong to the same system. A new local brain ships with memory skills in its content root. An agent can join an authorized directory, and only approved editors may publish to it. A hosted coding-agent install adds its own native route. Restarting and real-use verification are listed as separate steps, not assumed. Migration runs in stages and keeps shared choices and personal edits.

The author also describes the daily rhythm. While he sleeps, agents take in meetings, email, tweets, voice calls and original ideas. They fill in profiles for each person and company they meet, correct their own citations, and consolidate memory overnight.

Industry Impact

The docs offer three ways to start, in a clear order. The first path is the official recommendation. You add GBrain to an agent you already run. The agent keeps its identity and stores memory in its own environment. You need no new personal-agent identity and no private repository. Dedicated guides exist for Grok Bot, Muse, Codex and Claude Code. The second path is to run it on your own computer. One command, gbrain mcp expose, publishes the brain over MCP to a Tailscale tailnet and keeps it running. For cloud agents such as Grok Bot, Muse or ChatGPT, you add the --funnel flag. The docs even suggest telling the agent, "use my brain over mcp." The third path is to connect to an existing hosted brain. You can choose native OAuth or a private machine connection. Administration uses a separate owner credential, and delegation is written as a choice you must make on purpose.

One detail in the docs deserves credit. They separate Grok Bot from Grok Build, and Muse's personal agent from Muse Code, because these are different products. They also note that Muse already has editable native memory. GBrain adds a record that is explicit, portable, sourced and shareable. The guides mark dated evidence and list verification steps that are not yet done. That honesty helps readers judge whether their own setup will work. For developer communities and engineering teams, the larger point is the question of who owns memory. As agents act more like long-term colleagues, memory that lives only in one vendor's backend raises migration cost and weakens audit. GBrain treats memory as an asset that the user owns, with sources, open to correction. It can also serve as a shared company brain. Remote clients are limited by source and operation grants and by visibility filters.

Outlook

The project is also frank about its limits, and teams should read this part first. Local files and shared database credentials form a separate trust boundary. Source labels alone do not isolate those callers. The authorization tests cover specific access paths. They are not a general guarantee that nothing leaks. Before rollout, a team should review credential handling and permission scope for itself.

A second risk concerns evidence. The scale figures and the day-to-day results come mainly from the author's own account. How GBrain performs on your data and your workflow still needs a real test. A small team can start with keyword search, connect one existing agent, and check whether sourced facts and corrections behave as the docs describe.

Three things are worth watching next. First, when will the pending verification steps in each harness guide be completed? Second, how will corrections and retractions work in practice when several agents share one memory? Third, how will the line between free self-hosting and the paid gbrain.io service develop over time? The answers will show whether GBrain becomes a lasting standard for portable, auditable agent memory or stays a strong personal setup.