Back to Blog

The Wiki and the Intern

· Brad

I’d been keeping a directory of markdown files for my AI agents to read—notes, decisions, things I didn’t want to re-explain. Useful, right up until it wasn’t. Too many files, all of it raw. Nobody had decided what mattered. An agent could read it, but reading a landfill isn’t the same as knowing something.

Two Ideas That Clicked

A friend mentioned they used an “LLM wiki,” so I looked it up—it’s a pattern Andrej Karpathy published earlier this year. The idea that clicked wasn’t the wiki itself; it was the curator: something whose only job is to decide what’s worth keeping, dedupe it, and write it down properly. Raw notes are an input, not the product.

Separately, I’d heard about harness engineering—the scaffolding you build around a model so it can do real work, where each session starts cold and the agent turns up with no memory of the last. Then I heard the framing everyone reaches for now: the agent is an intern. Not a magic genius—an intern. Fast, capable, no memory of yesterday, and only as useful as the context you hand it. Putting those together is what clicked—the harness is the handbook you write for the intern.

And that’s where it meets the wiki: the intern needs a good handbook, so you write it properly and have something curate it.

The Interview

I don’t write the raw documents cold. I get the intern to interview me first.

It asks better questions than I’d think to answer on my own, because it’s probing for the gaps rather than narrating what I already know. The stuff it drags out is the context I know so well I’d never think to write it down—the judgement I’d quietly assumed couldn’t be handed over. That turns out to be the valuable part, precisely because it only lives in my head. The interview is how it gets out. Then the agent writes it all up—and the raw documents run long, many pages each. That bulk is exactly why they need a curator before they’re any use.

The Curator

The curator is a dedicated agent prompt. It ingests those raw documents into the wiki: dedupes, looks for anomalies, and holds the writing to a strict standard—correct and direct, no fluff. The quality prompts are deliberately harsh, because an LLM left unattended will happily generate plausible filler.

Every entry has a title and a corresponding why—why this section exists, why it matters. I added the “why” to force the model to think about purpose instead of padding. That was the whole intent. It turned out to do a second thing I never designed, which I’ll come back to.

An Index, Not a Pile

The wiki has a main page with a contents list, and for a while I thought that was just tidiness. It isn’t. It’s the whole point.

An intern can’t read the entire filing cabinet every morning before starting work. Neither can an agent. The context window is finite, and stuffing everything into it doesn’t just cost tokens—it makes the agent worse, because the signal gets buried in the noise. So the index stays in context, and the agent pulls a single page only when it needs it. Look it up, don’t memorise it.

If that sounds familiar, it’s the same shape as Claude Code’s Skills: a short name and description always loaded, the full body fetched on demand. I hadn’t set out to copy anything. I’d hand-rolled Skills in flat files without realising it.

The Part I Didn’t Plan

Which brings me back to the why on each entry—the line I’d added to stop the model padding.

It’s a retrieval trigger. It tells the agent when an entry is relevant, which is exactly the signal it needs to decide whether to pull the body into context. So the index isn’t a contents list anymore. It’s a routing table. The agent reads the why, decides “that’s the one,” and loads it.

I’d written that line for prose quality. It turned out to be the thing that makes the lookup work. That’s twice now I’d built something for one reason and found it quietly doing a second, more important job—and both times the second job had a name someone at Anthropic had already given it. That’s the part that stuck with me. You can reason your way to these structures from first principles, building for yourself, and land exactly where the people designing agent harnesses landed. The constraints are doing the converging, not the cleverness.

Why I Built It in HTML

I wanted to read the wiki too, not just the agent. I don’t mind markdown, but I don’t hand-edit these files anyway, so what matters is how the rendered version reads—and HTML reads better. It gives me colour, a contents page I can scan, and Mermaid diagrams rendered as pictures, which I take in faster than the equivalent paragraph. I kept the styling deliberately limited—a small, fixed set the agent works within—so pages stay consistent instead of each one reinventing the layout. Same source, two readers; serving the fussy human serves the agent fine too. (An Anthropic engineer, Thariq Shihipar, later made the case that agents read HTML better than markdown anyway.)

Where It Falls Down

It’s not solved. The biggest problem is duplication. The same fact ends up written in two places, the copies drift, and the agent starts giving different answers depending on which one it pulled. Left alone, a curated wiki rots back into the landfill I started with—just a tidier one.

What I think it needs is to be compiled, like code. A glossary as the single source of truth—one concept, one definition—and everything else references it instead of restating it. Then a build step that fails when a term is used but never defined, or when the same thing is written down twice. The mechanical checks are easy. The hard one is catching two pages that quietly contradict each other on the same concept—that needs the LLM to read for meaning, and it’s fuzzy, and I haven’t nailed it. You reduce the entropy; you don’t eliminate it.

And maintenance is real work. The curator has to keep ingesting, I have to keep feeding it, and the curator itself introduces broken links and bad merges. The wiki is a thing you tend, not a thing you finish.

What I’m Taking Away

Picturing the agent as an intern made me realise something I’d rather not have. The interview was the tell: the stuff it pulled out of me—the judgement I’d assumed couldn’t be written down—wrote down fine. A lot of what I’m paid for is just context in my head, and context can be exported. Interviewed out, curated, compiled, and handed to something that reads it back faster than I can.

I don’t have a tidy resolution for that. Export enough of what’s in your head and the obvious question is what’s left that’s only yours. I keep building it anyway, because not understanding the thing that’s coming for the work seems worse than the alternative. Better to be the one writing the handbook than the one it replaces—and for now, those are the same person.

— Brad


Disclaimer: This project is conducted in my personal time. All thoughts and opinions expressed here are solely my own and do not represent any current or former employers.