Context engineering
Controlling what the model can see when it answers often matters more than how you phrase the question.
What the model can see, not just what you say
Context engineering is the practice of controlling what information is loaded into the model's context window before it answers. It is not about phrasing your request more cleverly, that is prompt engineering. It is about making sure the model has the actual, relevant material in front of it: the right file, the right document, the right prior decision, at the moment it needs to reason about your request.
This matters because a model cannot use information it never received. It does not know your codebase, your company's policies, or yesterday's decisions unless those things are somewhere in the current context window. A beautifully worded prompt aimed at a model working blind still produces a guess, not an answer.
In practice, context engineering often outperforms prompt engineering. Rewriting a request five different ways rarely helps if the underlying problem is that the model never saw the one document that contained the answer. Loading that document once tends to fix the output immediately, no matter how the question is phrased.
Select a numbered hotspot to see what occupies that part of the diagram.
Same request, same phrasing, two outcomes. The only thing that changes is what is in the context window when the model answers.
Step 1: The request, without the right context
A support team asks an AI assistant: "Can we offer this customer a refund outside the normal 30-day window?" With no company policy loaded, the model has nothing to reason from except general norms. It gives a generic, hedged answer: "This depends on your company's policy, you may want to check with a manager." The request was clear. The model was not incapable. It simply had no source of truth about this company's actual refund rules, so it could not do better than a guess dressed up as caution.
Step 2: Add the actual policy document
The team attaches the current refund policy document to the conversation before asking again. The document states exceptions are allowed within 45 days for defective items, with manager sign-off logged in the ticket. What changed: the policy text is now inside the context window alongside the question. What improved: the model can quote the actual exception clause, state the 45-day defective-item allowance, and note the sign-off requirement, a specific, checkable answer instead of a hedge.
Step 3: Notice the fix was not the prompt
The question was worded identically in both steps. Nothing about phrasing, examples, or format changed between the generic answer and the specific one. The only variable was whether the refund policy existed inside the context window at the moment the model answered. This is the signature of a context problem: the same prompt produces a bad answer without the source material and a good answer with it. When you see that pattern, adding the right document fixes it faster than any amount of prompt rewriting.
Question 1 of 4
What does context engineering control?