Context engineering is the new prompt engineering
For two years the advice was to write better prompts. That advice stopped paying off somewhere around the point where the model became reliably good at following instructions. What it still cannot do is infer information you never gave it.
What changed
Prompt engineering optimised the request. Context engineering optimises what is in the room when the request arrives. Once models could follow instructions dependably, the remaining failures stopped being about phrasing and started being about absence: the relevant file was not loaded, the tool output was truncated, the decision from twenty turns ago was no longer in the window.
Why it matters for deployment teams
Context is a budget with a hard ceiling, and it is the only budget in the stack that is spent by accident. Nobody writes code that leaks tokens on purpose; they write code that appends one more tool result, and then another, until the useful half of the window has been evicted. The failures this produces are the worst kind: not errors, just answers that quietly got worse.
What to do about it
Start by measuring. Log tokens-in per request with a breakdown by source: system prompt, retrieved chunks, tool output, history. Most teams discover that one category dominates and that they guessed wrong about which. Then apply the three levers in order. First, stop sending what is not needed — sandbox verbose tool output and return references instead of contents. Second, compress what must be sent — summarise old turns, deduplicate overlapping chunks. Third, only then consider paying for a longer window, which is the most expensive and least effective of the three.
The part teams skip
Persist memory outside the window. A session that dies with the context is a session the user has to rebuild by hand. Write durable state to a store the agent can query, and pass the model a pointer rather than the payload. It is the same idea as pagination, and it is what separates a demo from something a colleague will use twice.