A while back I read about Andrej Karpathy’s LLM Wiki idea. The pitch is simple. Instead of RAG, you have the model incrementally maintain a persistent, interlinked markdown wiki. Knowledge compounds over time instead of getting re-retrieved on every query. It’s the same guy who reframed “prompt engineering” as context engineering, and there’s a ton of talk about the wiki idea right now.

It looked interesting. I already had a knowledge base running for one of my agents, and keeping it current took enough effort that I wondered if I could lower it. I decided to give it a shot.

Turns out yes. But the more interesting part was what I learned living in it. Once your primary reader is a model instead of a person, the old wiki instincts start working against you.

A human skims. A human tolerates a little clutter. A human quietly ignores the stale paragraph at the bottom of the page, because they can tell it’s old. A model does none of that. It reads everything you give it with equal weight. That contradiction you’d have glossed over becomes a coin flip in the answer.

So the whole thing has to be built to stay true over time. On purpose. With tools that enforce it. That constraint turns out to be clarifying. None of the core idea is novel. What I want to share is what it actually looks like once you commit to it, and what it’s like to arrive here from the RAG side.

Where this comes from

The concrete case is BrandCast, my passion project. Specifically its marketing agent: the repo that holds everything the agent needs to know about the product, the positioning, and the audience, and everything it produces from that.

It didn’t start as a wiki. It started as a local RAG store I queried over MCP. The agent asked a question, the retriever pulled the relevant chunks, and that was the datasource. That was a solid workflow. It worked. But it had a few challenges I kept bumping into.

The biggest was chunking. For the retrieval to rank well, each document had to carry frontmatter, and the whole document had to load as a single chunk. So I ran a hybrid setup on a local CPU-bound embedding model to make that work. The frontmatter existed partly to feed the ranker.

Ranking itself was the second challenge. RAG has to assume the top-ranked results have some relationship to each other. That put a lot of weight on the frontmatter and on what I named things. Get the naming slightly off and the wrong chunk floats to the top. So I had to be careful, deliberately, all the time.

Third, keeping it current took real effort. Skills, scripts, and workflows all existed to keep the corpus fresh, and to remind the harness to actually update it after it wrote something.

And the store itself couldn’t live in source control, for obvious reasons. So any fresh checkout had to rebuild the entire database before the agent could do anything.

So I ran an experiment. I threw out the retrieval layer and turned the whole repo into a wiki the agent reads directly. No embedding step, no separate store. The knowledge is just files, structured so the model can walk them. It’s the same less-infrastructure, same-capability move I made when Google’s File Search API let me delete seven database tables from a RAG pipeline, just taken one step further: this time the retrieval layer went away entirely.

It’s turning out well, and the challenges got smaller across the board. The frontmatter didn’t go away; it got promoted. In the wiki it isn’t a hint for a ranker, it’s mainline. It’s essential to how the whole thing is organized, so I maintain it because I have to, not as a tax on top.

Maintenance dropped the most. When the model writes a new doc into the wiki, it naturally matches the format of its neighbors, because it can see them. There’s far less fighting and far less reminding the harness to update the wiki than there was to keep the RAG corpus in sync. And because it’s all just files, a fresh checkout is ready to go. Nothing to rebuild.

That’s the payoff for a coding-adjacent workflow like a marketing agent. The agent already lives in a repo and reasons over files. Making the knowledge base also a repo means it reads docs the same way it reads code. It’s the same instinct behind context-driven development: the agent needs what the code doesn’t say, not just what it does, and a wiki is where that lives. That’s the setup the rest of this post is about.

Two axes, not one folder tree

The content splits along two different questions, and I keep them physically separate.

  • Knowledge, organized by subject. The base truth. Research, positioning, reference material, the facts. What is true.
  • Content, organized by audience. The stuff you actually produce for people. Organized by who it’s for, not what it’s about.

Knowledge feeds content. A subject folder in the first tree has a matching leaf in the second.

Keeping them apart stops the two from bleeding into each other. That’s the failure mode where your reference docs slowly turn into half-finished drafts, and your drafts start getting cited as if they were settled fact. Once that starts, you can’t tell what’s true anymore. Neither can the model.

The truth system is the whole point

This is the part that makes it work. It’s two engines.

Facts are atomic and sourced. Every load-bearing claim, especially any number, lives as its own small record. It has a stable ID, a source, a supporting quote, and a confidence rating. Anything customer-facing that cites a statistic has to point back to one of these IDs. A linter fails the build if it doesn’t.

Here’s the rule I keep coming back to: verifiability is the gate for whether a fact gets recorded at all. Confidence is a separate axis that governs where you’re allowed to use it.

