The model is not the product
What context engineering actually is, why "prompt engineering" was the wrong name, and why the discipline counts for more as models get better, not less.
When I tell people my job title is context engineer, they usually hear "prompt writer" and picture someone typing please be accurate into a text box with increasing desperation. It's a fair guess and it's wrong, and the difference between the guess and the job is most of what I want to explain here.
Start with an uncomfortable fact about the current AI landscape: the models are converging. Every serious lab now ships a frontier model that can reason, write, code and analyse at a level that would have been science fiction five years ago, and the gap between the best and the rest keeps narrowing. If you're building a product on top of these models, the model itself is increasingly a commodity. You can swap one for another in an afternoon. What you cannot swap in an afternoon, what actually determines whether your system is brilliant or dangerous, is everything you've built around the model. That everything has a name now. It's context.
Here is the mental model that makes the whole discipline legible. A large language model has no memory, no persistence, no awareness of anything outside the tokens in front of it. Every single time it runs, it wakes up with no idea who it is, what it's doing, or what happened thirty seconds ago. It is the most capable amnesiac ever hired. Context engineering is the discipline of writing the note it wakes up to.
That note is not just "the prompt". It's the system instructions that define what the system is and what it must never do. It's the retrieved knowledge: the documents, records and facts pulled in for this specific task. It's the tools it can use and the descriptions that teach it when to use them. It's the conversation so far, the state of the task, the memory of previous sessions, the output format it must produce. All of it, assembled fresh, every single time the model runs. The model's entire universe is that assembled bundle of text. It cannot know anything you didn't put there, and it will absolutely be influenced by everything you did, including the things you put there by accident.
Once you see it this way, the job stops looking like copywriting and starts looking like what it is: information architecture under a hard budget.
The budget part is a bigger deal than people expect. Context windows are large now, and getting larger, and there's a persistent fantasy that this makes the problem go away: just shove everything in. It doesn't work, for a reason that will feel familiar to anyone who's ever crammed for an exam. Attention is finite. A model given forty documents does not read forty documents the way a diligent clerk would; it attends unevenly, privileges the beginning and the end, loses things in the middle, and gets measurably worse at the task it was supposed to do. Irrelevant context isn't neutral. It actively degrades performance, the way a consultation goes worse when the patient brings a shoebox of unrelated paperwork and insists you read all of it. Every token spent on the wrong thing is attention the model cannot spend on the right one.
So the craft, in practice, is a set of questions asked over and over. What does the model need to know to do this step? In what form should it know it? When should it learn it, up front or on demand? And, just as important, what must it never see, because it will be distracted, misled or contaminated by it?
Get those wrong and you meet the failure modes, which I've come to think of as a small bestiary.
Starvation is the obvious one: the model doesn't have the information it needs, so it does what language models do, which is produce the most plausible continuation anyway. It guesses, fluently. Ask a model "should I worry about this headache" with no history, no medications, no timeline, and you'll get something generic and confident, because generic and confident is what the training distribution rewards. The fix isn't a smarter model. It's the missing context.
Flooding is starvation's mirror: the retrieval system dumps everything vaguely related into the window, and the one fact you need drowns in two hundred you don't. Flooded systems fail in a particularly nasty way, because they fail intermittently. The needle is in there. Sometimes the model finds it. You cannot ship "sometimes".
Poisoning is the subtle one: something in the context is wrong, stale or misleading, and the model treats it as ground truth, because as far as the model is concerned, the context is the truth. An outdated record, a mislabelled document, a previous model output that contained an error: all of it gets metabolised with total confidence. Garbage in, gospel out.
Conflict is the one nobody budgets for: the system instructions say one thing, a retrieved document implies another, a tool result contradicts both, and the model has to arbitrate silently between masters you didn't realise were fighting. The behaviour you get is whichever master won that day.
None of these are model failures in any interesting sense. They're context failures, which means they're design failures, which means they're fixable, and this is the part of the job I actually love. Because the thing that separates context engineering from prompt folklore is that you can measure it. Change the context, run the evaluations, watch the behaviour move. Form a hypothesis about why the system missed something, test it, fix it, and add a regression test so it can never silently come back. It's engineering in the plain sense: a feedback loop between design and evidence. Without the measurement, everything I've described collapses back into vibes, and vibes are how you end up with a demo that works and a product that doesn't.
I should say why the stakes shape my particular corner of this. In a consumer chatbot, a context failure produces an annoying answer. In medicine, the gap between "the system knows this person's actual medication list" and "the system is pattern-matching on what people like this usually take" is not an annoyance. It is the entire difference between a safe system and a plausible one, and plausible is a category of dangerous that deserves its own essay. The discipline is the same everywhere; medicine just refuses to let you be sloppy about it, which is one of the reasons I find the work satisfying. There's nowhere to hide.
The obvious objection to all of this is that it's temporary. Models get smarter every year; surely at some point they're smart enough that the scaffolding stops mattering. I think this gets it exactly backwards. A more capable model raises the ceiling of what the system can do. Context determines where under that ceiling you actually operate. As the ceiling rises, the cost of operating at ten per cent of it grows, not shrinks, and the systems that get trusted with real decisions will be the ones where someone did the unglamorous work of controlling what the model knows, when it knows it, and what it's allowed to do about it. Capability is what the labs sell. Reliability is what you build.
The model is the engine, and the engines are getting magnificent. But nobody ships an engine. They ship a car, and the difference between an engine and a car is everything I do all day.
Prefer the full experience? Read this essay in the house. Machine-readable: markdown source.