Filling the context window right, and reading it when an agent misbehaves

The window

A language model generates from its training and its context window, the bounded stretch of text it can see at once, and at run time only the window can change. Whatever the software around it supplies exists for the model only as tokens in that window: instructions, retrieved passages, the conversation so far, tool results. Every layer built around a model therefore ends as tokens in the window or nowhere, and an agent is a model with such a layer around it.

An earlier note in this series worked out what happens once the tokens are in: attention spreads over the window as shares of a fixed whole, and every token present thins what remains for those that decide the answer. This note asks what that arithmetic implies for how the layer is built and, when an agent misbehaves, how its window is read; both turn on what enters and how full the window is when the model generates.

What the field is building

Nearly everything built around a model decides the first of the two, what enters. Retrieval decides which passages enter; memory, what survives between conversations; helper agents return a result from a window of their own; skills keep a procedure outside until needed; compaction rewrites history to make room; staging swaps a large tool result for a small pointer. Each is a policy about the window, and we call the job they share window composition: deciding what enters a model's window and in what form.

Everything that enters adds to the second, which we call fill: how much the window holds when the model generates. The fuller the window, the more every generated token is affected, by dilution and, as measured below, by a shift in what the model does.

A misbehaving agent is read along the same two axes, and the operators of one we run in production for a client reported that it did not follow its instructions, while our telemetry showed it at 60% of its window without going straight to the answer: two readings of one complaint, a disobedient model or a window too full to answer from. We audited a month of its production turns and read the window, not only what the agent said, a method we call window accounting: reading the window before the output, in four questions.

Question 1: How full the window is and how fast it fills

The window's true size came first: the harness, the program that runs the model and builds its window, carried a stale figure for it, roughly a third of what the model allowed, since corrected; the shares below are of that smaller window, the one it believed it had.

We read the rate of fill off one conversation, 80 turns over five days: the share carried forward into the next turn climbed from 40% to 75% and crossed 60% near turn 50, so a window at 60% is a conversation near its fiftieth turn, and says nothing about what it holds.

Question 2: What each part is and which layer put it there

Taken apart, a turn is not made of instructions: the fixed prompt, what the harness sends on every turn, the delivered part of the agent's instruction document included, was about 6% of the window at turn start. Knowledge enters smaller still: a large result becomes a short envelope pointing at a staged file, 17,000 characters entering as about 200 tokens and the content only if the model reads the file; a skill's body, likewise, only if read. A helper's return comes back whole, the largest thing a turn adds and the one input with no ceiling, and history is the bulk of a deep turn.

The anatomy inverts the order one would design: the knowledge the agent depends on is the cheapest thing in its window and the most reduced on the way in, while what has already happened, history and helper output, fills it.

Question 3: How much of it serves the answer

Production tests whether that bulk serves the answer: across 5,966 questions in one month, every turn received the same instructions and only the history differed. Between fresh turns, the first five, and deep ones, the thirty-first onward, the agent pulled the framework behind its expertise on 34% of questions instead of 56%, cited without a fresh retrieval on 13% instead of 1%, and made half as many tool calls, 8.3 a turn against 16.6, answering more from the pile it already held.

Part of that is legitimate continuation, but every such failure the audit confirmed sat in the deep band; we call the shift fill drift: what a model does differently as its window fills, its instructions held constant. The 60% was real, then, but it was drift, not overflow, fill and behavior moving on one axis of turns, and not the larger part of the trouble, which the window could not show because it had never entered it.

Question 4: What never arrived

The larger part had never left the layer: the harness read the agent's instruction document only up to a limit nothing had measured it against, and well over half of it, by length, never reached the model. We call the distance the delivery gap: what was written for a model minus what reached its window. What arrived carried the agent's identity and its grounding directive to retrieve, cite, then interpret; what never arrived, its data-integrity rules, among them a labeling rule shipped in August for a July complaint, and a diagnose-first procedure three placements never delivered.

Production had run a natural experiment all along, one model given some rules and not others, and the delivered rules showed in behavior: no naive arithmetic on the numbers it was handed in all 71 turns where that rule applied. The rules past the limit behaved as if never written: the diagnose-first procedure fired on 38% of fresh questions, the model's own unprompted rate, and the August labeling rule, as specific as the arithmetic one, was broken again after its fix shipped past the limit.

Sorted by cause, the failures behind "the agent doesn't follow instructions" came out roughly three quarters the layer around the model and one quarter the model: on the layer's side, rules that never entered, delivered text that argued with itself and skill bodies never read into the prompt; on the model's, mostly long-context drift. An engine swap the next day, the one change that asks nothing of the layer, fixed none of the ten failure modes the audit found, at 2.2 times the cost per turn.

What we now build

The agent's latest working version is the four answers turned into structure, Question 4's first: the harness now measures the instruction document against its limit at every start, truncation is loud, and on production the document arrives whole, about 47 KB, cut from about 75 KB with every rule stated once. Closing the gap changed what else arrived: commentary meant for maintainers, written on the assumption it would never be read, came through as instructions once the file was whole and is now stripped before delivery.

Questions 2 and 3 changed what fills the window: rules once re-sent with every turn now enter once per conversation, a procedure the operator invokes is read before the agent acts, and helpers are used only where work runs in parallel. On production, turns that spawn a helper fell from about six in ten to under one in ten and the tokens a turn consumes by a fifth, against a same-engine control. Question 1 opened the window to roughly three times what the harness had assumed, a ceiling to measure against, not room to fill.

Five terms join the series vocabulary: window composition, what enters a model's window and in what form; fill, how much the window holds at generation; fill drift, what the model does differently as fill rises; the delivery gap, what was written minus what arrived; and window accounting, reading the window before the output.

A day apart, the engine swap changed the model and the reading changed what the model was given; building around a model is filling its window right, and fixing an agent is reading that window before believing its output.