Four kinds of work sit behind any agent, and each has a name that sounds harder than the thing it describes: prompt, context, loop and harness engineering. This note is about context engineering. The other three have notes of their own, and they can be read in any order.
Picture sending a friend to the shop for you. How you word the request is prompt engineering. What you send with them — the list, the money, a photo of the empty fridge — is context engineering. What they do when the shop has no milk is loop engineering. The bag, the bus fare and the rule about how much they may spend is harness engineering.
So: everything you send along with the words. Your friend needs the list, the money and, ideally, that photo of the fridge so they can see what is already there. Choosing those things, and leaving the rest of the kitchen at home, is the whole job.
In short
- What
- Choosing what the model can see for this particular job, how it is arranged, and what is deliberately left out.
- Why
- An answer can only be as good as what it was given. Leave a detail out and it is wrong; pile everything in and it goes vague.
- When
- As soon as the answer depends on something the model cannot know by itself — your data, your rules, or what happened five minutes ago.
- How
- Start from the question and work backwards. For each thing you are about to include, ask what would break if you left it out. If nothing would, leave it out.
What the model can see
A model answers from what is in front of it at that moment: your instruction, anything you pasted in, anything a search pulled up, the conversation so far, and whatever tools have reported back. That is the whole world. Everything else — your files, your database, last week’s decision, the thing everyone on the team knows — may as well not exist.
It helps to think of a very well-read new colleague on their first morning. Enormous general knowledge, genuinely useful, and absolutely no idea where anything is kept or how you do things here. They are not going to guess your house rules. Someone has to hand them over.
Context engineering is that handing over, done on purpose rather than by accident.
Why more is not better
The obvious move is to send everything, just in case. It feels like the safe choice. It is not.
You would not hand a friend your entire kitchen to go and buy milk. You would hand them the list. Past a certain point, extra material does not add certainty — it buries the one line that mattered somewhere in the middle of a hundred lines that did not. Attention is finite, for people and for models, and the middle of a long pile is where things go to be overlooked.
There is a second problem. The more you send, the more likely it is that two parts of it disagree — an old policy and a new one, a draft and a final. Now the model has to pick, and it will, silently, without telling you there was a conflict at all.
And there is a plain practical cost: everything you send has to be read every time. More context means slower, more expensive answers, so paying for material that changes nothing is simply waste.
When you reach for it
The moment the right answer depends on something the model has no way to know. Your data. Your rules. The state of things right now rather than in general.
The clearest signal is an answer that is sensible in the abstract and wrong for you. Generic advice where you needed a specific fact, a confident description of how something usually works when your version works differently, a summary that misses the one detail that would have changed the decision. That is almost never a wording problem. The words were fine; the bag was empty.
It is also where you go when the answers are erratic rather than uniformly bad — right on Monday, wrong on Tuesday, on the same kind of question. Usually something is being included some of the time and not others.
How to choose what goes in
Start from the question and work backwards. What would a careful person need in front of them to answer this well? That list is your context. Not everything adjacent to the topic — the things the answer actually turns on.
Then go through it once more and, for each piece, ask what would go wrong if it were not there. If the honest answer is nothing, take it out. This one habit does more for quality than almost anything else.
Put the most important material at the beginning and the instruction at the end, so the job is the last thing read before the answer starts. Say where each piece came from — “from the owner’s message”, “from our policy page” — because a model that knows a source is a rule treats it differently from a source that is a suggestion.
For anything long-running, keep a short running summary rather than the entire history. Old turns are the easiest thing to let pile up and the least likely to matter. Prune as you go, the way you would clear a worktop between steps.
Where it stops
Perfect context with a sloppy instruction is still a poor answer — that is prompt engineering. Perfect context answered once, with nothing checking the result, is a single guess that happens to be well informed; that is loop engineering. And if the material has to be fetched rather than handed over, something has to be allowed to go and fetch it, which is harness engineering.
Context decides how good an answer can be. It does not decide whether anyone checks it.
