Article
For a while, the skill in building with language models was thought to be phrasing: the magic words that made a model behave. That phase is over. Models are better at following plain instructions, and the thing that now separates a reliable AI feature from an unreliable one is what the model is given to work with. Not how you ask, but what it can see when you ask. The industry calls this context engineering, and it is mostly ordinary engineering applied to a new constraint.
The constraint
A model has a finite window of attention, and everything in it competes. Put too little in and the model guesses. Put too much in and it loses the important part among the rest, or costs ten times what it should. Every request is a budgeting decision: of everything we could show the model, which parts, in what order, at what length?
Four decisions that make up context engineering
What to retrieve. Not "the five most similar chunks", which is where most systems stop, but the right documents, filtered by what is current, what the user is allowed to see, and what the question is about. Retrieval quality is measured, like everything else, with a test set.
What to summarise. A long conversation, a long document, or a long tool result does not need to be in the window verbatim. A running summary of a conversation, refreshed every few turns, keeps the thread without the transcript. A tool that returns two thousand rows should return a summary and a way to ask for more.
What to exclude. The most important decision and the least discussed. Fields the model should never see are removed before the prompt is built. Instructions embedded in retrieved documents are stripped or fenced. A model cannot leak what it was never shown, and cannot follow an instruction it never received.
What to put first and last. Models attend more to the beginning and end of the window. The task and the constraints go first; the most relevant evidence goes last, nearest the question. The middle is for supporting material, and if something must not be forgotten, it does not belong in the middle.
For agents, it is the whole job
An agent's context is rebuilt on every step: the goal, the plan so far, the last tool result, and whatever memory the harness chose to keep. Deciding what survives from step to step is what makes an agent coherent over a long task. This is why we say the harness, not the model, is the product: the harness is where context engineering lives.
Practical rules we use
Measure tokens per request and treat the number like a page-weight budget. Keep prompts in version control with the same review as code. Never let a prompt contain data it does not need. And when a feature is unreliable, look at what the model saw on the failing cases before touching a single word of the instructions. Nine times out of ten the wording was fine and the context was wrong.
This is the work inside every AI feature we build, and it is most of what an agent engagement consists of once the prototype exists.