Usage & Prompting
Context Engineering
The extension of the prompt idea: not just phrasing the question but designing the entire information environment: which documents, which tools, which history, which format the model gets to see. In agentic systems this decides quality more than any single phrasing. Context is a scarce budget; filling it well is engineering work.
An example
An agent is supposed to handle a complaint. What belongs in its context? The complaint, of course. The customer's order history, but the last three transactions or all sixty? The complaints policy in full or only the relevant section? The correspondence so far in full or summarized? Each of these decisions costs tokens, time, and accuracy. Too little context produces wrong answers, too much produces expensive and equally wrong ones.
A closer look
This is the question of what should be in the window at all for a specific request: which documents, how split, in what order, with what summary of the history so far. It is selection work and can be measured.
Why it matters
Context engineering is the discipline that prompt engineering became when single requests turned into multistep systems. For an agent that takes twenty steps, the question is no longer how to phrase a sentence but what still has to be available at step seven and what can be condensed. That is architecture work and the place where the operating costs of agentic systems are actually decided, not in the choice of model.
Commonly misunderstood
More context is not better. Contradictory or outdated pieces in the window degrade the answer more reliably than missing context would.