Context is not a bucket — it is a delivery problem

The most common mistake in context engineering is treating the context window as one big bucket of text. It is not. It is a delivery mechanism for the right knowledge at the right moment, and treating it as a bucket is the cheapest way to make an agent both more expensive and less dependable.

This sounds obvious when stated plainly, and it is still the most common mistake. The instinct is to dump everything the agent might need into the context and let the model sort it out. The model is good at sorting. It is not good at being charged for sorting the wrong thing, and it is not good at being trusted to find the current authoritative version of something buried in a bucket.

What the bucket gets you

A bucket gives you two things: simplicity and a false sense of coverage. It is simple to put everything in. It feels like coverage, because everything is in there somewhere.

What it does not give you is dependability, and it does not give you cost control. The agent is now paying to read knowledge it does not need, and it is harder to tell which knowledge it acted on, and the current version of the thing it needed is buried under three older versions and a half-finished draft.

This is not a model problem. The model can read a bucket. The bucket is a knowledge problem dressed up as a context problem.

What a delivery model gets you

A delivery model asks a different question: what does the agent need at this moment, in what shape, and how do we know it is current and permitted? The context window is then a delivery surface, not a storage surface.

The practical effect is usually smaller contexts, cheaper runs, and fewer confident errors. The agent is not paying to read the whole document library. It is paying to read the specific knowledge it needs for the specific action it is about to take — and that knowledge is the current version, in the shape the agent can use, with the permissions the agent is allowed to act on.

This is the applied form of the knowledge-layer argument. Context engineering is where the idea that knowledge is a first-class layer becomes a daily engineering decision.

The usual mistakes

The bucket instinct shows up in a few predictable forms. Knowing them is half the fix.

The whole-document dump. The agent gets the entire document, the entire policy, the entire procedure — because it might need any of it. This is the most common form, and the most expensive. The agent pays to read the whole thing and then acts on a small part of it, with no clean way to say which part.

The stale version buried in the bucket. The current procedure is in there, but so is the one from two versions ago, and the half-finished draft, and the note that says "ignore this after Q2." The agent does not know which one is current unless the knowledge layer says so.

The unowned knowledge assembled on the fly. The agent pulls from whatever is easiest to reach — the shared drive, the ticket, the chat, the spreadsheet — and assembles its picture from whatever is least governed. This is the enterprise version of the bucket problem.

What to do instead

The fix is not a technique. It is a discipline: design the context as a delivery surface, with the same care you would design any other interface.

For most projects, that means three things:

• Send less of the right knowledge, not more of everything.
• Make currentness explicit — the agent should be able to tell what is current, not guess.
• Make the basis retrievable — when the agent acts, it should be able to show what knowledge it used, in what shape, and whether it was permitted.

These are the same ideas behind token savings and grounding. They are not separate goals. They are one discipline seen from two sides: cheaper runs and more dependable runs are both the result of taking the knowledge layer seriously.

The boring payoff

The boring payoff is the best one: an agent that costs less, acts on more dependable knowledge, and can show its basis when asked. That is not a model achievement. It is a knowledge achievement, delivered through a context window designed as a delivery surface rather than a bucket.

The model is still doing the reasoning. The knowledge layer is doing the rest.