The context window is a governed resource

Somewhere in the last two years, deciding what goes in the context window quietly became a job attached to everyone who works with AI agents. 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

There is one question retrieval answers 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 for wrong reasoning, hallucination, not being 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. And multiple parties compete for the space, the task description against the retrieved knowledge against the coordination state against the tool results against 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, whether 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 the claim, 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.

The bear case, taken seriously

The strongest argument against this entire product category deserves better than a dismissive clause, so here it is at full strength. Context windows keep growing. Continual learning is coming. Perhaps an external state layer is a bridge technology, and the bridge’s window is closing.

Half of that case is wrong about where the problem lives, and the mistake is instructive. The window was never the constraint; selection is. A ten-million-token context does not tell you which tokens matter. It multiplies the candidates competing for the same attention, and the empirical record is consistent: models reason measurably worse over huge undifferentiated contexts than over small governed ones. Fill a vast window with material chosen by resemblance and you have built a bigger haystack. Fill a mind, human or machine, with ninety percent junk and it performs like what it ate. Capacity does not solve curation. Capacity is what makes curation the problem.

The continual-learning half fails differently. Memory that lives in weights is testimony in its purest form: unauditable, unshareable between agents, uncorrectable by anything short of more training, and invisible to every governance question this essay cares about. A model that “just remembers” cannot show where a belief came from, cannot receive a correction as a record, and cannot hand its state to a colleague. Whatever continual learning delivers, it will not be provenance, authority, or a shared world.

And the honest concession, because an engaged bear case is only worth engaging honestly: growing windows really are eating the shallow end of this category. Products whose entire offer is “recall your last session” are being commoditized by raw capacity, and some of them will die of it. What capacity cannot commoditize is the governed part: who may write, what is still true, who is doing what, what may be held against whom. The library keeps getting bigger. That has never once made the librarian less necessary.

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 as a draft specification and a frozen pilot on an unmerged branch, evaluated so far against synthetic test states with known answer keys; the case matrix for evaluating it against our own live workspace, including adversarial cases designed to make it deliver the wrong thing confidently, is defined and not yet run. 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.