GBrain: The AI-Native Knowledge Base That Tells You What It Doesn't Know

Hook

Most RAG systems fail silently when they don't know the answer. GBrain's gap analysis explicitly tells you 'here's what I don't know yet'—the missing piece that makes institutional memory systems actually trustworthy.

Context

If you've ever run an autonomous agent for more than a week, you've hit the amnesia problem: the agent can't remember what it learned yesterday, can't connect dots across 500 conversations, and confidently hallucinates answers to questions buried somewhere in your 50,000-page knowledge base. Vector search helps but fails on relational queries ('who does Alice know at Acme?'), and traditional RAG returns chunks when you need answers.

GBrain is Garry Tan's answer to this problem—an opinionated, multi-tenant knowledge management daemon built for agents that need to maintain institutional memory across months. It's not a better Notion or Obsidian. It's a synthesis engine that reads your markdown/PDFs/URLs, builds a knowledge graph without LLM calls, and produces cited prose answers with explicit gap analysis. The 'dream cycle' runs overnight jobs to enrich entities, fix citations, and consolidate duplicates—turning a static index into a self-improving brain. With 23.5K stars and production use in YC-backed agent platforms, it's the most sophisticated open-source knowledge architecture shipping today.

Technical Insight

GBrain's architecture separates three concerns that most RAG systems conflate: retrieval, synthesis, and autonomous enrichment. The retrieval layer uses hybrid search (pgvector embeddings + BM25 keyword search + reciprocal rank fusion) with source-tier boosting and reranking. But the real differentiator is the synthesis layer—it doesn't return chunks, it generates prose answers with citations and gap analysis.

Here's how a query flows through the system. When you run gbrain think "Who invested in Alice's startup?", the retrieval pipeline finds relevant pages, the synthesis layer calls an LLM to produce a cited answer, and critically, it outputs what it couldn't answer:

// Simplified synthesis response structure
interface ThinkResponse {
  answer: string;           // Prose answer with inline citations [1][2]
  citations: Citation[];    // Full source metadata per citation number
  gaps: string[];          // Explicit list: 'No information about Series A investors'
  confidence: number;      // 0-1 score based on citation coverage
}

The gap analysis changes the trust model. Instead of silent failures or hallucinated answers, GBrain says 'I found X, but I'm missing Y'—making it safe to query a 100K-page knowledge base without re-reading everything yourself.

The knowledge graph extractor runs at write-time with zero LLM calls, using deterministic parsing to build typed edges (works_at, invested_in, founded, advises, attended). When you gbrain capture page.md, it scans for entity references and relationship keywords, creating graph edges in Postgres:

-- Simplified schema for knowledge graph edges
CREATE TABLE entities (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  type TEXT, -- person, company, school, etc.
  company_id UUID -- multi-tenant isolation
);

CREATE TABLE edges (
  id UUID PRIMARY KEY,
  source_entity_id UUID REFERENCES entities(id),
  target_entity_id UUID REFERENCES entities(id),
  edge_type TEXT, -- works_at, invested_in, founded, etc.
  company_id UUID -- RLS enforces tenant isolation
);

This zero-LLM approach benchmarks at P@5 49.1% / R@5 97.9% on rich-prose corpus—31.4 points better than vector-only RAG for relational queries. The trade-off: it misses implied relationships ('Alice joined the board' won't create an advises edge unless the text explicitly signals the relationship).

Multi-tenancy uses Postgres Row-Level Security to scope every query by company_id. The RLS policies are fuzz-tested across search/list/lookup operations, ensuring tenant isolation:

-- RLS policy example (simplified)
CREATE POLICY tenant_isolation ON pages
  USING (company_id = current_setting('app.company_id')::UUID);

Every API call sets the company context via Postgres session variables, and the MCP server enforces OAuth scopes (read/write/admin) before queries hit the database.

The dream cycle is where GBrain becomes autonomous. It's a cron-orchestrated job queue (called 'Minions') that runs overnight enrichment: entity resolution merges 'Bob Smith' and 'Robert Smith', citation fixing updates broken links, duplicate consolidation removes redundant pages. You schedule jobs with gbrain jobs submit enrich-entities, and they run asynchronously:

// Scheduling a dream cycle job
const job = await minions.submit({
  type: 'enrich-entities',
  params: { entity_type: 'person', batch_size: 100 },
  cron: '0 2 * * *' // 2 AM daily
});

This continuous synthesis is the moat—GBrain isn't a static index, it's a knowledge base that gets smarter while you sleep. The 43 skills (search, capture, think, plus 40 undocumented ones) compose into agent workflows, and the thin-client mode routes CLI commands through MCP to a remote server, so gbrain think works identically whether the brain is localhost PGLite or a team's hosted Supabase.

Gotcha

GBrain's OAuth implementation is homegrown (not using Auth0/Okta/battle-tested libraries), which is a red flag for company-brain deployments handling proprietary data. The multi-tenant isolation relies entirely on Postgres RLS with 'fuzz-tested' coverage—no formal verification, no security audit, no pen-test results. If you're storing sensitive institutional knowledge, this is a risk.

The knowledge graph extractor is deterministic and fast, but it can't understand implied relationships. 'Alice advised the CEO' won't create an advises edge unless 'advises' is an explicit keyword. There's no graph reasoning layer, so queries like 'who does Bob know who works at Acme?' require manual traversal logic. The benchmarks (P@5 49.1%) are on a 240-page Opus-generated corpus—no public evaluation on messy real-world knowledge bases (years of Obsidian vaults, Notion exports with broken links and inconsistent formatting). Schema pack migration is declarative but has no rollback mechanism, and custom pack authoring requires understanding undocumented internals. The dream cycle jobs have no documented failure/retry semantics or monitoring hooks—if an overnight enrichment job fails, you won't know until you notice stale data.

Verdict

Use if: you're running autonomous agents (OpenClaw, Hermes, Codex) that need to maintain 50K+ pages of institutional memory across weeks or months, you're building company-brain infrastructure where explicit gap analysis ('what's missing') is a trust requirement, or you need multi-tenant knowledge bases with agent-native synthesis and graph traversal. The synthesis layer alone—cited prose + gap analysis—is worth adoption if agent amnesia is killing your productivity. Skip if: you need production-grade security for multi-tenant SaaS (the OAuth is homegrown and RLS is fuzz-tested, not audited), you're looking for a polished personal knowledge tool (Obsidian is safer), or you don't have ops capacity for Postgres/Supabase and autonomous job queue monitoring. This is a power tool with sharp edges—adopt it if you need the unique synthesis+graph+dream-cycle architecture and can handle the operational surface.