Context Engineering: The Discipline That Replaced Prompt Engineering

Prompt engineering was a skill with a short half-life. In the early window of generally available large language models, the leverage really was in the wording: a clever instruction, a well-chosen role, a few-shot example placed just so, and a single model call would go from useless to impressive. Job postings asked for it. Conference talks taught it. The skill was real, and for about two years it was where the marginal gains lived, because the models were inconsistent enough that phrasing moved the needle and the surrounding machinery was simple enough that phrasing was most of what there was to tune.

That window has closed, and the contrarian claim is that it closed quietly while most organizations were still hiring for it. Prompting did not become unimportant; it became commoditized. The frontier models follow instructions well enough that the difference between a competent prompt and a brilliant one has compressed to a rounding error for most production tasks, and the patterns that used to be artisanal, the role framing, the step-by-step instruction, the output-format demand, are now baked into the models, documented in the provider cookbooks, and increasingly generated by the models themselves. The real leverage moved one layer up, to the problem of deciding what information the model sees at all. That discipline has a name now, context engineering, and the evidence from teams shipping production AI shows it is where the hard problems, the cost, and the durable skill have relocated.

What Context Engineering Actually Is

Context engineering is the discipline of assembling exactly the right information into the model's context window at the right moment, under a hard budget, so that the model has what it needs to answer and nothing that distracts it from doing so. Where prompt engineering tuned the instruction, context engineering decides the payload, and the payload is assembled dynamically per request from many moving sources rather than written once by hand.

It has several distinct components, and a mature AI system is doing all of them on every request whether or not anyone has named the work. The first is retrieval: selecting, from a corpus far larger than any window, the specific passages relevant to this query, which is the problem that retrieval-augmented generation exists to solve and which the analysis of retrieval-augmented generation explained treats in depth. The second is memory: deciding what from prior turns, prior sessions, or a persistent user profile belongs in this turn's context, and in what compressed form. The third is tool-result formatting: when the model calls a tool and gets back a blob of structured data, someone has to decide how that result is shaped, truncated, and labelled before it re-enters the window, because the raw payload is frequently larger and noisier than the model can use well. The fourth is compression and summarization: collapsing long histories, long documents, and verbose tool outputs into dense representations that preserve the signal and shed the tokens. The fifth is ordering and placement: deciding where in the assembled context each piece sits, because position changes how strongly the model attends to it.

None of these is wording. All of them are engineering decisions about information, made under a constraint that prompt engineering never had to respect: every token added to the context has a cost in money and in latency, and beyond a point an added token actively degrades the answer. That constraint is what turns context assembly from a content problem into an engineering discipline with budgets, tradeoffs, and measurable failure modes.