The prompt that used to get the model behaving has stopped working, and no amount of rewording brings it back. That’s the tell that context engineering as a practice has become a discipline of its own. The failure has moved from “the model misunderstood” to “the model never saw it.” Context engineering is the discipline of deciding what enters the model’s window on every call, in what order, at what fidelity and at what cost. By the end, you’ll be able to name the four operations and their costs.
What is context engineering, and what does it actually cover beyond the prompt?
Prompt engineering optimises the wording inside a window someone else sized. Context engineering decides what fills that window, and it covers more than the prompt.
A prompt-only view misses most of what actually reaches the model: retrieved documents, tool definitions and schemas, memory, sub-agent handoffs, and the summaries compaction leaves behind. It misses the order they arrive in, too.
Order is itself a design decision, and it changes how reliably the model uses what it’s given. Models use evidence near the start or end of a long input more reliably than in the middle, a quirk of long contexts that punishes careless assembly.
The Model Context Protocol (MCP) turned this into a job. It standardises how tools and resources are described and discovered, so tool schemas moved from an integration chore into context’s job: resident in the window, billed on every call.
The consequence is that the artefact your team now ships and maintains is the context layer you own outside the model, the harness that assembles the window. The constraint that makes the discipline necessary is the context budget, denominated in tokens and dollars and divided across every surface a prompt-only view never sees.
That scope is wide enough to invite the obvious objection: isn’t this just prompt engineering with a new name?
Context engineering vs prompt engineering: is this a real shift, or a rebrand of work good teams already did?
The shift is real, though the rebrand charge deserves a hearing. Good teams curated examples and trimmed long transcripts long before the term existed, and that craft is genuine. What changed is the constraint, and it changed three times.
First, the unit of work moved from a string to a runtime. You’re no longer optimising a template you write once; you’re optimising a harness that assembles the window on every call, under a budget, while the working set changes shape. Prompt engineering gets you the first good output; context engineering keeps the thousandth output good (the craft predates the label, the discipline doesn’t).
Second, the failure modes moved. Prompt engineering fails as an ambiguous instruction. Context engineering fails as the right information missing, buried or dropped at the step that needed it. You debug by inspecting what was actually in the window rather than re-reading the prompt.
Third, the cost model moved from per-call to per-window-tier. Occupancy, rather than wording, now drives the bill, and crossing a pricing threshold reprices the whole request rather than the overflow.
The rebrand charge correctly credits the craft; it misreads the constraint. Prompt engineering is scoped to what it always optimised: instruction wording, examples and formatting. That work still matters; it just sits inside context engineering now, rather than opposite it. Inside that larger discipline, four operations do the actual work of spending the window.
What are the four operations of context engineering, and what does each one cost?
The four operations are eager load, just-in-time fetch, compact and sub-agent: four ways an item can occupy the window, each with its own cost. They stack rather than replace one another. It’s one naming scheme among several (write/select/compress/isolate covers the same ground); the costs are what matter.
Eager load. Everything in the window up front: standing instructions, the output contract, tool schemas. It buys presence from the first token. It costs tokens on every call plus attention dilution, and tool catalogues are where teams pay it without noticing. Chrome DevTools’ MCP server alone consumed roughly 18,000 tokens before the agent did anything useful.
Just-in-time fetch. Hold a lightweight reference and load the content at the moment of need, via just-in-time retrieval, from the context layer you own outside the model. It costs latency on every hop and a dependency on retrieval quality; the failure point moves to retrieval rather than reasoning.
Compact. Summarise the history to reclaim space. It costs fidelity, lost irreversibly and usually silently: the prompt survives, the rule does not. Compaction alone raises constraint violations from zero to roughly 30 per cent across model families (the loss is in the summariser rather than the model). That’s why the window you pay for is not the window you get, and what compaction throws away is its own accounting.
Sub-agent. Hand a slice of work to an isolated context window that returns a distilled summary, the orchestrator-worker pattern. It costs tokens multiplied across agents plus coordination overhead; Anthropic’s own numbers put multi-agent systems at roughly 15 times the tokens of chats. The trade is handing work to a sub-agent instead of one long transcript.
The context budget is what makes all four necessary: a budget alongside latency and memory, and these four operations are four ways of spending it.
The discipline is real because two things changed, and neither of them is the name. The artefact you maintain is now the harness, and the bill is now the context budget: a first-class engineering budget, denominated in tokens and dollars. The four operations are how you spend that budget deliberately, and they’re part of the wider shift this cluster maps.
Which article you read next depends on which operation your team runs. If you’re eager-loading everything, start with how crossing a pricing threshold reprices the whole request. If you’re fetching just in time or running sub-agents, read about the context layer you own outside the model. If you’re compacting history, read what compaction throws away and how to measure the loss.
Frequently Asked Questions
Is context engineering just prompt engineering with a bigger budget?
No. A bigger budget changes how much you can afford, not who decides what earns a place in the window. Prompt engineering still applies inside that window, but the budget forces a decision prompt craft never had to make: what gets evicted when the list grows. Teams that treat it as a spending limit usually find the real limit is attention, not tokens.
Do the four operations replace each other, or stack?
They stack. Most production harnesses run all four in a single request: a resident block of instructions and tool schemas (eager load), a retrieval hop for the document at hand (just-in-time fetch), a summary of earlier turns (compact), and a delegated subtask (sub-agent). The design question is not which one to pick, but what proportion of the budget each one gets.
Where does retrieval sit? Is it a fifth operation or part of just-in-time fetch?
Retrieval is the mechanism inside just-in-time fetch, not a separate operation. What makes it an operation is the timing: you hold a lightweight reference and pay the latency at the moment of need, rather than carrying the document from the first call. That is why retrieval quality, not model reasoning, becomes the failure point when the fetch misfires.
Is MCP a context engineering tool or an integration standard?
It is an integration standard, and that is exactly why it matters here. Before MCP, connecting a model to a tool was a bespoke build per vendor. Now tool and resource definitions arrive in a predictable shape, so the question shifts to which definitions stay resident in the window and what they cost. The protocol standardises access; your harness still owns the assembly.
Does prompt engineering stop mattering once you adopt context engineering?
No, it moves inward. Wording, examples and formatting still decide whether the model uses what it is given, but they now operate on a smaller share of the outcome. A perfectly worded instruction cannot rescue a window where the relevant evidence was evicted by compaction or arrived after the model had already answered.
How do I tell which operation my team is already running by default?
Read the code that builds the request, not the prompt file. If the whole tool catalogue and every policy document ship on every call, you are eager loading. If a retrieval step runs mid-conversation, that is just-in-time fetch. If a summariser rewrites history, you are compacting. If an orchestrator spawns workers, you are running sub-agents.
What happens if we just buy a bigger context window instead?
You move the problem, you do not remove it. A larger window raises the ceiling on what you can carry, but the usable portion is smaller than the advertised number, and evidence buried in the middle of a long input gets used less reliably. Occupancy still bills, so the cost per call climbs with every document you leave resident.
Is context engineering only relevant if we are building agents?
No. A single-turn retrieval pipeline, a support bot with a knowledge base or a coding assistant with a tool catalogue all face the same decision about what enters the window. Agents make the problem visible because a run spans many calls, but any system that assembles more than one document into a request is already doing this work, deliberately or not.
How do we measure whether our context assembly is actually working?
Measure failure modes, not vibes. Track how often the model answers without the evidence it needed (a retrieval or eviction failure), how often it ignores a rule that was summarised away (a compaction loss), and what share of tokens per call is standing overhead rather than task content. Those three numbers move before quality scores do.
Why are tool schemas such an expensive part of the window?
Because they are always resident and always billed. Every tool you expose adds its definition to every call, whether or not the model uses it, and a large catalogue also dilutes attention across options the task never needed. Curating the exposed set, rather than exposing everything the platform supports, is one of the cheapest wins in the budget.
How do I stop compaction from quietly dropping rules the model needs?
Lift them out of history and keep them resident. Anything that must survive compaction, such as output contracts, escalation limits and tone constraints, belongs in the standing block rather than in the conversation being summarised. Then compaction only rewrites narrative, which degrades gracefully. If a rule lives only in a turn from forty messages ago, assume it is already gone.
Who should own context engineering on a team?
Whoever owns the harness, not a prompt library. In practice this lands with the platform or application engineers who assemble the request, because the decisions involve retrieval, latency budgets and token spend rather than copywriting. Product and domain experts still supply the rules and the evidence; they just stop being the ones deciding what fits.
