the knowledge base

My Teams folder is a GitHub repository. When I wrote that on LinkedIn, the same question kept coming back: sounds great, but how do I set that up myself? The answer is less exciting than people expect. A folder of markdown files, an instruction file, and an AI that has access to that folder. There’s no more infrastructure to it than that.

The interesting part isn’t the tool. It’s the question of who maintains that knowledge base, and who it’s actually written for.

In an earlier essay I described how I structure project knowledge: raw sources, a wiki, a schema. That was the personal side. This essay is about the layer above it. What happens when that knowledge base isn’t one workspace, but the foundation that both human and AI work from?

the archive nobody reads

Almost every organization has a knowledge graveyard. A shared drive, an intranet, a wiki that was set up in good faith and went quiet after three months. The pattern is always the same: the maintenance burden grows faster than the value, so people give up. And because the archive goes stale, nobody trusts it anymore, so it gets maintained even less. A document folder is an archive. You throw files into it and search through it later, if you even try.

Meanwhile those same organizations use AI as a chatbot with the memory of a goldfish. Every question starts from zero. The documents are right there, but every session has to plow through them again, and every summary gets derived from scratch.

My inversion: turn the archive into a knowledge model. The AI reads a new source, pulls out the essence and works it into existing pages. Contradictions get flagged, summaries sharpened, connections drawn. The knowledge gets compiled once and then kept current, rather than rebuilt with every question. The concept comes from Andrej Karpathy, who called it the LLM Wiki in April 2026. I apply it daily with Claude Cowork on my own files.

two readers, one source

What makes this pattern different from every earlier knowledge-base attempt: there are now two kinds of readers, and they read the same file.

The AI reads the wiki as working memory. For every question it first grabs the index, a catalog where each page is summed up in one line, and then dives straight into the right pages. That works surprisingly well up into the hundreds of pages, with no embeddings and no separate search infrastructure.

The human reads the same wiki as a reference. If you’d rather have something nicer to look at, point Obsidian at the wiki folder: a free program that shows markdown folders as a click-through knowledge base, with a graph view that shows at a glance what’s connected to what and which pages are loose ends. The AI makes changes based on the conversation, and you page through it in real time. The AI is the writer, Obsidian is your reading environment, the wiki is the result.

That’s the architectural point. No separate documentation for humans and separate context for machines, but one source of truth in the one format both read fluently: plain text in folders. No vendor, no subscription, no migration when next year’s tool goes by a different name.

who maintains what

The division of roles is the heart of the method, and it’s strict.

You’re the editor. You bring in sources, give direction, correct course where the AI gets it wrong. The raw sources are sacred: the AI reads from them but never changes anything in them.

The AI is the writer. Every cross-reference, summary, index line and log entry is its work. That’s exactly the boring work people let wikis rot over.

In practice there are only three operations. Ingest: process a new source, update the pages involved, add to the index and log, and flag whatever contradicts what’s already there. Query: answer a question with references to your own pages, and write a worthwhile answer back as a new page, so your questions build knowledge too. Lint: a periodic health check for contradictions, stale claims, pages with no incoming links, and terms that don’t have a page of their own yet.

And one habit that carries the whole thing: every work session ends with the instruction to update the wiki with what we learned that session. Five minutes, no separate documentation time. This is the entire trick.

from folder to foundation

You can start locally, in an ordinary folder on your own machine. The step that turns it into an organizational foundation is the repository. Put the folder on GitHub and you get version history, a backup and the ability to work with a team, all in one move. Every change the AI makes is a visible change in version control, reversible and reviewable like code.

That’s where the Teams-folder line comes from. Not because a repo is trendy, but because it’s the only shared storage an AI agent can genuinely work inside while every change stays traceable at the same time.

Fair is fair: writing in the same wiki with a whole team at once without conflicts is something I haven’t solved yet. Version control catches part of it, but the editorial question remains: when two pages contradict, who decides which one wins? For me alone, and for a small team with one clear editor, it already works today. The governance for ten simultaneous writers is work in progress.

The payoff, meanwhile, isn’t in searching faster but in seeing more sharply. When I ran into a comparable process at a second client after a CRM project with the first, I didn’t have to explain my project history all over again. The wiki held the pattern, the AI applied it to the new context and spotted differences I’d long since forgotten.

That, in the end, is what makes a shared knowledge base a foundation. Every earlier generation of knowledge systems was a place work had to go, after the real work, done by people who had better things to do. This is the first generation where the knowledge base pulls its own weight: it reads along, writes back and gets better with every session. A foundation that pushes back is no longer an archive. It’s a colleague who never moves on to another project.