Most of What an Agent Sees, It Admitted Itself

Every discussion of context as a scarce resource eventually arrives at what to do about the material already in the window: what to trim, what to summarize, what to replace with a reference. That is the downstream half of the problem. The upstream half is deciding what was allowed in to begin with, and it is the half that determines how much work the downstream half has to do.

Admission is the higher-leverage decision, and in most systems nobody makes it. It gets made by default, by whatever the retrieval layer returned, whatever the tool emitted, whatever the standing configuration loads before the request exists. The result is a context window assembled by accretion and then repaired by trimming, when the repair would have been mostly unnecessary had the door been governed.

What makes this harder than it sounds is that the party doing the admitting is usually not the author of the system. It is the agent, at runtime, deciding which tool to call and therefore what lands in its own window. Admission control cannot live in the prompt, because by the time a prompt is written the interesting admissions have not happened yet.

Admission and trimming are different problems with different economics

Trimming operates on material that has already been paid for. Something was fetched, transmitted, and placed in the window, and now a decision is made about how much of it to keep. Even the best trimming strategy is a recovery from a decision that already went badly.

Admission operates before the cost is incurred. Material that never enters costs nothing to hold, nothing to re-transmit on every subsequent request, and nothing in attention. It also cannot be trimmed badly, cannot be summarized lossily, and cannot mislead the model. Every failure mode trimming worries about is a failure mode of material that was admitted.

This is not an argument that trimming is unnecessary. Plenty of material has to enter and then stop being useful, and that is exactly the case trimming exists for. The argument is about ordering. Give one system a disciplined admission policy and crude trimming, and another unlimited admission and sophisticated trimming, and the first wins, because the second spends its sophistication on a problem it created. Admission is where the leverage is because it is the only point at which a piece of context costs zero.

The practical consequence is that “the window is filling up” is rarely a trimming problem. It is usually an admission problem presenting late.

The parties that set the volume have no stake in the budget

Context discipline is usually practiced on the channel someone sat down and wrote. That is not where the volume comes from, and it is not where the sizing decisions come from either.

Everything that reaches the window was sized by somebody. A retrieval layer decided how many documents constitute an answer, and returns twelve where three would have done. A tool author decided what a complete response looks like, and returns the whole record rather than the two fields anyone needed. Whoever published a page decided how long it runs. Each of those is an admission decision made at runtime, by a party that did not know the budget existed and would not have been consulted about it if it had.

This reframes where the control point sits. Governing what enters context by writing careful prompts is governing the one channel that was never the problem. The control has to sit at the boundary where material crosses into the window, which means at the tool layer, the retrieval layer, and the fetch layer. Those are the admitting parties. The prompt is a passenger.

It also explains why context discipline so often fails to survive contact with an agentic system. A human assembling a request applies judgment at assembly time. An agent assembling its own context applies judgment about which tool to call, and the tool decides what comes back. The judgment and the consequence are separated by a layer the agent does not control, so the agent cannot be the one holding the budget.

Relevance is the wrong criterion

The usual admission criterion is relevance, and relevance is a trap. Almost everything is arguably relevant to almost any task. A senior engineer asked whether a given document is relevant to a given question will nearly always find a thread connecting them, which means relevance cannot discriminate and therefore cannot be a policy.

The criterion that works is counterfactual. Would the output differ if this were absent? If not, it bought nothing and cost full price. That is a sharper test because it is answerable, and because it fails most of what relevance passes.

Standing constraints tend to pass it decisively. A rule the system would otherwise violate, a convention it would otherwise guess at, a version boundary it would otherwise break through: without these the output is confidently wrong in a way that is expensive to catch downstream, so their presence changes the action. Background material tends to fail it. Not because it is untrue or unrelated, but because the model would have produced the same answer without it.

The test has a second-order benefit worth naming. Material that changes the action is material the system can be held to. If a piece of context never alters an outcome, its presence cannot be validated and its absence cannot be detected, which makes it unfalsifiable weight. Context you cannot tell the effect of is context you cannot debug.

Where the counterfactual test gets genuinely hard is when you cannot run it in advance. You often do not know whether a document changes the answer until the model has seen it. This is real, and it is the argument for admitting the material and then measuring, rather than for admitting everything permanently. An admission that cannot be justified after the fact should not survive to the next run.

Exclusion is two different controls that should never share a list

The single most common structural mistake in context management is treating exclusion as one thing. It is two, and they have almost nothing in common besides the verb.