Don’t conflate “is this accurate” with “should we use it here.” Those are two different questions. Collapse them and you’ll either block good facts or ship shaky ones.

A record looks about like this:

id: fact-0412
claim: "The service processes X events per second at peak."
source: "internal load test, 2026-06"
quote: "sustained 12,400 req/s over a 10 minute window"
confidence: high   # governs where this is allowed to appear

Documents carry a review marker. Each piece of collateral declares who it’s for, when it was last looked at, how often it should be, and which canonical guides it depends on.

That last one is the clever bit. There’s a small fixed vocabulary of dependency tokens, one per high-blast-radius guide. When one of those guides changes materially, it fires a review of every document that declared it depends on it.

You change the pricing guide once. The system hands you the list of everything downstream that now needs a second look. No more hunting.

Write only what’s true now

This is the rule I violate most, and regret every time.

The instinct, honed by years of human-facing docs, is to annotate. Add a “Correction:” note. Leave the old value next to the new one “for context.” Keep a paragraph about the thing you shelved, in case someone wonders.

Don’t. For a machine reader, the shelved paragraph isn’t context. It’s noise that competes with the truth.

Write the current claim cleanly and delete the rest. Put dates that matter inside the claim itself (“twelve dollars, effective April 1”) rather than as metadata that says “last reviewed.”

The one time you keep a mention of a dead thing is inside an active guardrail: “do not rebuild this.” That sentence is operative. Everything else about the dead thing is just weight.

Expect big reductions when you clean. If a pass through the wiki isn’t deleting a lot, you’re probably being too precious.

One home per fact

Every fact gets exactly one canonical location.

When a research sweep turns up something new, you promote the finding into its canonical home. Then you throw the sweep report away. The report was scaffolding.

If you keep it, it ages into a second, quietly conflicting source of truth. It becomes the place where dead positioning goes to survive. A parallel store always rots. One home, every time.

Tools do the enforcing

None of the above holds up on discipline alone. It holds up because there are scripts.

  • A structure linter for the wiki: dead links, orphan pages, missing markers.
  • A content linter for the truth and voice rules: uncited stats, banned phrasings, naming slips.
  • A freshness report that reads the facts’ review windows and tells you what’s expiring.
  • A dependency audit that checks the review-token wiring and catches the doc that has a price in it but forgot to declare it depends on pricing.

Run them, read the output, fix what’s real.

Here’s the nuance. A fair amount of what a linter flags is a false positive. The right move there is usually to make the tool smarter, not to contort the writing around it. But the tool catches the drift you wouldn’t have. That trade is worth it.

Keep the artifacts out of the repo

Text sources only. The recipe to regenerate an image lives in the repo. The rendered image does not.

Public renders go to object storage. Internal ones go to a drive. The binary never gets committed. You track the thing that can rebuild the artifact, not the artifact.

Keeps the repo small, diffable, and honest about what’s actually source.

Procedures as skills

The recurring jobs get encoded as skills the model can invoke. A grading gate that scores a draft against the voice rules before it’s called ready. A research routine. A cleanup pass that hunts stale content.

This is how the judgment gets to be consistent, instead of me re-explaining it every time. The gate runs the same way whether I’m watching or not. It’s the same posture I wrote about with agent feedback loops: the system is a living thing you maintain and tighten after every failure, not a doc you write once.

The posture that ties it together

Bias to action inside your lane. Reversible, in-scope work should just happen. The git history and the audit trail are the real safety net, not a permission prompt. Save the asking for the small closed list of things that are genuinely hard to reverse or reach outside the system.

Most of the time, if a mistake is one revert away, the right move is to make the call and move on.

The same move shows up elsewhere

I’ve since done the same thing for my coding framework agent. His name is Bob. It’s a little different there. The whole repo isn’t the wiki. The repo is mostly code, and the wiki is one part of it that the agent maintains alongside everything else. That’s actually closer to the canonical Karpathy setup people talk about online, where a dedicated wiki sits next to the raw sources. My marketing agent is the looser version, where the entire repo is the knowledge base.

Same idea either way. A machine-first knowledge base the model keeps true, with the discipline pushed down into tools. The shape flexes to fit the project. This has a very similar feel to the current trend of swapping out MCP servers to Skills with scripts that call APIs and SDKs.

That’s the pattern. A wiki that reads its own reader correctly. A truth system with teeth. And enough tooling that staying honest is the path of least resistance, rather than a thing you have to remember to do.

The tools change. The craft endures. It turns out that’s true even when the reader is a machine.