Implementing Agentic Knowledge Graphs: Automating LLM Wiki Construction via Claude Code and Obsidian

In the evolving landscape of Large Language Model (LLM) orchestration, the primary bottleneck is no longer just model parameter count or context window size—it is the quality and structure of available context. As we move from simple RAG (Retrieable Augmented Generation) toward true agentic workflows, the ability to transform unstructured data blobs into a structured, interconnected knowledge graph becomes paramount.

This post explores a methodology for building an "LLM Wiki"—a self-evolving second brain—leveraging Andrej Karpathy’s concept of indexing sources and using Claude Code as an autonomous ingestion engine within an Obsidian-based Markdown ecosystem.

The Architecture: Knowledge Graphs as Markdown Ecosystems

The core philosophy behind this implementation is to treat knowledge not as a flat collection of documents, or even a vector database, but as a web of interconnected nodes (entities, concepts, and sources) represented via Markdown files. By using Obsidian as the frontend, we gain a high-fidelity visualization of backlinks and relations, while the underlying .md structure ensures that any agent—whether it be Claude Code, Hermes, or Codex—can traverse the graph without proprietary API dependencies.

The architecture relies on a specific directory hierarchy designed for agentic readability:

• /raw: The landing zone for unprocessed data (PDFs, YouTube transcripts, raw text).
• /wiki: The structured output layer containing atomic Markdown pages categorized by concepts, entities, sources, and topics.
• /index.md: A centralized routing table or "Table of Contents" that allows agents to perform efficient lookups without scanning the entire filesystem.
• /log.md: An immutable audit trail of all ingestion events, providing temporal context for how the knowledge base has evolved.

Initializing the Agentic Schema

The setup begins by utilizing Claude Code (specifically leveraging the Fable model's advanced instruction-following capabilities) to initialize a workspace based on Karpathy’s LLM Wiki Gist. The goal is to move beyond simple file storage and establish an "Agentic Instruction File" (e.g., Cloud.md) that defines the schema, folder conventions, and routing rules.

The initialization prompt instructs the agent to:

1. Implement a complete second-brain logic based on the provided Gist.
2. Generate a Cloud.md schema containing strict operational rules.
3. Establish the directory structure (index, log, raw, wiki).
4. Define the ingestion pipeline for future documents.

By providing this high-level architectural directive, we shift the burden of organization from the human user to the LLM. The agent is not merely a writer; it acts as a database administrator (DBA) that understands how to decompose complex information into granular, cross-linked nodes.

The Ingestion Pipeline: From Unstructured Blobs to Atomic Nodes

The true power of this system lies in its ability to perform "Batch Ingests." Unlike traditional RAG, which might simply chunk text based on character counts, an agentic ingest analyzes the semantic weight of a source and decides how many wiki pages are required to represent it accurately.

Case Study: Analyzing Claude Fable 5 and GPT 5.6 Sol

In a recent test execution, two disparate sources were ingested:

1. A PDF System Card for Claude Fable 5 + Mythos 5.
2. A URL-based article regarding the OpenAI GPT 5.6 Sol preview.

The ingestion process took approximately 10–12 minutes, during which the agent performed several complex operations:

• Decomposition: The single PDF was decomposed into roughly 20 distinct wiki pages.
• Entity Extraction: The agent identified and created nodes for Anthropic, OpenAI, Frontier Models, and specific model versions like Mythos Preview.
• Relational Mapping (Backlinking): Crucially, the agent recognized semantic overlaps between the two sources—such as shared benchmarks or cybersecurity safeguards—and established backlinks between the OpenAI article and the Claude system card.

This creates a "routing" capability. When an agent queries the system for "Cybersecurity in Frontier Models," it does not need to perform a brute-force search of every file. It consults the index.md, follows the link to the relevant concept, and discovers the cross-referenced data between the two labs' different testing harnesses.

Deterministic vs. Agentic Automation

A critical distinction in this workflow is the movement from deterministic automation (fixed scripts that move files) to agentic automation (models that decide how to structure information).

While models like Opus 4.8 are highly capable, the implementation highlights that certain models—specifically Fable—demonstrate superior performance in handling "emotional" or nuanced prompting instructions (e.g., "Create this in a way a beginner could understand without being overwhelmed"). This nuance is vital when building a user-facing interface for complex technical data.

Furthermore, the system allows for varying levels of structural density. For certain projects, such as meeting transcripts ("Herc Brain"), a "flat" structure is often preferable to prevent excessive folder nesting, which can increase token consumption during retrieval. The agent decides whether to implement a deep hierarchy or a flat list based on the nature of the input data.

Conclusion: The Universal Data Layer

The ultimate advantage of this Markdown-centric approach is interoperability. Because the "intelligence" of the wiki resides in the .md files and their routing rules, you are not locked into a single ecosystem. This knowledge base can be ingested by any agentic framework—be it Hermes, Codex, or custom-built orchestrators within an AIOS (AI Operating System).

By treating your data as a structured, navigable graph of Markdown files, you transform a simple collection of notes into a high-performance, machine-readable context engine.