Prompt engineering asked what to say to the model. Context engineering asks what the model actually needs to see, in what order, and what gets thrown away to make room for it — the discipline agents forced into existence.
For a couple of years, "prompt engineering" was the catch-all term for getting good output from an LLM: phrase the instruction well, add a few examples, maybe a system message. That framing made sense when the unit of work was a single request-response pair. It stopped making sense once the unit of work became an agent loop running for dozens of turns, pulling in retrieved documents, tool schemas, tool outputs, and its own prior reasoning — all competing for the same finite context window.
"Context engineering" is the name that stuck for the broader discipline. It isn't a rebrand of prompt engineering so much as an admission that the prompt was never the whole problem. The instruction text is one input among many now, and often the smallest one by token count. The real engineering problem is deciding what goes into the context window at all, in what order, and what gets evicted when it doesn't fit.
The shift tracks three things happening at once in 2025–2026:
Shopify's Tobi Lütke and several agent-infrastructure teams popularized "context engineering" as the better label around mid-2025, and the framing spread quickly because it gave practitioners a name for work they were already doing ad hoc — trimming tool outputs, summarizing old turns, reordering retrieved chunks — without a shared vocabulary for it.
Every agent's context window is really four distinct budgets stacked on top of each other, and they behave differently under pressure.
The fixed scaffolding: role, constraints, output format, safety rules. This is the part "prompt engineering" originally covered, and it's usually the smallest slice by token count in a mature agent — a few hundred to a couple thousand tokens that rarely change turn to turn.
Every tool the model can call needs a name, description, and parameter schema in context, every single turn, whether or not the model ends up calling it. This is the part teams most consistently underestimate. Connect a model to a dozen MCP servers with verbose tool descriptions and you can burn 10–20K tokens before the conversation even starts. It's also why tool schema design matters as much as prompt wording — a bloated schema is a context cost paid on every single call, not just the ones that use it. An agent calling something like Utilix's MCP server for a one-off checksum or encoding task is a useful contrast case: a narrow, single-purpose tool costs a small, fixed schema footprint rather than a sprawling one.
Whatever a RAG pipeline, a file read, or a search result pulls in. This is the most elastic budget and the one most directly under the engineer's control — you decide how many chunks, how big, how reranked.
Everything the agent has already said and done. In a long-running agent, this is the budget that grows without bound unless something actively compacts or summarizes it.
The failure mode in almost every under-engineered agent is treating these four budgets as one undifferentiated pile and letting whichever one grows fastest — usually history or retrieval — crowd out everything else.
Size isn't the only variable — position is the other one context engineering has to account for, and it's less intuitive. The 2023 "Lost in the Middle" research (Liu et al.) showed that retrieval-augmented models are measurably worse at using information placed in the middle of a long context than information placed near the beginning or end, even when the model's claimed context window comfortably fits everything. That pattern has held up, in varying degrees, across generations of models since — instructions and retrieved facts sandwiched deep inside a long history are more likely to get effectively ignored than ones at the edges.
That's why mature agent setups do things that look redundant on paper: repeating the critical instruction right before the final generation step even though it already appeared in the system prompt, or putting the single most relevant retrieved chunk last instead of first in a reranked list. It's not redundancy for its own sake — it's compensating for a known positional weakness rather than trusting the window size alone.
Token budgets per component, not just a global limit. Instead of "keep the whole prompt under N tokens," mature agents cap each of the four budgets independently — tool defs get at most X tokens, retrieval gets at most Y chunks, history gets compacted once it crosses Z. A single global ceiling just means whichever budget grows fastest eats the others.
Context compaction for long-running loops. Rather than keeping every tool call and result verbatim, agents periodically summarize older turns into a condensed form and drop the originals — the same pattern covered in how long-running agents avoid drowning in their own history. The summary is lossy by design; the bet is that the loss is cheaper than the context it frees up.
Truncation and pagination at the tool-output boundary, not after the fact. A tool that can return an entire file or an entire database table needs to paginate or truncate at the source, because by the time a 50,000-token tool result lands in context, the damage to the budget is already done — you can summarize it afterward, but you've already paid for it once.
Reranking before inclusion, not after. Retrieval pipelines that fetch 50 chunks and stuff all of them into context are solving the recall problem and ignoring the context-budget problem. Reranking down to the 5–8 chunks that actually matter, and ordering them with the lost-in-the-middle effect in mind, does more for output quality than fetching more chunks ever will.
Treating tool schemas as a design surface, not a given. Shortening descriptions, dropping rarely-used optional parameters, and splitting one sprawling multi-purpose tool into several narrow ones all reduce the fixed cost paid every turn — independent of whether the model calls that tool at all.
Context engineering is budget management, not a cure for the underlying model limitation. A model with weak long-context recall is still going to have weak long-context recall; better context engineering just means you're not making that problem worse than it has to be. It also doesn't replace good retrieval — if the retrieval step pulls the wrong documents, no amount of careful token budgeting rescues the answer. The discipline is about not wasting the context budget you have, not about making a fundamentally insufficient budget sufficient.
Prompt engineering asked "what should I say to the model?" Context engineering asks "what does the model actually need to see, in what order, and what am I willing to throw away to make room for it?" The second question is the one that determines whether an agent still works on turn 40 of a long task, which is exactly the point at which prompt wording stops mattering and context budget starts being the whole story.