Context Engineering

Prompt engineering asks what to say to a model. Context engineering asks a bigger question that only appears once a model runs in a loop: of everything that could occupy the window on this turn — instructions, tool definitions, retrieved documents, prior steps, the last tool’s output — what actually earns its place?

Treating the window as a budget
Context is finite and not uniformly valuable, so the work is allocation rather than wording:

Tools — every registered tool’s schema occupies space on every turn, and a crowded catalog both costs tokens and makes selection harder, which is the argument for loading tools dynamically.
Retrieval timing — fetch a document when the step needs it, instead of pre-loading everything that might be relevant.
Tool output — a four-thousand-line log is rarely worth its tokens; truncate or summarise it before it enters the history.
History — old turns get compacted, while the goal and the live constraints get restated so they sit near the end, where attention is strongest.

Why it decides whether an agent works
Agent failures are frequently context failures wearing other clothes. A plan drifts because the constraint that shaped it fell out of the window ten steps ago. A tool is called with a stale parameter because a newer observation was buried under noise. An injected instruction in a retrieved page is obeyed because nothing marked it as untrusted data. None of that is fixed by a better-worded prompt — it is fixed by deciding, deliberately, what the model sees at each step.

Context engineering is the deliberate design of what enters a model’s context window at each step of an agent’s loop — system instructions, tool schemas, retrieved documents, compacted history, trimmed tool output. It treats the window as a scarce budget to allocate rather than a prompt to word well. Most agent failures trace back to it: a constraint that fell out, an observation buried in noise, untrusted text read as instruction.

A good manager does not hand a new hire the whole filing cabinet. They hand over the brief, the two documents that matter today, and a note about what was already decided — because too much paper is as unhelpful as too little.

Context engineering is doing that for software working towards a goal on its own. At every step, someone has to choose what the program gets to see: the instructions, the tools it may use, the notes from earlier steps, the result it just received.

It matters because most failures look like stupidity and are really forgetfulness — the program was never shown the thing it needed.