Watch an agent work against a database nobody has told it about and it does the same thing every session: SHOW TABLES, then DESCRIBE this and DESCRIBE that, feeling its way across the schema one metadata query at a time, like someone crossing a dark house with their hands out. It is a house they have walked before and do not remember, and one that may have been quietly renovated since their last visit (a table added, a column renamed), with no note left on the counter to say so. It is not lost, exactly; it just wakes up every session having forgotten it was ever here.
The first time this genuinely bothered me, I was wiring up an MCP server against an internal database, and I typed something at the agent that turned out to be the whole idea: could we cache the list-tables and describe results and keep the structure written down on disk, so the model could make its decisions before we ran a single live query. I did not invent that thought; I just happened to have it. The same idea was loose in the world at the same moment. Andrej Karpathy published a version of it and supplied the name that stuck, the LLM wiki (a knowledge base the model compiles once and keeps current instead of re-deriving on every query), and within weeks dozens of people had built their own.
An idea, once enough minds accept that it is even possible, becomes a building block left lying around for whoever is standing close enough to pick it up; what we call genius is often just proximity to the right unfinished thought.
And these models came with no manual. Nobody shipped a guide to working with them, so everything we know we have had to find by experiment, out loud, and hand to each other; the whole field is people poking at a black box and posting what fell out. There is a quiet joke in that, given where this is going: we spend our days writing the manual the machine reads, and we never got one for the machine. The model's reading problem and the warehouse's cost problem turned out to be the same problem, and the answer to both is a map.
The model navigates; it does not skim
A person reads documentation the way they read a map of a city they half-know already: skim it, jump to the unfamiliar part, fill the rest from memory and a quick question to whoever sits nearby. The model has none of that. It reads top to bottom, literally, every word, every session, from a cold start, and there is nobody nearby to ask. So the first line of this project's instructions is not a friendly welcome; it is an order: always read the memory files below before you start anything. Underneath it sits an index (a few databases, a couple of hundred tables, counts, and links down into the detail), and the model reads that map and knows where it stands before it touches anything live.
The shape underneath is deliberately dull. One index at the top; one folder per database; inside each, the tables sorted by kind (the dimension tables that hold entities, the big event tables, the pre-aggregated rollups), every table a single row with its size and a link down to its full column list. Nothing loads until it is needed. The model reads a hundred lines to understand a warehouse it would otherwise have interrogated with a hundred queries.
A map, not a tour
The temptation, when documenting a system for a model, is to give it the tour: dump every table and every column into one enormous file and let the context window sort it out. That is not a map; it is the territory, photocopied. The entire value of a map is that it is smaller than the place it describes. So the index carries only enough to choose with: a name, a type, a row count, one line of what lives in the table, and a pointer to the rest. The model reads the index, forms a plan, and opens precisely the two files the plan calls for. I built the same thing once as a single MCP tool that returns a whole schema as one document instead of twenty describe-table round-trips; this is that idea, grown to a warehouse.
A colleague, Olek, had made the same move on a different project, for the agent that drove a design system: summarize what is available, build an index of it with pointers and examples, then aim the work at the index instead of the raw thing. His reason for it has stuck with me. It is faster, and you get fewer hallucinations, because you have handed the model a guided path instead of a dark house. A model that is guessing is a model that is free-associating, and a map is the whole difference between remembering and inventing.
The cheapest query is the one you didn't make
None of this is abstract thrift; the rediscovery has a bill. One month of an agent working that warehouse ran about twenty-six hundred queries: cheap per query and quick (a third of a second on average, seventy-odd dollars all in), but a real fraction of that was the model re-asking what it had already been told, in a fresh session that remembered nothing. The skill that wraps the index says the quiet part in its own instructions: read the local index first, because it is faster than a live query and spares the compute.
Reference data gets the same treatment one level down. The constants a warehouse leans on (status codes, call dispositions, the dozen lookup values every query joins against) do not change between Tuesday and Wednesday, but a mapless agent re-derives them on every run. So they are written into memory once and read from there, and the model stops asking the warehouse to remind it what it already established last week. For a decade compute was free enough to ignore one call at a time; an agent that pays by the token and the warehouse-second puts the meter back in your eyeline, and not making it look up what it can read off disk stops being hygiene and becomes the budget.
The cheapest, fastest query is the one you never had to make.
Skills ate the coding-standards document
A map tells the model where the tables are; it does not tell it that the big event tables will hurt you if you forget a date filter, or which key joins across databases, or that we do not SELECT-star in anger. That knowledge used to live in a coding-standards document: the one linked in onboarding, skimmed once, and never opened again while the real standards lived in code review and in a few senior heads. Now it lives in a skill, and the difference is everything, because a skill is executed rather than referenced. The model loads it and does the thing; there is no step where a human was supposed to remember.
I review a lot of the skills my team writes, and I keep distilling the same handful of rules out of them.
This is the same move as the philosophy document from the last note: taste you cannot teach in the room, written down where the model (and the new hire) can follow it. We have gone a step further and built a skill whose only job is to write other skills to this standard. The coding-standards document did not die. It grew hands and started doing the work itself.
Document once, and it becomes the standard
The instinct is to treat all this mapping as overhead, the thing you do at the end if there is time, which means never. That is backwards. On a new project you do it first: build the index, write the skill, set the conventions, get one thing genuinely right. Because the first thing you build well becomes the template the model copies. On a greenfield project the map is not a record of how the work was done; it is the first draft of how the work will be done, and once you have refined it by hand, with taste, every session afterward inherits it for free.
Here is the part that stays with me. I built every piece of this for the machine (the index, the stubs, the cached constants, the skill) because the machine was the one paying the toll for not having them. But the thing I ended up holding was the document I should have handed every person who ever opened that warehouse, saw two hundred tables, and had no idea where to start. The map a model needs and the map a newcomer needs are the same map. We just never got around to writing it down, because people muddle through and machines will not, and for years muddling through was cheap enough to hide what we had failed to write.
