Evolving the Graph: Making Intellectual Change Visible

Andrej Karpathy published a gist this week describing a pattern for building personal knowledge bases using LLMs. The idea is not retrieval at query time in the way most RAG systems work. Instead, the LLM incrementally builds and maintains a persistent wiki, integrating new sources into existing pages, cross-referencing, flagging contradictions, and compounding over time. The wiki is mutable and owned by the LLM. The raw sources are immutable. You provide the curation and the questions. The LLM does the bookkeeping.
It is a compelling model, and it connects directly to the 'Building a Second Brain' work by Tiago Forte, and to related projects like mempalace that I have been watching and thinking about for my own CortexYou idea. But what caught my attention specifically, from a site perspective, was a concept buried in the community discussion underneath Karpathy's gist.
Several people referenced frontmatter fields for tracking the status of wiki pages: active, superseded, archived. The point being that knowledge does not just accumulate. It gets replaced. Views change. Technology moves on. The page you wrote in 2021 about how to approach agent orchestration is not necessarily wrong, but it is incomplete relative to what you would write in 2026. If your knowledge base does not surface that evolution, then it flattens time in a way that is quietly misleading.
That observation landed because it is precisely a problem this site has.
The knowledge graph here already connects content through themes, entities and related posts. But everything it contains is treated as equally current. A post from 2023 exploring nanoGPT sits as a peer node alongside something written this year. That is fine for what that post actually is, but if I had subsequently written something that directly revisited or replaced that thinking, the graph has no way of showing that thread. A reader navigating the graph would have no signal about which direction the thinking has moved.
The fix is straightforward in principle. When you write a new post that explicitly supersedes an earlier one, you declare it in the front matter:
supersedesContentId: "blog-2023-06-exploring-nanogpt"The build pipeline picks this up and generates a directed evolves edge in the graph, running from the newer post to the older one. In the graph view on the explore page, these render as dashed amber lines, visually distinct from the grey lines used for related content and the weighted lines connecting themes and entities. You can follow the chain. You can see where thinking has moved.
A real example for me would be posts about AutoGen, Semantic Kernel, and then Microsoft Agent Framework. Those are not just related posts on the same theme. They are a progression. The earlier posts did not anticipate where the tooling would end up. A graph that can surface that progression is more honest about the nature of the content than one that simply clusters by theme.
The authoring overhead is low by design. You only add the field on the newer post, at the time you write it, when the connection is fresh. You do not go back and retrofit older content. This is option two from the Karpathy framing: forward-looking rather than retrospective. In practice it means the graph gets richer over time without creating a maintenance burden.
None of this would have surfaced without Karpathy's gist prompting the reflection. Credit is due there. The broader pattern he describes, the compounding personal wiki, is something I will return to as I get CortexYou moving again. But for now, this felt like the right small step: take the concept, apply it where it fits, and ship it.
The explore page graph will show evolves edges as they appear. If you are reading this and you have your own knowledge graph or personal site, the idea is simple enough to port. The value is not in the visual effect. It is in being honest about the fact that thinking is not static, and making that visible to people who are following your work over time.
#KnowledgeGraph #BuildingASecondBrain #LLM #SiteDevelopment
Continue exploring