The first is a budget control. Some material is not worth the space it occupies, and it is recognizable by a poor ratio of signal to bulk rather than by category. Excluding it is an optimization. Nothing bad happens if it slips in beyond a slightly worse run, and nothing bad happens if you deliberately relax it, because the bulky thing is occasionally the thing the task is about.

The second is a security control. Some material must never enter regardless of budget, because its presence in a window is itself the harm. Excluding it is not an optimization. It does not trade off against quality, it cannot be relaxed for a good reason, and a single violation is a breach rather than a degraded run.

These controls differ on every axis that matters. Budget exclusions are advisory, contextual, and worth overriding. Security exclusions are absolute, universal, and never worth overriding. Budget exclusions fail softly. Security exclusions fail permanently, because once a secret has been in a window it has been transmitted to a model provider, written to whatever logs the system keeps, and is potentially reachable in the run’s own history.

The advisory property belongs to this particular budget and does not travel with the word. What sorts these two controls is not the label but the cost of a violation, and keeping bulk out of a window is advisory only because the cost of failing is a worse run. Other budgets in an agent system sort the other way on the same test. A ceiling on spend or on iterations is also a budget, and it is absolute, enforced where the agent cannot reach it, precisely because exceeding it costs something other than quality.

Put both in the same mechanism and you get one of two failures, guaranteed. Either the mechanism is treated as advisory, and now something advisory is guarding credentials, or it is treated as absolute, and now nobody can admit a build artifact for a legitimate reason without an argument about policy. The mechanism cannot be both, so it will be wrong for one of its two populations.

The design that holds is two mechanisms with two enforcement levels. The budget list is a heuristic maintained near the work, adjusted freely, and allowed to be wrong. The security boundary sits at the layer that actually performs reads, is enforced structurally, denies by default, and is not a list the agent or its author can casually amend. They look similar on a whiteboard, and conflating them is how a system ends up with credentials in a context window because someone loosened a performance setting.

An instruction not to look is not a control

Related, and worth stating on its own because it recurs. Telling a model not to read something is not exclusion. It is a request, and a request is adequate for the budget control and useless for the security one. That asymmetry is the whole of it. The same mechanism cannot serve both populations, and an instruction is the weakest available version of the mechanism, offered to the population that can least afford weakness.

Structural enforcement means the material is unreachable rather than forbidden. The tool cannot return it. The retrieval index does not contain it. The credential is not resolvable from the environment the agent runs in. Then the question of whether the agent tried does not arise, and the model’s compliance is not load-bearing. Instructions are for behavior and code is for guarantees, and the context boundary is one of the places that principle is violated most often, because an exclusion list feels like configuration when it is doing the work of access control.

Admitted context is admitted trust

Budget is the obvious cost of admission. It is not the most serious one.

Anything that enters the window is material the model reasons over, and the model has no reliable way to distinguish material that was placed there as data from material that was placed there as direction. A fetched document, a record from a datastore populated by users, a result from a third-party integration: all of it arrives in the same channel as the system’s own instructions and is read on the same terms.

That makes admission a trust boundary, not just a budget boundary, and it means the two exclusion controls above are joined by a third question at the door: not only “is this worth its tokens” and “is this permitted to be here,” but “who wrote this, and what happens if they wrote it adversarially.” Content whose author is outside the system’s trust boundary is input in the security sense, and admitting it unframed is the context-window analog of interpolating untrusted input into a command.

The mitigations are the ordinary ones and they are all admission-time decisions. Fetch narrowly rather than wholesale. Mark provenance structurally so external content is distinguishable from system direction rather than blending into it. Keep the privileges available during a run that has ingested external content proportionate to the trust in that content. None of these are available once the material is already in the window, which is the entire point. Trust decisions have to be made at the door, because after admission there is no door.

The standing layer is where the counterfactual test cannot be run

Runs are stateless by default, which is why every serious system grows a standing configuration layer: the rules, conventions, and constraints that must be present before the first token of the actual request.

That layer breaks the counterfactual test. The test asks whether material changes what the system would do, and answering it requires knowing what the system was asked. Standing context is resolved before the request exists. It cannot be selected for the task, because at the moment it loads there is no task. It is the only context admitted without the one piece of information that would justify admitting it.

That is not an argument for keeping the layer thin, which is the ordinary advice and is true for ordinary reasons. It is an argument about what belongs in it at all. The bar is not “important,” and it is not even “usually right.” It is “in force regardless of what comes next,” because that is the only claim the layer’s loading behavior can actually honor. Anything else is a bet placed before the cards are dealt, and it is charged whether it wins or not.

