GBrain's README graph-recall figure is an upper bound, not production search performance

Key findings

Terms used in this report

• MCP (Model Context Protocol) is an open protocol that agents such as Claude Code and Codex use to call external tools. GBrain exposes its features as MCP tools, and agents read and write memory through them.
• PGLite is an embedded database that compiles Postgres to WebAssembly so it runs inside a single process with no separate server. It is GBrain's default engine; for shared or large deployments GBrain uses Postgres with the pgvector extension.
• Hybrid search combines keyword search with semantic search (comparing embeddings, which turn text into numeric vectors). GBrain merges the two ranked lists with RRF (Reciprocal Rank Fusion, which sums the reciprocals of each result's ranks).
• A reranker is a separate model that re-reads search candidates together with the query and reorders them. The candidates and the query are sent to an external API.
• R@5 (recall) is the share of pages labeled as relevant that appear in the top five results; P@5 (precision) is the share of the top five results that are relevant. The developer's report always uses five as the P@5 denominator.
• An adapter is the code an evaluation repository uses to run the same questions against each system being compared. Two adapters with the same name can differ in whether they call the product's own search or a separate path built for the evaluation.
• Compiled truth and timeline are the two parts GBrain splits a page body into. The first is the current overall judgment and is rewritten when new evidence arrives. The second is a dated record of evidence and is only appended to.

What GBrain is — facts checked on 2026-10-06

The GitHub repository description reads "Garry's Opinionated OpenClaw/Hermes Agent Brain." The README says Garry Tan built it as the memory store for his own agents (personal assistants running on OpenClaw and Hermes) and then generalized it. We checked the values below in the repository and through the GitHub API.

The read/write flow works like this. When an agent calls remember or put_page over MCP, GBrain writes a Markdown page and indexes it in the database. Retrieval is split into gbrain search (returns a list of result pages) and gbrain think (generates a synthesized answer from the results, with citations and a note on what is missing). The overnight maintenance job, the "dream cycle," consists of 26 phases in the current code (link cleanup, fact extraction, contradiction detection, embedding and others).

We covered the broader trend of keeping agent memory in a Markdown folder in Agent memory is moving to files, and the cost structure of a memory benchmark in our DolphinBench report (Korean only). This report looks only at GBrain's claims and code.

What the June note said and what the repository says now

We checked each statement in the June note against the current code and docs. Some things changed after June; some were not accurate even in June.

The verdicts are this report's classification. "Needs scoping" does not mean the June statement was wrong; it means the current docs state a narrower scope.

The README's graph figure — the eval report classifies it as an upper bound

In the paragraph describing its knowledge graph, the README says that "on BrainBench relationship questions a graph adapter scored P@5 0.3421, R@5 0.9791 vs 0.1917 / 0.6874 plain hybrid," and links to the 2026-09-09 report in gbrain-evals as the source. The README itself adds a caveat: these are "whole systems, not a graph-only lift or a general guarantee."

The linked report carries one more caveat. A note added on September 28 says that, "because it knows the four question forms in advance," the adapter has been renamed graph-oracle-parse and is treated as an upper bound. The body of the report also describes this adapter as "a useful specialized system … different from the production hybrid pipeline exercised below." The same report separately publishes a controlled comparison on the production search pipeline in which only the relationship retrieval stage (search.relational_retrieval) is switched off and on.

Here is what the controlled comparison found. Across 435 pairs (145 relationship questions repeated under three data-ingestion orders), turning the relationship stage on raised recall on 45 pairs and lowered it on none. The effect varied by question template. For "Who invested in X?", the share of questions with a correct first result rose from 9/39 to 21/39; for "Who attended X?", recall stayed at 0.38. For the attendance questions, the report notes that the evaluation data links meetings to people, while the product follows links from people to meetings. It also states that the three ingestion orders repeat the same questions, so the 435 pairs are not independent samples; that the answer key gives credit only to person pages; and that answer accuracy was not measured.

In short, in the developer's measurement the relationship stage raised recall on some questions without lowering it on any. But the 0.9791 the README cites comes from an adapter that knows the question templates in advance; the production pipeline scored 0.7241. Both figures come from the version evaluated at the time (0.48.4.0), and we found no re-measurement on the current version.

Other developer evaluations — unfavorable results and corrections are included

gbrain-evals is a separate repository under Garry Tan's account, so these are developer measurements, not independent evaluations. The reports do include comparisons in which GBrain came out behind, along with correction notes.

What these reports show is not that "GBrain is always better" but that you should decide which settings to enable by testing them on the questions you actually expect to ask. The report's own conclusion recommends comparing simple search with GBrain on the same questions and holding back questions you did not use to choose settings. In the sources we checked, we found no reproduction of these evaluations by an independent party.

Sharing and backup — limits the docs state themselves

Of the material missing from the June note, the most important for an adoption decision is the set of boundaries described in docs/guides/memory-boundaries.md and docs/architecture/system-of-record.md. Where the code could confirm a point, we checked it too.

• By default, memories an agent saves are readable by every connected agent. The default visibility of the remember operation is world in the code (src/core/verbs.ts). The README says you must pass visibility: "private" to keep a memory to one agent.
• A Markdown export is not a full backup. DB-only facts and pages, revision history, withdrawal state, the job queue, settings and authentication records may not be recoverable from Markdown, so the docs recommend using the engine's full backup and restore path and testing a restore into a separate location.
• Local storage does not mean local processing. Keyword search and link extraction without an API key use no model API, but once embeddings, the reranker, query expansion or synthesis are turned on, the relevant text is sent to the configured provider. The connected agent's own model receives recalled memories even when GBrain runs without an API key.
• With default settings, each save adds one fact-extraction call. For pages of extraction-eligible types such as notes, meetings and email, a queued job calls a fact-extraction model once after the save; the docs say gbrain config set facts.extraction_enabled false turns this off.
• A source organizes content; it does not isolate access. Remote clients are restricted by per-source grants and visibility filters, but local callers that use the same files or database credentials are not. The docs advise keeping content that must be fully inaccessible in a source that has not been granted.

Developer claims we could not verify

The README also makes claims that cannot be checked from outside the repository. This report records them only as developer claims, not as facts.

Checklist

What is not settled

• This report is a rewrite, on 2026-10-06, of an initial note published on 2026-06-16. The June note was an overview restating the README, with no per-figure source checks and no limitations section. Its use-case scenarios and staged adoption plan were removed because they had no supporting evidence.
• This report contains no new performance measurements. We did not install or run GBrain. What we did was read the code and load the repository's code to count the defined operations and phases. All performance figures are developer measurements taken from the gbrain-evals reports.
• The evaluated versions differ from the current one. The relationship comparison was run on 0.48.4.0 and the LongMemEval re-measurement on 0.60.37.0. We did not confirm whether 0.60.78.0 produces the same values.
• The evaluation data is not real usage data. The report says the concept-search results come from a synthetic corpus, and a September 28 correction says the "externally authored" question set is 50 AI-written placeholder questions. These evaluations cannot tell you how GBrain performs on real personal or company data.
• We checked the permission boundaries against the docs and only part of the code. We confirmed the default visibility and the operation-exposure rules in the code, but did not verify that source isolation holds on every path. The developer also says it does not guarantee this.
• It changes quickly. The CHANGELOG gained 196 entries after June 16 alone. Statements about the code in this report refer to commit a08578c, and repository figures are from the GitHub API as of 2026-10-06.

References

All sources were retrieved and checked on 2026-10-06.

We rewrote the initial note of 2026-06-16 to current standards on 2026-10-06. The introductions on GeekNews (a Korean developer news aggregator) and Zenn (a Japanese developer blogging platform) cited in the June note are secondary sources and are not used as evidence in this version. If the README's graph figure or the eval reports change, we will update this report and note the revision date.