The context window is a governed resource

Somewhere in the last two years, a new job quietly attached itself to everyone who works with AI agents: deciding what goes in the context window. The industry even has a name for it now, context engineering, which makes it sound like a discipline. In practice, in most stacks, it is a vibe. Retrieve what resembles the query. Stuff the window until it’s full. Truncate from the top when it overflows. Pray that the load-bearing fact made the cut.

The window is being treated as a bucket. It is actually a budget, and the difference between those two words is the subject of this essay.

Similarity is not materiality

Retrieval answers one question extremely well: what stored text most resembles this query? That question is genuinely useful, and embedding search earned its place in the stack. But it is not the question an agent’s next decision depends on. The operational question is: what does this decision depend on? And the overlap between the two is much smaller than the industry’s architecture diagrams assume.

Consider an agent about to modify a payment code path. The ten most similar files are the easy part; any index can produce them. What the decision actually turns on is different in kind: the correction that superseded yesterday’s claim about the retry behavior. The decision record that constrains how errors must surface. The fact that another agent holds a lease on the module right now. The freshness of the test results the agent is about to trust. Whether the claim it’s building on was verified against source or merely asserted by another model in a hurry.

Not one of those is a similarity property. They are state properties: truth over time, authority, contradiction, concurrency. A retrieval system cannot rank by them, because the text of a document does not carry them. A paragraph does not know it has been superseded. An embedding does not know its source file changed this morning. Similar is what a fact looks like; material is what a fact does. The window should be allocated by what facts do.

Errors follow context

When an agent makes a bad call, the postmortem habit is to blame the model: wrong reasoning, hallucination, not smart enough. Look closer at real failures and the proximate cause is usually upstream of the reasoning. The agent didn’t know about the constraint. It acted on a fact that had been corrected two days earlier. It duplicated work another agent had finished, or undid work another agent was mid-way through. The reasoning was fine; the world model it was handed was stale, partial, or contradicted elsewhere.

Here is the detail that should bother you more than the failures themselves: in most stacks you cannot even establish which of these happened, because nothing records what the agent was shown at decision time. Context assembly happens in glue code, is influenced by race conditions in retrieval, and leaves no trace. “What did the agent know, and when did it know it” is the first question of any serious audit, and today’s context pipelines cannot answer it. The most consequential input to every agent decision is the one input nobody logs.

Allocation problems want governance

Frame it as what it is. The context window is a scarce resource; frontier windows are large, but attention quality degrades as they fill, cost scales with occupancy, and there is always more candidate state than room. Every token spent on look-alike text is budget not spent on the fact that would have prevented the error. Multiple parties compete for the space: the task description, the retrieved knowledge, the coordination state, the tool results, the conversation itself.

A scarce shared resource, contested by multiple claimants, where allocation decisions have consequences and mistakes need auditing afterward: we know what that is. That is the setup for every resource-management problem computing has ever solved, and computing solved none of them by vibes. Operating systems don’t let applications hand-manage physical memory on intuition; there is paging, protection, and accounting. Nobody would accept a filesystem that returned “whatever blocks look similar to your filename.” Yet context, the working memory of every agent decision, is managed today like a scratch disk without a memory-management unit: no protection, no provenance, no record of what was resident when the fault happened.

The fix in every prior case had the same shape. The resource got a governor: a layer whose job is deciding what gets the resource, under declared rules, leaving a record. Context is due for its governor.

What “governed” would mean

Governed context delivery is a small phrase for five concrete properties. None of them is exotic. Each is computable. And, notably, none of them is available to a retrieval index operating alone.

Selected by materiality. What enters the window is chosen for the decision at hand: the shape of the task determines which classes of state matter (constraints, corrections, concurrent work, obligations), and selection is scored against that, not against textual resemblance.

Provenance attached. Every delivered fact arrives carrying where it came from and its verification state: source-grounded, inferred, or merely claimed, and by whom. The agent can weigh a fact by its pedigree instead of treating everything in the window as equally true.

Freshness declared. Staleness is explicit. A fact whose source changed since verification says so. The most dangerous item in a context window is a confident sentence about a world that has moved on.

Authority respected. Delivery is scoped to what this agent, on this connection, is entitled to see. Context assembly is an act of authorization, and pretending otherwise just means the authorization happens implicitly and wrong.

Receipted. The delivery itself is recorded: what was selected, what was excluded, under which budget, for which request. Afterward, “what did the agent know when it acted” is a query, not an archaeology project. And because delivery is measured, selection can be improved against reality instead of against anecdote.

Why this needs a state layer underneath

Read the five properties again and notice what each one quietly names. Provenance requires maintained records of where claims came from and how they were verified. Freshness requires knowing what changed, which means watching sources over time. Authority requires durable identity and scoped permissions. Materiality requires knowing what work is active and what obligations are open, which means coordination state. Receipts require a journal that outlives the session.

That is a list of things a retrieval index does not have, and cannot have, because text alone does not carry them. It is, more or less item for item, a description of a state layer: a system whose job is maintaining what is true, what changed, who is doing what, and who may see what. This is the honest form of a claim we make about our own product, and it cuts both ways: a state layer is what makes governed delivery possible, and without governed delivery a state layer is a warehouse with no loading dock. The two are halves of one design.

You cannot govern the delivery of state you do not maintain. Whatever stack you run, that sentence is the test. If the answer to “was this fact superseded?”, “who else is working here?”, or “what was this agent shown?” lives nowhere in your system, then your context pipeline is not engineering. It is hope with an API.

What changes if it works

Orientation stops being a lecture. A fresh agent’s first turn contains the state of the work: what matters now, what changed since last session, who is doing what, what needs attention, each item carrying its provenance. Not a summary someone wrote; a projection of live state.

Audit becomes a query. When an agent errs, the first question has an answer with receipts. Was the constraint delivered and ignored, or never delivered? Those are different bugs, in different components, and today they are indistinguishable.

The budget starts buying materiality. Tokens go to the correction, the constraint, the conflict, because those are ranked by what they do, not by what they resemble. The window gets smaller and better at the same time, which is what governed allocation has done for every resource it has ever touched.

And selection itself becomes an empirical discipline. Once delivery is receipted, you can score it: did the material fact make the window on the turns where it mattered? That closes the loop that vibes-based context engineering cannot close, because you cannot improve what you never recorded.

Where we actually are

We are building this now, on the state layer we already run our own development through, and honesty about the state of it matters more to us than the impression of finish. The governed selector exists and is being evaluated the only way we trust: against cases with known answer keys drawn from our own live workspace, including adversarial ones designed to make it deliver the wrong thing confidently. Rollout is deliberately gated behind that evidence. Selection under a real budget is a genuinely hard problem; our materiality models will be wrong in ways the receipts will document, and that is precisely the point of building the receipts first.

So the claim here is not “we solved context.” The claim is structural: decision-relevant delivery is the right shape for the problem, it is only buildable on top of maintained state, and every stack that treats the window as a bucket will keep paying for it in errors nobody can audit. The context window is the most consequential real estate in the agentic stack. It deserves what every other scarce resource in computing eventually got: a governor, rules, and a paper trail.