Material that is true sometimes has a different instrument: a scoped layer that resolves when its condition holds. Scoping is what restores the test at the configuration level. It converts an unconditional admission, which cannot be justified, into a conditional one, which can, and it lets material that changes the action in one context be present exactly there rather than forcing a choice between everywhere and nowhere.

Over-inclusion does not overflow, it crowds out

The intuitive model of context exhaustion is a container filling up and refusing more. That is the least interesting version. The behavior that actually costs systems is that admitting low-value material now leaves no room for high-value material later.

Every admission is zero-sum against a future admission you cannot foresee. Material admitted early, when the task looked simple, consumes space that the task, once it turns out to be hard, needs for the tool results and intermediate work that would have solved it. The system does not fail at the moment of the bad admission. It fails several steps later, on a request whose own composition looks entirely reasonable, and the diagnosis points at that request rather than at the decision that doomed it.

The dilution cost compounds this and is harder to see. Off-target material is not passive. The share of the window that determines the answer shrinks with every marginal admission, and that ratio is a property of the whole window rather than of any item in it, which means no individual admission can be blamed for it. A hundred defensible decisions produce a window in which the few things that decide the outcome are a minority of what the model is reading, and not one of the hundred looks wrong on review.

Both of these mean the same thing operationally. The cost of admitting something is not paid at admission and is not attributable to it. That is exactly the profile of a cost that goes ungoverned, and it is why admission policy has to be a design decision rather than an emergent one. Nothing in the runtime feedback will ever point at it.

Narrow admission has its own failure, and it is worse in exploration

The argument so far runs one direction, and taken too far it produces a different broken system.

Under-admission causes rediscovery. Material the system needed but did not admit does not simply go missing. The agent goes and gets it, or worse, guesses at it, or worse still, produces something confidently wrong that gets caught downstream at a cost far exceeding what the material would have cost to include. A narrow context that is narrow in the wrong dimension is more expensive than a broad one, because it pays the full price of the work and then pays again to redo it.

This bites hardest during exploration. When the system does not yet know what matters, an admission policy is a guess, and a confident wrong guess is worse than no guess. The honest posture in a discovery phase is broad admission followed by aggressive reduction once the shape of the task is known, which is the one case where trimming genuinely is the primary instrument.

That posture has a precondition, and it is worth being exact about it, because the opposite rule is correct nearly everywhere else. Admit broadly and reduce later only works when the party that admitted the material is the party that can see what it ended up using. An agent exploring its own context can. Anyone composing a handoff for someone else cannot: pass a generous slice to a delegated agent and you have no way to tell which part it quietly came to depend on, so the reduction is guesswork and the discipline has to run the other direction, starting minimal and adding deliberately. Breadth is defensible when admission and observation sit in the same place. When they come apart, it is not. This is also the strongest argument for delegating discovery, which turns a broad search into a single admission.

There is a second case worth naming. A system with no reliable basis for deciding what matters should not be making confident admission decisions. Curation, at the door or anywhere else, is a claim about what is not needed, and a system that cannot support that claim is better off admitting broadly and measuring than enforcing a policy it invented. Admission discipline is earned by knowing something about the task, and it is a mistake to perform the discipline before you have the knowledge.

What both cases share is that they are phases, not permanent conditions. Broad admission during discovery is a deliberate, bounded choice with a defined end. Broad admission because nobody decided is the ungoverned default, and the two look identical from the outside. The difference is entirely in whether someone chose.

The door is a design decision whether or not you design it

Context reaches an agent through channels, and every channel is an admission point that either has a policy or has a default. The default is not neutral. It is a policy that says whatever the retrieval layer returned is what the model deserves to see, that whatever a tool emits is worth its space forever, that any content the agent can reach is content it should reason over, and that anything ever worth writing into the standing layer is worth loading on every run for the life of the system. Written out, nobody would ratify that. It is what most systems run.

Designing it instead comes down to a small number of decisions, made once, at the boundary rather than in the prompt. Material enters because it changes what the system does, and material that cannot be shown to change anything leaves. The security boundary is enforced where reads happen and is never the same list as the budget heuristic. External content is admitted as untrusted input, marked as such, and scoped accordingly. The standing layer holds what is true on every run and nothing else, with everything conditional pushed into a layer that loads when its condition holds. Breadth is a phase you enter deliberately and exit deliberately.

None of this asks anything of the model. It asks the system to decide what the model sees, at the only moment when that decision is still free.