Knowledge Graphs for AI Agents · From RAG Limits to Self-Updating Codebase Brains
Track 0 — Overview
M00 · The Context Problem & the Knowledge Lifecycle
📍 Module 1 of 14⏱️ ~30 minutes🧰 Prerequisites: none — this is the gateway module (code-free)📶 Level: Beginner
Welcome. Before you learn a single graph algorithm or file format, you need to feel the problem this whole course exists to solve: AI coding agents waste most of their effort — and your money — just finding things. This module shows you the problem, the 90 days in 2026 that produced an entire ecosystem of answers, and the map of what you'll build across the next 13 modules.
Learning objectives
By the end of this module you will be able to:
Explain the difference between exploration tokens and reasoning tokens, and why the split matters more than model intelligence for day-to-day agent cost.
Describe the context-assembly problem — why every new agent re-derives the same organizational knowledge from scratch.
Recount the 90-day timeline (April–July 2026) that took the field from a Karpathy post to Google's Open Knowledge Format.
Name the three context layers — structural, narrative, semantic — and say which kind of question each one answers.
State the four stages of the knowledge lifecycle (extract → curate → serve → maintain) and map each course track onto it.
The 147-file bug fix
Here is a true story, the kind every developer who uses an AI coding assistant eventually collects. A developer asks Claude Code to fix a session-timeout bug in their authentication middleware. The fix, it will turn out, is three lines — a wrong comparison operator on one line, plus a small test.
But before the agent gets anywhere near those three lines, it starts reading. It reads the logging system. It reads the database migration history. It reads half the API endpoints. For reasons known only to itself, it reads the Terraform configs. The developer watches the file counter climb — 50, 90, 120 — and finally hits Escape at file 147.
The natural reaction is to blame the model: "it's not smart enough to know where to look." But that diagnosis is wrong, and the wrongness matters. The agent was doing exactly what any newcomer to that codebase would do without a guide: exploring. Every file it opened was a reasonable guess. The problem wasn't intelligence. The agent had no map.
This course is about building that map — not by hand, and not once, but as a living system that stays true while the code underneath it keeps changing. By the capstone you will have built one: a structural graph extracted from code, a curated knowledge bundle describing what the code means, a server that lets any agent query both in a single call, and the monitoring that catches the map going stale before an agent trusts a lie.
Animation · LOST_AGENT — the same question, with and without a map
Reduced motion: showing final state.
Walk it, step by step
Below is that session, step by step — what the developer typed, what the agent did, and what the context window looked like at each turn. Watch one thing in particular: the moment the file reads layer overtakes everything the agent is actually reasoning with. The last two steps leave the story behind and show the measured version on a real 9,195-file repository.
Exploration tokens vs reasoning tokens
Before ride-hailing apps, imagine hiring a taxi in a city with no street signs and a driver with no map. The meter starts the moment you get in — and it runs at the same rate whether the driver is making progress toward your destination or circling the same block trying to find it.
The pain: at the end of the ride you pay a fortune, and most of the fare bought you nothing. You didn't pay for transportation; you paid for the driver's confusion. Worse, tomorrow's driver starts just as lost — the confusion is re-purchased every single trip.
The mapping: an AI coding agent's context windowThe fixed amount of text (measured in tokens) a model can consider at once — every file it reads, every instruction, every previous message counts against it. is the taxi meter. Every file the agent opens costs its full size in tokensThe unit LLMs read and bill in — roughly 4 characters of text per token. A 500-line source file is about 2,000 tokens., whether that file contained the answer or not. When the agent explores instead of navigating, you pay for the circling. And the next session starts just as lost.
In an agentic coding session, spent tokens split into two kinds of work. Reasoning tokens are spent thinking about your actual question — designing the fix, weighing tradeoffs, writing code. Exploration tokens are spent locating the relevant code: reading files, grepping for symbols, tracing imports, opening related modules to check a hunch.
The uncomfortable empirical fact: on codebases of any real size, the majority of tokens are exploration. The agent isn't thinking hard about your question for most of the session. It is trying to find where the relevant code lives. And exploration has a second, sneakier cost: when the context window fills up and gets compactedWhen a conversation outgrows the context window, older content is summarized or dropped. Files the agent read earlier are gone — re-consulting them means re-reading them at full price., files the agent already read are forgotten — and re-opened at full price. Context usage grows with session length even when the task doesn't.
Contrast that with a lookup. If a pre-built index can answer "who calls this function?" directly, the agent spends a handful of tokens on the answer instead of thousands on the search. The work of understanding the codebase's structure was done once, ahead of time — not re-paid on every query, by every agent, every day.
💰 Why it matters — real numbers
In one published benchmark across seven open-source projects (same model, same tasks, the only variable being whether a pre-built code graph was available), answering exploration-heavy questions on the VS Code repository dropped from 2.8 million tokens to 601,000 tokens per benchmark run. On the Excalidraw repo: 3.5 million → 344,000. Aggregate across all seven projects: 57% fewer tokens, 71% fewer tool calls, 46% faster answers, 35% lower cost — with zero change to the model. Every one of those saved tokens was mechanical file exploration that contributed nothing to answer quality. (You'll dissect these benchmarks — including where they get much less impressive — in M05.)
⚠️ Common misconceptions
"Bigger context windows will fix this." — No. A bigger window lets the agent read more irrelevant files before answering, at proportionally higher cost. And models demonstrably degrade as context fills: they forget earlier instructions, re-read files they already saw, and make mistakes they wouldn't make with a clean context. The fix is keeping irrelevant content out, not making room for more of it.
"Smarter models will fix this." — A model that needs to read 50 files and burn 3 million tokens to answer will never be used casually, no matter how intelligent it is. The friction is structural. As one analysis put it: the fastest way to make an AI coding tool better might not be to make it smarter — it might be to give it a map.
"This is only about money." — It's also about correctness. An agent skimming dozens of half-relevant files picks up wrong assumptions along the way. Fewer, more targeted reads mean fewer wrong beliefs in the agent's working model of your system.
The context-assembly problem
Exploration waste is the symptom you can see on an invoice. The deeper disease has a name — Google's engineers called it the context-assembly problem — and it isn't about code at all.
Ask a seemingly simple question inside any real organization: "How do we compute weekly active users from our event stream?" The answer exists. But where? Usually scattered across a metadata catalog, a wiki page nobody has opened since last year, a code comment, a Slack argument between two data engineers, and the memory of one senior engineer who is on vacation this week.
Every time a team builds a new AI agent, that agent has to reassemble the answer from scratch — because none of those places agree on a format, and none of them was written to be read by a machine. Table schemas, metric definitions, JOIN paths, incident runbooks, API contracts: the knowledge that agents need most is exactly the knowledge that lives in the most fragmented places. The cost isn't one-time. It's a recurring tax on every task, every agent, every teammate running one.
And stale context isn't just slow — it's actively dangerous. An agent acting on an outdated mental model of a service's dependencies doesn't merely waste tokens; it can confidently change something it didn't know was connected to something else. (In M02 you'll watch an agent retrieve a stale metric definition and ship a wrong dashboard without a single error appearing anywhere.)
Karpathy's LLM Wiki
In April 2026, Andrej Karpathy posted a thought experiment that crystallized the fix. Instead of having a model search the same raw documents over and over, let it build and maintain a living wiki — a compiled, cross-linked set of Markdown notes that serves as durable external memory. Drop papers, notes, screenshots, and architecture docs into a folder, and let an AI that understands their relationships keep the wiki current.
The insight that stuck with engineers was about temperament, not technology: humans abandon personal wikis because the upkeep is tedious — fixing cross-references, updating stale pages, logging changes. But as Google's own materials later put it: "LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The bookkeeping that causes humans to abandon personal wikis is exactly what LLMs are good at."
Think of it as compilation. Source code isn't re-parsed from scratch every time you run a program — it's compiled once and reused. Stable knowledge about your systems deserves the same treatment: compiled once, kept current incrementally, and looked up instead of re-derived. That single idea — knowledge as a compiled artifact — is the seed of everything in this course.
The 90-day timeline
What happened next is one of the fastest idea-to-ecosystem sprints in recent developer-tools history. Everything this course teaches emerged, matured, and started attracting serious scrutiny inside a single 90-day window:
Animation · TIMELINE — from a post to an ecosystem in 90 days
Reduced motion: showing final state.
April 1, 2026 — Karpathy posts the "LLM Wiki / knowledge compiler" concept on X.
April 3, 2026 — Safi Shamsi launches Graphify on GitHub, materializing the idea within 48 hours. The project enters Y Combinator's S26 batch.
June 1, 2026 — Graphify passes 58,300 GitHub stars and 1.2 million PyPI downloads.
June 12, 2026 — Google Cloud publishes the Open Knowledge Format (OKF) v0.1 spec: a vendor-neutral standard for exactly the kind of curated Markdown knowledge Karpathy described.
July 1, 2026 — a bidirectional Graphify ↔ OKF integration toolkit ships, claiming up to a 71.5× reduction in query tokens.
July 5, 2026 — Graphify reaches ~78,000 stars — and technical publications begin publicly scrutinizing the headline claims.
Hold onto that last entry. A field that went from tweet to 78,000 stars in 90 days is a field where marketing outran measurement. One of this course's standing rules — you'll see it in every module that quotes a number — is the honesty rule: every vendor benchmark gets paired with its independently replicated range. The 71.5× claim, for instance, came from one favorable 52-file test corpus; replications on real codebases landed between 6.8× and 49×, and one from-scratch benchmark on an ordinary Python codebase measured 7.3×. Still excellent — but a different conversation than "70x".
The three context layers
So the fix is "give the agent a map." But a codebase needs more than one kind of map — because agents ask more than one kind of question.
Consider three questions an agent might face about the same system:
"What calls verify_token, and what breaks if I change its signature?" — a question about structure. The answer is a fact about the code itself, mechanically derivable from source.
"Why does billing publish an event instead of calling notifications directly?" — a question about intent. No parser can answer it; the answer lives in a design decision some engineer made and (hopefully) wrote down.
"Has anyone seen this timeout error before?" — a question about the long tail: old tickets, Slack threads, incident channels. Unstructured, uncurated, and far too voluminous to organize by hand.
Three questions, three fundamentally different knowledge sources — and three different technologies, each the subject of a track in this course:
Layer
Holds
Built by
Retrieval style
Course track
Structural (what the code is)
Call graphs, imports, class hierarchies, communities
Deterministic ASTAbstract Syntax Tree — the tree-shaped representation of code's grammatical structure that parsers produce. M03 is entirely about this. parsing (tree-sitter, Graphify, CodeGraph, okf-rs) — zero LLM calls
Chunking + embeddingsNumeric vector representations of text where similar meanings land near each other — the machinery behind vector search and RAG. (vector RAG)
Probabilistic similarity search
Baseline (M02), integrated in M10
Animation · THREE_LAYERS — which layer answers which question
Reduced motion: showing final state.
⚠️ Common misconceptions
"Knowledge graphs replace RAG." — The single most viral misframing in this entire field, and this course will push back on it repeatedly. Graph tools' own benchmarks show they tie well-tuned vector RAG on retrieval accuracy (M04 has the exact numbers). Their real advantages are determinism, ingest cost, and structural queries RAG cannot express. The three layers are complements. Teams that rip out RAG to install a graph are solving a problem they don't have.
"One tool will cover all three layers." — Every tool you'll meet specializes. Graphify extracts what the code is; OKF curates what engineers know; vector search handles the remainder. The architecture question is never "which one wins" but "which layer owns which context" (M10 gives you the decision matrix).
The knowledge lifecycle — and your map of this course
Whatever the layer, knowledge that serves agents goes through the same four stages. This lifecycle is the spine of the course — every module slots into one stage:
Stage
The work
Where you'll learn it
1 · EXTRACT
Parse code into a structural graph: nodes, typed edges, communities, provenance tags
M01 (fundamentals), M03 (tree-sitter), M04 (Graphify), M05 (the tool landscape)
2 · CURATE
Write down the knowledge parsers can't see — intent, definitions, runbooks — in a standard, agent-readable format
M06 (the OKF spec), M07 (OKF for codebases)
3 · SERVE
Let agents query it all cheaply: MCP servers, progressive disclosure, hybrid routing
M09 (MCP), M10 (the hybrid stack)
4 · MAINTAIN
Keep it true while the code changes: enrichment pipelines, hooks, lint gates, freshness monitoring
Two framing notes before you start. First, the baseline: M02 makes you build and break the RAG-only approach so you understand precisely which failures the later layers fix — you cannot evaluate a cure without seeing the disease. Second, the capstone: everything converges on a single build where you wire all four stages together over a small mock monorepo called orderflow — a billing service, an orders service, a notifications worker — which you'll come to know embarrassingly well. Every lab in the course graphs, describes, serves, or monitors that one repo, so you can always check the machine's answers by hand.
✅ Why this order
The course teaches extraction before curation because extraction is free and deterministic — you can trust it blindly and build intuition fast. It teaches curation before serving because a server with nothing worth serving teaches nothing. And it teaches maintenance last but insists it matters most: the field's own production postmortems (M11 walks through four of them) show that the demo is easy and staying-true-over-time is the actual engineering problem. A stale map is worse than no map, because the agent trusts it.
Hands-on exercise (no code required)
What you'll produce: a one-page baseline observation of your own AI assistant's exploration behavior — the "before" photo you'll compare against in the capstone. Time: 15 minutes.
Step 1 — Pick a codebase you know. Any repo with 30+ files where you already know the answer to a structural question (so you can grade the agent).
Step 2 — Ask a structural question. In your AI coding assistant, ask something like: "Which functions call [some function], directly or indirectly? What would break if I renamed it?"
Step 3 — Count, don't vibe. While it works, tally: how many files did it open? How many searches did it run? Did it re-open any file twice? If your assistant reports token usage, record it.
Step 4 — Grade the answer. Was it right? Complete? Did it miss an indirect caller? Write down one sentence: "To answer a question I could answer from memory, the agent read N files and made M searches."
✅ Checkpoint
You have a note with three numbers on it: files read, searches run, correctness. Keep it — the capstone's Phase 1 repeats this measurement formally on the orderflow repo, and Phase 7 makes you compare honestly. If the agent read fewer than 5 files, congratulations: your repo is small enough that (as M04 and M11 teach) graph tooling may genuinely not be worth it. That's a course lesson too.
🔍 Context Engineering Lens
The 147-file bug fix is what the sibling course's context engineering module (M03B) calls a failed six-layer inventory: nobody decided what should occupy the context window, so exploration decided by default. Context engineering asks "what gets included at all, in what order, fresh or cached, full or summarized?" — a budgeting problem, not a writing problem. Everything this course builds is that budget, industrialized. The mapping is made explicit in M02B — The Context Engineering Frame.
Knowledge check
Six questions. Pick an answer to see immediate feedback.
1. In a typical agentic coding session on a large codebase, where do most tokens go?
Reasoning about the user's actual question
Exploration — finding where the relevant code lives
Writing the final code
Safety filtering
2. Which context layer answers "Why does billing publish an event instead of calling notifications directly?"
The structural layer (AST call graph)
The narrative layer (curated knowledge, e.g. OKF)
The semantic layer (vector RAG)
3. What is the correct order of the knowledge lifecycle?
Serve → extract → maintain → curate
Curate → extract → serve → maintain
Extract → curate → serve → maintain
Extract → serve → curate → maintain
4. What was the core idea of Karpathy's "LLM Wiki" concept?
Fine-tune a model on your codebase so it memorizes the structure
Let a model build and maintain a living, cross-linked Markdown wiki as durable external memory
Replace documentation with automatically generated code comments
Store all knowledge in a proprietary graph database
5. Why don't bigger context windows solve the exploration problem?
They do — a large enough window makes graphs unnecessary
They let the agent read more irrelevant content at higher cost, and model performance degrades as context fills
Context windows can't hold source code
6. What shipped on June 12, 2026, and what is it?
Graphify — a YC-backed AST graph extractor
Google Cloud's Open Knowledge Format (OKF) v0.1 — a vendor-neutral Markdown+YAML standard for curated knowledge
CodeGraph — a SQLite-based local code index
A new Claude model with a larger context window
Module summary
The problem
Agents burn most tokens on exploration, not reasoning — re-purchasing the same confusion every session. 147 files for a 3-line fix.
The disease behind it
The context-assembly problem: organizational knowledge scattered across catalogs, wikis, comments, and vacationing brains — reassembled from scratch by every agent.
The idea
Karpathy's LLM Wiki: compile stable knowledge once, like source code, and let models do the upkeep humans abandon.
The ecosystem
90 days in 2026: Karpathy post → Graphify (Apr 3) → OKF v0.1 (Jun 12) → integration toolkit → scrutiny. Hype outran measurement; this course pairs every claim with its replicated range.
The architecture
Three complementary layers: structural (what code IS), narrative (what engineers KNOW), semantic (the messy rest). Complements — not competitors.
Your map
Extract (T2) → curate (T3) → serve (T4) → maintain (T5), all converging on one capstone build over the orderflow repo.
Next up — M01: Knowledge Graph Fundamentals. Before touching any tool, you'll build a real (tiny) code graph by hand in pure Python: nodes, typed edges, traversal, communities, god nodes, blast radius, and the EXTRACTED/INFERRED honesty labels every serious tool ships. Everything later in the course is these primitives wearing better clothes.
References
Google Cloud — Introducing the Open Knowledge Format (cloud.google.com/blog/products/data-analytics)