Most people use AI like a vending machine for answers.
Upload a document. Ask a question. Get a response. Close the tab. Tomorrow, upload the same document again. Ask a slightly different question. Watch the model start from zero again, as if yesterday never happened.
This is the default pattern for "AI productivity" today. It feels magical the first few times because the system can summarize, explain, and extract insights from almost anything you throw at it. But after a few weeks, the magic starts to feel strangely disposable. You are not building knowledge. You are renting short bursts of intelligence.
The problem is not that the models are too weak. The problem is that the workflow has no memory that compounds.
Andrej Karpathy described a better pattern: using LLMs to build and maintain personal knowledge bases. Not just a folder of uploaded PDFs. Not just a chatbot over documents. A persistent, structured, interlinked wiki that an LLM updates over time.
The important part is not the wiki. We have had wikis for decades.
The important part is the maintenance.
That is the missing piece that killed almost every "second brain" system before AI. People love the idea of a personal knowledge base. They love Obsidian graphs, Zettelkasten diagrams, PARA folders, tagged notes, backlinks, evergreen notes, dashboards, and all the rest. But after the initial burst of enthusiasm, the same thing usually happens: the system becomes another system to maintain.
You clip articles but do not summarize them. You create notes but do not connect them. You tag things inconsistently. You forget to update old claims when new information arrives. You create a beautiful structure and then slowly avoid it because every interaction creates more bookkeeping.
The second brain fails because it still needs a first brain to clean up after it.
Karpathy's LLM wiki pattern changes the economics. It treats the knowledge base less like a personal notebook and more like a codebase. Raw sources go in. The LLM reads them, extracts the important parts, creates or updates markdown pages, maintains cross-references, tracks contradictions, and keeps indexes current. The human does not write the wiki by hand. The human curates sources, asks questions, reviews outputs, and decides what matters.
Andrej Karpathy post
https://x.com/karpathy/status/2039805659525644595
That is a much more interesting division of labor.
From Retrieval to Compounding Knowledge
Most AI document workflows today are based on retrieval. You upload files, the system chunks them, embeds the chunks, and searches for relevant passages when you ask a question. This is the basic idea behind many RAG systems, and it is useful. It lets the model answer questions about material that is not in its training data.
But retrieval has a ceiling.
When you ask a question, the system searches, pulls a handful of fragments into context, and generates an answer. The answer may be good, but the work usually disappears when the conversation ends. The synthesis does not automatically become part of a durable structure. The next question starts another retrieval cycle.
That is fine for one-off questions. It is weak for learning, research, writing, and strategy, where the whole point is that understanding should accumulate.
An LLM-maintained wiki works differently. It does not wait until query time to synthesize everything from scratch. It compiles knowledge ahead of time.
When you add a new source, the LLM reads it and integrates it into the existing system. A paper might update a concept page. A company profile might revise a competitor page. A transcript might add evidence to a customer pain point. A new article might contradict an older summary, so the wiki flags the tension instead of quietly burying it in a pile of documents.
The question changes from "Can I retrieve the right paragraph?" to "Has my knowledge base become smarter because I added this source?"
That is the real shift: knowledge becomes cumulative.
The Three Layers
The architecture is simple enough that its simplicity is easy to miss.
The first layer is raw sources. These are the original materials: articles, PDFs, notes, transcripts, papers, web clips, images, repos, datasets, and anything else you want the system to know about. This layer should be treated as immutable. The AI can read it, cite it, and summarize it, but it should not rewrite the evidence.
The second layer is the wiki. This is a directory of markdown files maintained by the LLM. It can include source summaries, concept pages, entity pages, timelines, comparisons, open questions, indexes, and research briefs. This is the compiled layer. It is where raw material becomes usable knowledge.
The third layer is the schema. This is the set of instructions that tells the LLM how to behave as a maintainer. What folders exist? What counts as a source summary? How should citations work? When should it create a new concept page instead of updating an old one? How should contradictions be recorded? What does a health check look for?
The schema is what turns a chatbot into an operator.
Without it, you have a model improvising. With it, you have something closer to a junior researcher who knows the house style, the filing system, and the maintenance rituals.
Obsidian fits naturally into this workflow because it is already a local markdown environment with backlinks, graph views, and fast navigation. Karpathy's framing is useful: Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase.
That metaphor matters. Codebases are not valuable because they contain files. They are valuable because the files follow conventions, reference each other, can be refactored, can be linted, and can be improved without starting over. A serious knowledge base should work the same way.
The Human Should Not Be the Clerk
The old model of personal knowledge management quietly assumed that the human would do everything.
You read the source. You highlight. You summarize. You choose the folder. You add tags. You create links. You remember that an older note now needs to be updated. You notice that two sources disagree. You keep indexes clean. You decide whether an orphan note should be deleted, merged, or connected.
This is exactly the kind of work that feels productive in week one and unbearable in month three.
It is also exactly the kind of work LLMs are good at.
They do not get tired of repetitive structure. They do not mind updating fifteen files in one pass. They can scan for stale claims, missing backlinks, duplicated concepts, inconsistent naming, and unresolved contradictions. They can turn a messy source into five useful artifacts: a summary, a list of claims, an entity page update, a concept page update, and a question worth investigating later.
The human should stay closer to judgment.
Which sources belong in the system? Which claims are actually important? What question is worth asking next? Which synthesis feels true, useful, surprising, or wrong? What should be turned into an article, memo, deck, decision, product idea, or research direction?
That is the part where taste matters.
The LLM should do the clerical work of knowledge. The human should do the editorial work of meaning.
What This Looks Like in Practice
Imagine you are researching a market. You start with a few analyst reports, competitor blog posts, customer interviews, product pages, and sales call transcripts. In the old workflow, these would become a pile of documents. Maybe you would ask a chatbot questions over them. Maybe you would keep a spreadsheet. Maybe you would eventually write a memo that becomes stale the moment new information arrives.
In the LLM wiki workflow, every new source updates the living map.
A competitor announcement updates the competitor's page. A customer call updates a page about objections, pain points, buying triggers, and language customers actually use. A market report updates concept pages around pricing, regulation, adoption, or distribution. A new contradiction gets logged instead of ignored. A useful query can become a saved brief that future queries can build on.
After a few weeks, the system is no longer just a document store. It is a research environment.
The same pattern works for writers. Ingest your past essays, notes, interviews, saved articles, and drafts. The wiki can track your recurring arguments, examples, claims, references, and unfinished ideas. When you sit down to write, you can ask what you have already said about a topic, which examples are strongest, where your thinking has changed, and what angle you have not explored yet.
It works for self-education. Ingest lectures, readings, exercises, and papers. The wiki can maintain concept pages that evolve as the course gets harder. It can explain how week seven revises week two. It can generate review sheets, identify weak areas, and turn confusion into a study plan.
It works for teams. Feed it meeting notes, Slack threads, customer calls, planning docs, strategy memos, support tickets, and postmortems. The wiki can maintain project pages, customer pages, product decision logs, competitor pages, and recurring risk themes. The benefit is not just search. The benefit is that the organization stops losing context in the cracks between tools.
In every case, the pattern is the same: sources are collected, knowledge is compiled, questions produce outputs, and useful outputs get filed back into the system.
The exploration adds up.
The Health Check Is the Product
One of the most underrated parts of Karpathy's pattern is linting.
A normal note system decays silently. Links break. Pages duplicate. Summaries get stale. Claims contradict each other. Important sources remain unprocessed. You do not notice the decay until you need the system for real work and no longer trust it.
An LLM-maintained wiki can be checked.
You can ask it to find orphan pages. You can ask it to identify duplicated concepts. You can ask it which claims need citations. You can ask it where newer sources conflict with older ones. You can ask it what pages are too vague, too long, too thin, or missing obvious cross-references.
This sounds small, but it is the difference between a pile of notes and an operating knowledge base.
The health check is not a side feature. It is the mechanism that keeps trust alive.
A knowledge base you do not trust is just another archive. A knowledge base that can inspect itself, explain its weaknesses, and propose repairs starts to feel like infrastructure.
Why Markdown Matters
The humble choice of markdown is more important than it looks.
Markdown files are portable. They can live in a normal folder. They can be opened in Obsidian, edited by any text editor, versioned with git, searched with command-line tools, rendered into websites, transformed into slides, or processed by scripts.
This keeps the system from becoming a black box.
Many AI products want to absorb your knowledge into a proprietary interface. That may be convenient, but it also makes your understanding dependent on someone else's database, pricing, roadmap, and export button.
A local markdown wiki is boring in the best possible way. It is inspectable. It is durable. It can be backed up. It can be diffed. You can see what the model changed. You can roll back bad edits. You can build small tools around it.
For serious knowledge work, boring infrastructure wins.
The Product That Wants to Exist
Karpathy described this as a hacky collection of scripts, but it points toward a much larger product category.
The next great knowledge tool probably will not look like a chatbot with an upload button. It will look more like an AI-native research environment: local-first storage, structured ingestion, citation-aware synthesis, automatic maintenance, visual outputs, health checks, version history, and agentic workflows that can operate across the whole knowledge base.
It will not just answer questions. It will maintain the context that makes better questions possible.
That distinction matters. A chatbot is reactive. A maintained knowledge base is cumulative. A chatbot gives you a response. A wiki gives your future self a better starting point.
This is also why the phrase "second brain" may finally become less embarrassing. For years, it often meant an aspirational filing cabinet: a place where you put things in the hope that future-you would organize them. But a real second brain should not merely store memories. It should preserve structure, update beliefs, surface connections, and make accumulated thought easier to reuse.
Until now, that required too much human discipline.
Now the maintenance can be delegated.
The Real Workflow
The practical workflow is almost disappointingly simple.
Collect raw sources. Let the LLM compile them into a structured markdown wiki. Use Obsidian or another markdown interface to browse the result. Ask questions against the wiki. Save substantial answers back into the wiki. Run periodic health checks. Repeat.
The flywheel is what matters.
Every source makes the wiki better. Every good question creates an artifact. Every artifact becomes future context. Every health check improves reliability. Over time, the system develops a shape that reflects what you actually study, write, build, and decide.
This is very different from asking an AI to summarize a PDF.
It is closer to having a research assistant whose main job is not to produce final answers, but to keep your intellectual workspace coherent.
That may be one of the highest-leverage uses of current LLMs. Not replacing your thinking. Not pretending to know everything. Not generating infinite disposable text. Just doing the maintenance work that makes serious thinking compound.
The Takeaway
The old second brain was a storage system with a discipline problem. It gave you a place to put everything, but it still depended on future-you to organize, connect, update, and clean it. That is why so many note-taking systems start as beautiful maps and end as quiet archives.
The LLM wiki flips the model. Raw sources remain the evidence layer. The markdown wiki becomes the compiled layer. The schema gives the AI rules for how to maintain it. Health checks keep the system trustworthy. Obsidian or any other markdown interface becomes the place where you inspect, question, and reuse the work.
RAG can help you answer a question from a pile of documents. An LLM-maintained wiki changes the starting point for every future question.
That is the core idea. The value is not just faster summaries, cleaner notes, or prettier graphs. The value is accumulated context. Every source, every query, every contradiction, and every useful output can strengthen the system instead of disappearing into another chat thread.
The human role becomes narrower and more valuable: choose better inputs, ask sharper questions, challenge weak synthesis, and decide what matters. The AI role becomes repetitive and structural: summarize, link, revise, cite, lint, and maintain.
That is how knowledge work starts to compound.
Your second brain does not need more folders.
It needs someone to maintain it.
And for the first time, that someone does not have to be you.
If you liked this article leave me a follow for more ai and obsidian advice: @Degen_calls_sol
