Context Engineering Is Not Prompt Tuning
Prompt engineering focuses on the question. Context engineering focuses on the world you hand the model before the question. That distinction changes how you design reliable LLM systems.
Prompt engineering has a reputation problem. The phrase sounds like something between marketing and guesswork: type the right words, get the right output, and keep iterating until the result improves. That reputation isn’t entirely unfair, but it has buried something more useful, which is that context, not prompt wording, is the real lever when you’re building with language models.
A prompt is a question. Context is the world around it.
The prompt is what you ask. The context is everything you hand the model before the question. Most of the variables that decide whether a model behaves well or badly aren’t in the prompt at all. They’re in the context: what information you include, what you leave out, how it’s structured, what role the model has been given, what constraints are in place, what examples you’ve shown it.
Change the wording of the question and you get different phrasing. Change the context and you get different reasoning. That distinction matters a lot once you’re building systems instead of writing one-off queries.
Context is a software boundary
In a well-designed application, context isn’t an afterthought. It’s a deliberate system boundary. Just as a function has a signature that defines what it accepts and returns, the context window has a shape that defines what the model is working with. Get that shape wrong and you get incorrect or unhelpful output. Get it right and the model starts to feel reliable.
This is what AI Tools Are Not Magic Bullets describes at the system level: the LLM is one step in a pipeline, responsible for a narrow transformation, and context engineering is what makes that step reliable. Without intentional context design the transformation is unpredictable, and no amount of prompt rewording will fix it.
Context design comes down to decisions about:
- what data the model needs access to, and how much
- how that data is formatted and ordered
- what instructions constrain the model’s behaviour
- what examples anchor the expected output format
- what information is explicitly excluded and why
Those decisions should be made deliberately and then tested, not adjusted by feel.
Too much is as bad as too little
A context window with everything available in it isn’t a rich context, it’s a noisy one. Models don’t automatically prioritise the most relevant information. They weight what’s recent, prominent, and repeated, so burying the important thing under thousands of tokens of background guarantees it competes with everything else for attention.
At the other extreme, a model asked to classify a customer message without knowing what the product does, what the categories are, or what a typical message looks like will produce something technically valid and practically useless. Both failure modes come from the same mistake: not knowing what the model actually needs.
What you’re after is the minimum sufficient information to reliably produce the right output. A classifier that gets a customer message, the product category, and three examples of past decisions will beat one that gets the full customer history and a 500-word system prompt. That takes discipline, because it means understanding what the model needs to do the job, which means understanding the job.
The failures are usually structural, not lexical
When a model produces wrong output, the instinct is to change the prompt. Reword the instruction, add emphasis, rephrase the question. That sometimes works, but more often the problem is structural. The context didn’t include the information the model needed. The format was ambiguous, so the model fell back on a pattern from its training data. The instructions contradicted each other. The examples showed something different from what the instructions described.
None of that gets fixed by changing the phrasing of the question. It gets fixed by changing the context. That’s the practitioner-level shift: from “what words should I use” to “what does this context reliably produce, and why.”
Context design is a system concern
In a production application, the context is assembled programmatically. A request comes in, the system retrieves relevant data, builds the context window, calls the model, and processes the output. Every one of those steps is an engineering decision. Which data gets retrieved? How is it formatted? How do you decide what’s relevant? What happens when retrieval returns nothing? How do you truncate the context if it overflows the window? What gets logged and monitored?
Those aren’t prompt questions, they’re system design questions. The teams that get the most out of language models treat context assembly as a first-class engineering concern: they write tests for context construction, they monitor what goes into the window, and they have code for the edge cases. The teams that struggle treat context as whatever happened to be in the request, and pour their energy into rephrasing the system prompt instead.
The model is not the product
A model is a component. The context pipeline is the interface. The output handling is the rest of the system. Getting the model right isn’t enough on its own. The context has to be well-constructed, consistent, and testable, and the output has to be validated, logged, and handled gracefully when it’s wrong. None of that happens on its own just because the model is capable. It happens because someone treated context design as engineering.
The quality of the output is mostly decided before the model ever sees the question. So the question worth spending your time on isn’t how to word the prompt. It’s what the context actually contains.