Context engineering
More context isn't automatically better context. The actual skill is curating what a model sees — and it's a genuinely different discipline from writing a good prompt.
Curating, not maximizing
The instinct once someone learns a model has a large context window is to paste in everything that might be relevant — the whole document, every past conversation, every possible constraint. That instinct is backwards. A model working from a pile of mostly-irrelevant information has to guess which parts matter, and it guesses wrong often enough that the extra material actively hurts more than it helps. Context engineering is the skill of deciding, deliberately, what belongs in that limited space and what gets left out — closer to editing than to filling a container to the brim.
What context actually is, practically
Everything the model has to work with at the moment it generates a response — the instruction itself, background information, prior conversation, examples, and any constraints — all competing for a limited amount of attention. Too little of it and the model is guessing at what you actually meant. Too much, especially irrelevant material, and the genuinely important details get buried in noise it has to sift through.
The four things worth deliberately including
Constraints
What the answer must respect — length, format, audience, things explicitly off-limits.
Examples
One well-chosen example does more than a paragraph describing what you want in the abstract.
Memory
What's already been established in this conversation that shouldn't need repeating.
Relevant information
The specific facts this particular task actually needs — not everything you happen to know.
A practical layering technique
Structure context in a consistent order: background first (what's this about), then the actual task (what's needed right now), then constraints (what it has to respect), then an example if one exists. That order isn't arbitrary — background frames how everything after it gets interpreted, so it belongs first, and constraints belong close to the task itself rather than buried somewhere else entirely.
Where context engineering goes wrong
How this differs from prompt engineering
A prompt is the specific instruction — what you're asking for, right now. Context is everything surrounding that instruction the model also has to work with. The two overlap constantly in practice, but they're different skills: prompt engineering is about phrasing the ask well; context engineering is about curating what else the model sees while it works on that ask. A perfectly phrased prompt sitting on top of irrelevant or missing context still produces a mediocre result — the two need to be right together.
The short version
Treat context as a curated, limited resource, not a bucket to fill. Include constraints, one good example, relevant background, and nothing else — deliberately, in a consistent order — rather than pasting in everything that might conceivably matter and hoping the model sorts it out. That discipline, more than any specific phrasing trick, is what separates a genuinely well-directed request from a merely well-worded one. For the instruction-phrasing half of this pairing, see Prompt Engineering.