Context engineering is the practice of giving a model the right knowledge before you ask it anything, and it is the skill that decides whether AI returns junk or returns exactly what you intended. The model is rarely the problem. The context you fed it usually is. I watched a room of professionals prove this to themselves in ninety seconds, and I want to walk through what happened and the framework I gave them.
Last Saturday I taught the third session of a five-part AI and design series to a room of working professionals and early-career designers. The theme was context as fuel. I did not want them to hear the lesson. I wanted them to feel it. There is a difference between a leader nodding along to a slide about context and a leader watching their own screen produce garbage, then watching it produce gold, with nothing changed but the words they typed first. The second one sticks.
So I ran an exercise. I asked everyone to open whatever AI tool they use and type three words: "Recommend a gift." Most of the room got back follow-up questions or generic suggestions. A coffee mug. A gift card. The kind of answer you would expect from someone who knows nothing about you.
Then I handed them a second prompt. This one spelled out the recipient, the occasion, the person's interests, a budget, and the constraints. Same tool. Same person typing. The only thing that changed was the knowledge they handed the model before asking.
Roughly nine out of ten people in that room got a sharp, specific recommendation with zero follow-up questions. One variable moved. The output transformed.
That is the entire point I have been trying to make to executives for two years. The quality of what AI gives you is directly proportional to the quality of the context you give it. Prompt engineering is asking the right question. Context engineering is supplying the right knowledge so the machine can produce what you actually meant. One is an evolution of the other, not a synonym for it.
Here is why this matters now and not last year. The models stopped being the bottleneck. When every serious model can write, summarise, and reason at a high level, the gap between a useless answer and a precise one is no longer the model's capability. It is the context surrounding the request. The people who win with AI in 2026 are not the ones with access to a better model. Everyone has the same models. The winners are the ones who have learned to feed those models well.
I see this play out in boardrooms more than in classrooms. A senior leader runs a prompt, gets a bland answer, and concludes the AI is overhyped. What actually happened is that they gave the model a one-line brief with no audience, no goal, and no constraints, and the model returned the average of everything it had ever read on the subject. The average is always bland. They set the model up to fail, then blamed it for failing. I have stopped letting that conclusion stand unchallenged. The model answered the question it was given. The question carried no context, so the answer carried no edge.
This reframes what the skill actually is. For two years the industry sold prompt engineering as the differentiator, and people collected clever prompt templates the way they once collected keyboard shortcuts. Useful, but shallow. The deeper skill was always sitting underneath it. A perfect prompt on top of empty context still produces a generic answer. Rich context with an average prompt produces a useful one. If I had to choose where a team should spend its next month of learning, I would not send them to a prompt library. I would send them to map the context their systems hold and the context their systems ignore.
I gave the room a framework so this would be repeatable, not a one-time party trick. I call it SCOPE. Five inputs that decide whether a system understands a person or guesses at them.
S - Situation Where the user is right now. Time, place, mood, moment.
C - Constraints Legal and ethical limits. What data you may and may not use.
O - Objective What the product is genuinely trying to do for the person.
P - Preferences Stated and inferred, held loosely, never assumed permanent.
E - Evolution People change. A system that freezes one data point ages badly.Situation is the live state of the person. It is raining outside, it is late at night, they are between meetings. A system that ignores the moment gives technically correct answers that feel tone deaf.
Constraints are the limits on what you are allowed to know and use. DPDP in India, GDPR in Europe, CCPA in California. Constraints are not a legal footnote you add at the end. They are an input to the design from the first line.
Objective is the honest answer to what the product is for. Not what the roadmap says. What the person in front of it is actually trying to get done. Most teams optimise for engagement and call it the objective. The user's real objective is usually finishing a task and leaving.
Preferences are the trap. You can collect them, but you must hold them loosely. Someone who orders vegetarian food fifteen times is not necessarily a vegetarian. They might be on a diet, cooking for a guest, or simply curious. Treating one repeated signal as a fixed identity is how personalization starts to feel wrong.
Evolution is the input most systems forget. People are not static. Someone two years into their career does not want roles built for someone with twenty years of experience, yet plenty of platforms keep pushing exactly that because they treated an old data point as a permanent fact. Context has a shelf life. Good systems let it expire.
The reason SCOPE works as a teaching tool is that each letter maps to a question a designer can actually answer in a sentence. What is happening for this person right now. What am I allowed to use. What are they really here to do. What do I think I know about them, and how sure am I. What about all of this will be different in six months. Answer those five honestly for a single feature and you will find the gaps that make it feel robotic. Skip them and you will keep tuning prompts on top of a foundation that was never laid.
There is a line running through all of this, and the room felt it the moment I named it. Personalization is a paradox. People want to be treated like a regular at their favourite restaurant, the place where the staff knows their order before they sit down. And the same people recoil the instant they feel watched. Helpful and creepy are separated by a very thin line.
I used the 2012 Target story to make it land. A retailer's models predicted a teenager was pregnant from her shopping pattern and started sending baby-product offers before her own family knew. The math was right. The context handling was a violation. Helpful and creepy were one design decision apart, and the company landed on the wrong side of it.
That is the responsibility context engineering carries. As you give a system more knowledge about a person, you also own which side of that line the experience lands on. The skill is not just supplying context. It is supplying the right context, with the right limits, that expires at the right time.
The day after that session I taught the next one in the series, on how systems nudge behaviour, and the two lessons turned out to be the same lesson wearing different clothes. Context decides what a system knows about you. Nudges decide what it does with that knowledge. A system that knows you well can serve you well or manipulate you well, and the difference is intent. I asked that room to count their unread notifications. The range ran from two to more than thirty. Then I asked how many of those felt useful. The honest answer was around one in five. Every irrelevant notification is a context failure dressed up as engagement. The system knew enough to interrupt you and not enough to know whether it should.
This is why I keep pulling the conversation back to context before anyone reaches for a model upgrade. The companies getting AI wrong are not short on compute. They are short on the discipline of knowing their user, holding that knowledge responsibly, and letting it change. That discipline does not come from a vendor. It comes from the team that designs the experience deciding, on purpose, what their system is allowed to know and what it owes the person it knows it about.
Three things to do this week.
- Run the gift test on your own team. Ask five people to give an AI tool a vague request, then the same request with full context. Watch the output change. Nothing teaches the lesson faster than seeing it happen on your own screen.
- Write the SCOPE inputs for one product you own. Pick a single feature and write one honest line for each: Situation, Constraints, Objective, Preferences, Evolution. The gaps you find are the reasons that feature feels generic.
- Find one piece of context your system treats as permanent. A preference, a role, a label set once and never revisited. Decide what should make it expire. That single fix is usually the difference between a system that knows a person and one that nags them.
While you are here, the back catalogue has more on the human side of working with AI: