🕸️ Knowledge graph, demystified

At its core, the whole course revolves around a simple structure: the graph. There’s no mystery—it’s the oldest way to draw “things and how they connect.” Think of a subway map: each station is a point, and each track is a line connecting two stations. The Graphify graph is exactly that, except instead of stations it stores ideas, and instead of tracks it stores relationships between ideas.

Two details give the graph its power. The first is neighborhood: from one node, you can immediately see everything connected to it — its direct neighbors. The second is the degree of a node: how many edges leave it, or in other words, how many other things it connects to. A high-degree node is a busy intersection; a low-degree node is a dead end. Remember these two—they come up again in topics 3 and 4.

↑ The circles are nodes; the lines are edges. The bright circle in the center has many connections (high degree) — it is the god node. The dashed line surrounds a well-connected group — a community. Everything that follows is in this one figure.

"Node" and "edge" are generic names. When Graphify actually looks at your content, it gives them more specific names: each node becomes a entity and each edge becomes a typed relationship. It's the same graph from topic 1 — just with precise terminology layered on top.

Each entity and relationship also carries an invisible label: the provenance — which file it came from. This lets the agent say “I read this in hooks.md, line such-and-such” instead of making it up. Provenance is what separates a reliable map from a pretty guess.

Here’s a vocabulary trap worth remembering: the video that inspires the course talks about “concepts” and “connections”; in practice, the tool says “entities” and “relationships.” They’re the same thing with different names. Knowing both keeps you from getting stuck when the GRAPH_REPORT.md using one term while the video uses another.

When you have hundreds of nodes, you’ll notice that some groups interact a lot with each other and little with the rest — like cliques at a party. These groups have a name: communities. In the diagram in topic 1, the dashed line circled one of them. Communities are what turn a tangle of points into a set of themes readable.

But who decides where one community begins and another ends? An algorithm—and the one Graphify uses is called Leiden. You don't need to understand its math; you just need to know that it scans the graph on its own and returns the groups, without you having to label anything by hand.

Under the hood, in plain language, Leiden repeats three steps until it can’t improve any further:

Remember the bright node at the center of the diagram? That was the god node: the most connected entity in the graph, the intersection that almost everything passes through. In a graph of Claude Code documentation, "Context Window" is often a god node — dozens of other concepts point to it.

Why should you care? Because god nodes are the best starting points to ask the agent. Instead of starting with an obscure concept tucked away in a corner, you start with a hub and let the agent “go down” through the neighborhood. It’s like entering a city through the central station, not through an alley.

Now let's bring it all together in an acronym you'll hear a lot: GraphRAG. To understand it, start with simple "RAG." When an agent needs to answer questions about documents that don't fit in the context window, it search the most relevant passages and pastes them into the context before answering. This is RAG.

The problem with ordinary RAG: it returns a pile of unrelated snippets. The model receives standalone pages and has to guess how they connect. The GraphRAG solves this by retrieving on top of the graph: beyond the excerpts, it provides the relationships between them—neighborhood, community, god nodes. Text + map, not isolated text.

↑ Same question, two answers. Standard RAG dumps disconnected passages; GraphRAG delivers the concept e its neighborhood. That’s why the map answers faster and with fewer hallucinations.

To wrap up the module, here’s the practical payoff. With the map in hand, Claude Code knows what's close to what. You ask about subagents; instead of scanning the entire repository with grep, it jumps straight to the “Subagents” node, reads the neighborhood from it—“agent teams,” “separate context,” “orchestration”—and responds in the right context.

The benefits grow with the size of the project. In large repositories, reading everything is expensive and slow; following the map is cheap and direct. That's the selling point of the whole stack: better answers from large codebases, because the agent spends its context window on what matters, guided by relationships instead of guessing.