A Deep Dive into LLM Wiki / Obsidian-Wiki / GBrain: The "Self-Organization" and "Self-Evolution" of Knowledge in the Agent Era

Posted on In Views: Word count in article: 1.4k Reading time ≈ 5 mins.
From a knowledge-engineering perspective, this article dissects the designs of Karpathy's LLM Wiki, Obsidian-Wiki, and GBrain, analyzing the self-organization and self-evolution of knowledge in the Agent era, and how Skillify turns scattered material into continuously evolving structured memory.

Today’s article looks at things from the angle of Knowledge Engineering, starting from the designs of LLM Wiki, Obsidian-Wiki, and GBrain, to unpack why—in the Agent era—knowledge engineering matters more than merely optimizing RAG, and how “Skillify” turns scattered material into continuously evolving structured memory.

Background

Recently the focus of attention on AI has been highly concentrated, mainly revolving around the concept of “self-evolution,” spanning two core dimensions: the “automatic accumulation of Skills” and “RL (reinforcement learning) training.” For most engineering deployment scenarios, achieving Agent self-evolution through the Skill mechanism is the lighter-weight and more broadly applicable approach.

Illustration of Agent self-evolution and automatic Skill accumulation

Automatic Skill updates alone are not enough—giving the Agent more “knowledge” through humans, and even having the “knowledge base” that stores it “auto-curate,” “auto-organize,” “auto-update,” and even “auto-evolve,” is what continuously drives the Agent’s ongoing “self-evolution.”

Illustration of the knowledge base's auto-curation, auto-organization, and auto-evolution mechanism

From “Knowledge Pile-Up” to “Structured Memory”

Andrej Karpathy open-sourced the “LLM-Wiki” project, whose core is a single Markdown file aimed at guiding LLM Agents to update and structure knowledge. GBrain was built by Garry Tan, President and CEO of Y Combinator; its philosophy is similar to LLM-Wiki but more engineered.

Illustration introducing Karpathy's open-source LLM-Wiki project

Humans are very good at “mindlessly piling up” knowledge but very bad at “organizing” it. The difficulty of knowledge management shows up along two dimensions: timeliness and dynamic maintenance, and the complexity of organizational structure. In the AI era, the quality of knowledge directly determines the ceiling on outcomes.

If Prompt Engineering teaches the model “what kind of task to accomplish,” then Knowledge Engineering teaches the model “what it should know” and “how to apply what it already knows.” Karpathy’s LLM-Wiki breaks through the limitation of traditional RAG’s “retrieve from scratch on every query”: guided by a Schema file, the LLM proactively maintains a structured Markdown Wiki, “compiling” raw material into a persistent knowledge body with cross-references and contradiction annotations.

Illustration of a Schema guiding the LLM to maintain a structured Wiki knowledge body

Skillify: A “Knowledge Form” of Progressive Disclosure

Illustration of Skillify's progressive-disclosure knowledge-organization form

The core innovation of LLM Wiki and GBrain is generalizing the Skill into a form of knowledge organization. GBrain’s founder coined the term “Skillify”—to write Skills, or to organize and load knowledge the way a Skill does. This mechanism lets all kinds of Agents take in all kinds of files, text, and links, then automatically “compile” and archive them into a unified personal knowledge base.

Diagram of files and links being automatically compiled and archived into a unified knowledge base

Reviewing the three stages of Alibaba Cloud’s intelligent customer service: the era of traditional intelligent knowledge bases (2016-2022) → the RAG era (from 2023, with the problems of a model-capability gap and unconsolidated knowledge) → the Agent era (an LLM-led persistent knowledge base, “learn once, available forever”).

If RAG is letting the LLM “bring the textbook into the exam,” then Skillify is letting the LLM “read the book thoroughly and turn it into organized notes.”

LLM Wiki: A Three-Layer Architecture for a Knowledge Closed Loop

Diagram of the LLM Wiki three-layer architecture knowledge closed loop

The core idea of LLM Wiki: rather than retrieving from raw documents at query time, have the LLM progressively build and maintain a persistent Wiki. The three-layer architecture: Raw Sources (read-only archive) → The Wiki (structured knowledge pages) → The Schema (meta-instructions).

Three core operations:

  • Ingest: the LLM reads the raw material, extracts key points, and automatically updates the global index; one source can ripple updates across 10-15 related Wiki pages.
  • Query: the LLM first locates the relevant Wiki pages, then synthesizes a cited answer. High-quality answers can be archived as new pages.
  • Lint: similar to static code analysis, it identifies factual contradictions, cleans up outdated statements, and finds orphaned pages.

