You write the instructions carefully. Three paragraphs: the conventions of the repository, the tone of the commit messages, the two directories nothing may touch. You paste them in and the agent starts well. Forty minutes later it does exactly what the second paragraph forbids. You go back and read what you wrote. It is still there, still clear. What you cannot see is the payload that actually reached the model on that turn: some of your instructions, a compressed account of the last half hour, two files fetched along the way, the output of three tool calls. What you wrote was one ingredient. Something else chose the mixture.

The bench is small and the wall is not

Start with the word itself. Context is everything the model can read during a single call — your standing instructions, the session so far, documents pulled in mid-task, notes it left itself, the results of tools, and the descriptions of what it is allowed to do. It is not a document. It is a working surface with a hard edge, measured in tokens, and every one of those things competes for the same room.

Think of a repair bench. The bench is small on purpose, because you need to see what is on it. Everything else lives in drawers along the wall, each one carrying its name and a line saying what is inside. You do not carry the wall to the bench. You read the fronts, pull open the one drawer this job needs, and push it shut when the job moves on.

An agent runtime works the same way, and the drawers are its skills. A short index stays in front of the model at all times: a name, a sentence each. The full instructions and the tool schemas load only when a skill is actually chosen, then get dropped or compressed once the phase ends. An agent reads “database migration: creates and verifies migrations” and nothing more until the schema has to change. The browser skill and the deployment skill sit closed on the wall, costing it nothing.

Everything on the bench costs the task something

This is where the idea meets a decision you have to make. A runtime that loads every capability up front pays for all of them on every turn, used or not, and the instructions you wrote compete for room with the work the agent is doing right now. Extensibility stops being free: each new skill is a standing tax on the task in progress. Loading late turns that tax back into a cost you only pay when it buys something.

The same reasoning runs past cost. Keeping the whole history because keeping is easy is not memory, it is sediment; what belongs in the window is what serves the purpose in front of you. Before the runtime compacts, it should write a summary somebody can check, so continuity survives compression instead of being asserted. Retrieved material needs its origin and its expiry travelling with it, or the agent will act on a document that stopped being true last Tuesday. And opening a drawer is also granting a capability: loading a skill lazily is the same instant in which its tools become reachable, so the sandbox has to be there when it opens, not somewhere in the design notes. A description too thin to choose from fails in the other direction — the agent reaches into the wrong drawer confidently.

What reaches the model is a decision

Each pass of the loop you built makes that decision again. Something selects what the model will see, assembles it, and clears it — before every call, all day. Which means the token budget, the memory layer, the choice of tools and the threat model are not four problems. They are one problem seen from four sides, and it is the problem that decides whether an agent still behaves the same way six hours into a task.

It also explains a result that looks unfair from outside. Two teams run the same model on the same task and get different reliability, and the difference is not in the weights. One of them treats the window as a place to pour things into, the other treats it as a resource with an owner, a budget, and rules about what earns a place there this turn.

So when the behaviour drifts, rewriting the instructions is rarely the repair. The question is what the runtime put in front of the model at the moment it went wrong, and why that, and not something else. Your prompt is an input to that decision. It is not what the model reads.