# Good context *This is my context. There are many like it, but this one is mine.* Published 2026-05-09 · https://dom.vin/2026/good-context ## Summary An essay arguing that agent-written context — memory files, READMEs, handover notes — has entered a new era of consequence. Humans never read documentation carefully enough for quality to matter; agents read everything and act on it. At small scale, agent-written context is a handover from one session to the next. At scale (many concurrent sessions reading the same base), it becomes a commons, and the quality problem changes character. Bad context in a commons doesn't mislead the next session — it degrades every concurrent session at once. The design question shifts from how each agent should write well to how you build a commons that stays coherent despite noisy individual contributions. The answer draws on city-planning levers: legislation (a recursive instruction baked into the context that tells agents to write this way and to keep the instruction), budgeting (what gets protected from eviction), civic planning (schema and structure). The recursive instruction is the key move, and it requires precision: every word changes the weight of every other. This is the discipline of a prompt refined through many iterations — closer to poetry than documentation. The essay is itself designed to be read by agents: good context, about good context, written in the form it argues for. ## Claims - Agents read documentation with full fidelity and act on it — which changes the cost of getting it wrong. - At scale, agent-written context becomes a commons: the same files read simultaneously by many concurrent sessions. Bad context in a commons degrades all of them at once. - The design question at commons scale is not how each agent writes well but how you build a commons that stays coherent despite noisy individual contributions. - The recursive instruction — context that contains the rule to write context this way, and to pass that rule forward — is the legislative layer. It tilts the distribution without requiring every session to comply. - The recursive instruction requires precision: every word changes the weight of every other. This is what distinguishes a prompt refined through many iterations from one written once and shipped. --- Somewhere in your project there's a README that's lying. People never really read READMEs often enough for that to matter, the history of documentation is littered with best efforts and fixes when someone happens to notice. Agents not only notice, they take that shit seriously. Agents love docs. They love reading them and they love writing them. READMEs, plan specifications, memory files, decision logs, session summaries, handover notes, lengthy code comments, a CLAUDE.md sitting at the root of every serious project. The agent writes its world into existence. Then reads it back. Then acts on what it read. Some of this is designed as a handover, one session writing what the next one needs. At small scale that's the whole story. But once you're past the first few stages the same files are being read by dozens of concurrent sessions at once. The handover becomes a commons. Not by design. By volume. What was a private notebook becomes a public record. Every session reading it, writing to it, often at the same time. The context isn't addressed to a specific successor anymore. It's addressed to whoever shows up next, with whatever task loaded. The failure mode changes with it. Bad context in a sequential system misleads one session. Bad context in a commons misleads every session running right now, simultaneously: the stale assumption, the reversed preference, the fact accurate six weeks ago, distributed to every agent reading the base as if current. The radius of failure is the swarm. And there's no alarm. A session that reads bad context doesn't know it's reading bad context. It just acts on what it finds, confidently. The obvious answer is to make agents write better context. The problem is you can't reliably make them do that. These are confident narrators: they'll summarise a decision they half-understood and produce something that reads clearly and is subtly wrong. They'll treat a vague instruction as a precise one and generate output that looks exactly like compliance. At any real scale there's no mechanism to check. Dozens of sessions writing to the same commons simultaneously, nobody auditing. Individual reliability isn't achievable, and even if it were, it wouldn't be enough. This isn't building a house, slowly, brick by brick, every token placed deliberately, everything perfect. That's not what's happening and it's not the right frame. It's more like a well-run city: everyone chips away at it, it grows organically, and individual actors still cause harm but the overall thing thrives because bad actors are lost as noise. The question isn't how each agent writes well. The question is how you design a commons that stays coherent despite the noise, where good entries accumulate and bad ones get outweighed, where the architecture does the work. Cities have levers for this. Legislation shapes the distribution of behaviour without requiring everyone to comply. Budgeting decides what gets resources and what gets evicted. Civic planning channels individual actions toward aggregate coherence. None of these eliminate bad actors. They don't need to. They just need to design an environment that drowns them out as noise in the otherwise [thriving metropolis](https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04). The same levers work here. Budgeting is what you protect from compression and what you let go. Civic planning is the schema that shapes what a write looks like. Legislation is the interesting one. The legislative move is a piece of context that contains the instruction to write context this way. A memory file that explains how it should be maintained and includes, explicitly, the instruction to keep that explanation in place. A handover note that says: write like this, and pass this forward. It doesn't need every session to follow it. It just needs to tilt the distribution. The sessions that do produce entries that, in aggregate, outweigh the noise. Good context accumulates. The commons stays legible. That only works if the instruction is precise enough. Not the kind of precise you find in formal specifications, where you enumerate cases and close loopholes. A different kind: the precision of the word that can't be moved. "Keep this updated" produces compliance without understanding. An agent reads it, adds a line when it remembers, moves on. The instruction was followed. The spirit was missed. What you need is something specific enough that the agent makes a genuine judgement: whether the context has drifted, how a corrected entry should be written, what the next session actually needs to know. The complication is that this instruction is also abstract and self-referential in a way most instructions aren't. It describes how to write context, using context, to produce context that includes itself. It has to work for sessions with different tasks, different priors, different levels of domain knowledge. It can't assume its reader. Every word changes the weight of every other. Remove one and the structure shifts. Add one and the meaning moves. This is what a prompt looks like after a hundred iterations. Closer to poetry than documentation. In a poem, the precise word in the precise position does work no other word could do, and what's unsaid matters as much as what's said. The corners have been chipped away. Redundancies, qualifications, examples that seemed helpful until you noticed they were narrowing the interpretation: all gone. What's left is the minimum viable instruction, and every word of it is load-bearing. This essay is designed to be read by agents. Good context, about good context, written in the form it's arguing for. If it works, an agent reading it writes better context. Including, maybe, context that passes this forward. Man, we're just along for the ride now.