Context Engineering refers to this: the information a model can see when it generates is limited, and you have to decide what goes into that limited budget — system instructions, tool descriptions, retrieved material, message history, intermediate conclusions from a scratchpad, or nothing at all.
Anthropic gave a fairly restrained definition in its engineering blog: context engineering is the set of strategies for curating and maintaining the optimal set of tokens during LLM inference. It treats context as a finite resource to be managed, not as something to stuff full because you can.
Grab It in One Sentence First
Context Engineering is making trade-offs inside a finite context window: what information the model gets each turn, how it's organized, and when it gets dropped.
An everyday analogy is packing a suitcase for a colleague's trip. The capacity is fixed, so what you pick isn't "everything that might come in handy" but "what this trip will actually use." Pack it too full and finding one shirt means digging through everything; leave out the charger and the whole trip stalls. Context engineering is that packing decision, except what gets packed is information.
Why This Term Emerged
Early LLM use was mostly one-shot classification and generation, so what everyone cared about was how to write the prompt. Once systems became multi-turn, got wired to retrieval, had tools attached, and were split across collaborating Agents, there was much more to manage than a single instruction: the system prompt, tool definitions, external data arriving over MCP, message history, and retrieval results all have to fit into the same window.
So the focus shifted: from finding the right words and phrases toward asking what configuration of context is most likely to produce the behavior you want. That shift is what the term Context Engineering marks. Anthropic describes it as the natural progression of prompt engineering — prompt engineering governs how instructions are written, context engineering governs how the whole token budget is spent.
flowchart TB
subgraph Window["Context window (finite)"]
Sys["System instructions"]
Tools["Tool definitions"]
Hist["Message history"]
Ret["Retrieved results"]
Mem["External memory summary"]
end
Store[("External storage<br/>files / vector DB / board")] -->|select on demand| Ret
Hist -->|compress| Mem
Mem -->|write back| Store
Window --> Model["Model generation"]What It Usually Includes
LangChain groups the common strategies into four buckets, a taxonomy that's widely used. Write means storing information outside the window — for example, having the model record intermediate conclusions in a scratchpad file, so they don't occupy the current conversation and can be fetched back when needed. Select means pulling in only the relevant parts each turn; retrieval-augmented generation is the most typical form of selection.
Compress means replacing long history with a summary, keeping decisions, conclusions, and unresolved questions while discarding verbose tool output. Isolate means splitting context up, most commonly by handing work to subagents, each with its own window, tools, and instructions, so they don't contaminate one another.
Tool design counts as part of this too. Anthropic stresses that tools themselves should be designed for token efficiency: clear non-overlapping responsibilities, well-scoped purpose, and unambiguous parameters. A common failure mode is a bloated toolset where functions overlap, every option looks defensible, and the model picks the wrong one.
The Difference from Prompt Engineering
Prompt Engineering is about how that block of instructions is written: what role to set, how to describe the task, how many examples to give, how to constrain the output format. Context Engineering is about what should be in the window at all, of which the instruction is only one piece.
A concrete difference: for the same coding task, prompt engineering agonizes over "let me state the requirement more precisely," while context engineering asks "which files should actually be read this time, does the entire test output need to be pasted in, can last turn's three thousand lines of logs be cut down to just the failing ones?" The first tunes wording; the second tunes volume and signal-to-noise ratio.
The two don't conflict, but once a task is complex enough to need multiple turns and multiple tools, the second one usually decides the outcome.
Its Relationship to Context Windows, RAG, and Compaction
The context window is the hard constraint and the reason this discipline exists; however large it gets, it's still finite, and the fuller it is, the more easily the model's attention to the middle gets diluted. RAG is the most mature approach in the "select" bucket, responsible for picking the few passages worth seeing this turn out of a large corpus. Context compaction is the concrete mechanism in the "compress" bucket, swapping history for a summary as the window fills so the session can continue.
Anthropic's multi-agent research offers corroboration: multiple Agents each holding isolated context clearly outperformed a single Agent on breadth-first research tasks, in part because each subagent's window could be allocated entirely to a narrower sub-task.
Where It's Easy to Misunderstand
The first misconception is that "a bigger window means you don't have to manage context." Going from a few thousand tokens to a few hundred thousand did relieve a lot of problems, but filling a long window is both expensive and slow, and when relevant information is buried among irrelevant material, performance drops. The finite-resource assumption didn't disappear because the window grew.
The second is treating this as purely a retrieval problem. Retrieval only answers "what to bring in from outside," but how to trim history, how many tools to expose, how long the system prompt should be, and when to spin off a sub-task are not things retrieval decides.
The third is chasing "give it everything at once." Stuffing in all possibly relevant material usually works worse than fetching in batches on demand: the former makes the model hunt for signal in noise, the latter lets it go get things with the current question in hand.
How to Decide Whether to Use It
Single-turn translation, rewriting, and classification basically don't need dedicated context engineering — a clear instruction is enough. Once any of the following appears, it deserves real attention: the conversation will run many turns, the material to read exceeds the window, more than three tools are attached, intermediate state has to persist across steps, or the same prompt visibly degrades in a long session.
A practical self-check is to look at the token composition: break down one request's tokens by source and see how much goes to the system prompt, tool definitions, history, and retrieval results. If seventy percent of the budget is going to material unrelated to the current step, that's exactly where context engineering should step in.