Obsidian-Wiki: An Engineered Implementation from Idea to System

Illustration of Obsidian-Wiki's Skill-based multi-Agent framework

Obsidian-Wiki is a Skill-based multi-Agent framework whose core enhancements include:

Illustration of Obsidian-Wiki's core enhancements such as Delta tracking and provenance tagging

  • Delta tracking: uses SHA-256 hashes to track all sources, so it knows which need reprocessing.
  • Source-trust boundary: treats source documents as untrusted, guarding against prompt injection.
  • Provenance-tagging system: three confidence levels—extracted / inferred / ambiguous.
  • Agent history-ingestion Skills: automatically scan the histories of Claude, Codex, OpenClaw, and Hermes Agents.
  • Knowledge-graph Skills: a cross-linker skill automatically discovers connections between pages and introduces a confidence-scoring system.

Illustration of the knowledge-graph cross-linker skill and confidence scoring

LLM Wiki’s capability boundaries: no database dependency (suitable for hundreds to a low thousands of pages), an obvious scale ceiling, no automated scheduling, and weakly structured graphs. As pages balloon, you’ll need to bring in vector search or graph-database infrastructure.

GBrain: Hybrid-Retrieval Architecture and the Evolution of Graph Relationships

GBrain’s architectural philosophy: Thin Harness, Fat Skills. Keep the Harness thin and put your main energy into enriching the Skills.

Illustration of GBrain's Thin Harness, Fat Skills architectural philosophy

Latent Space vs. Determinism

Diagram of the division of labor between LLM latent-space decisions and deterministic code execution

Let the LLM decide “what to do” (latent space), and let code guarantee “where” and “how” (determinism).

Hybrid-Retrieval Architecture: Vector Filtering + File Disclosure

Flowchart of GBrain's vector-filtering-plus-file-disclosure hybrid retrieval

GBrain’s retrieval process is “Chunk confirmation → full-page loading → layered presentation.” Vector retrieval quickly screens candidates from a massive set of files, then full-page loading follows progressive disclosure. “Coarse vector screening + careful file reading” avoids both the semantic loss of pure RAG and the inefficiency of pure file traversal.

seekdb engineers this pattern: a single query can perform full-text matching, vector nearest-neighbor retrieval, and also layer on scalar filtering, weighted fusion, RRF, or a reranking model.

GBrain’s measured results on a 240-page benchmark:

Metric GBrain (with graph) Hybrid search only (no graph) Gap
P@5 49.1% 17.7% +31.4 pp
R@5 97.9% — —

Graph Construction and Entity-Relationship Extraction

GBrain’s four-step graph-construction pipeline: entity extraction (regex + keyword pattern matching) → page generation → relationship classification (keyword matching to determine relationship types) → backlink enforcement. GBrain has a complete graph data structure: nodes, typed edges, traversability. It lets the Agent perform complex reasoning tasks such as “find all companies invested in by Zhang San where Li Si is employed.”

seekdb: How Hybrid-Search Capability Lands in Real Engineering

As knowledge scale keeps growing, an AI-native hybrid-search database like seekdb answers the question: how should the underlying retrieval infrastructure absorb these demands? It blends vector search, full-text search, scalar filtering, and reranking into a single engine, reducing the complexity and consistency problems that come from stitching together multiple retrieval components.

An NVIDIA engineer has already released MemBox, a multimodal intelligent memory system built on seekdb + PowerMem: the frontend receives user messages and images, the backend vectorizes them and retrieves relevant memories in seekdb, then injects the recalled user profile into the LLM’s context.

LLM Wiki and Obsidian-Wiki explore knowledge-organization paradigms, GBrain explores engineered knowledge systems, and seekdb fills in the “large-scale, filterable, hybrid, rerankable” retrieval infrastructure. Future Agent systems will inevitably combine “the upper-layer knowledge organization” with “the lower-layer hybrid-search foundation.”

Summary

The system of Skills and dynamic knowledge maintenance is precisely what determines whether an Agent can evolve from “trial-and-error exploration, one round at a time” into “persistent learning and updating.”

Technology selection isn’t either-or. The usual best practice is a hybrid architecture: use a hybrid-search capability like OceanBase seekdb for fast first-pass screening, solving the “find it fast” problem; and at the same time preserve the LLM’s ability to deeply read high-value knowledge, disclose progressively, and self-iterate offline, solving the “answer accurately” and “remember firmly” problems.

Reference links: