Context Engineering
Also called: context management
Context engineering is the practice of deciding what information — instructions, tools, retrieved documents, history, memory — actually goes into a model's context window for a given step, and how it's structured and kept up to date.
For a single chat reply, getting a good result is mostly about wording: phrase the question well and the model answers well. That's react-prompting's sibling concern, prompt engineering — crafting the instruction text itself. Context engineering is a broader job that emerged as people started building agents that run for many steps: instead of just writing one good prompt, someone has to decide everything else the model sees at each step — the system instructions, which tools are exposed, which documents got retrieved, how much conversation history survives, what's pulled in from memory, and which file contents are attached.
The term is an increasingly common way practitioners describe this work as of 2026, not an established discipline with a fixed method — different teams draw the boundary between 'prompt' and 'context' slightly differently, and there's no single body that defines it. What most usages agree on is the core shift: a prompt is text you write once for a turn; context is the full assembled input a model sees, most of which an agent's harness constructs and updates automatically as the session goes on.
This matters specifically for agents, as opposed to one-shot chat, because context accumulates. A coding agent that has been running for dozens of turns has read files, run commands, and received tool outputs — all of which can pile into the context window. What a harness or developer chooses to keep verbatim, summarize, or drop directly shapes both the cost of each step (more context, more tokens billed) and the agent's actual behavior: stale or irrelevant context can distract the model or cause it to act on outdated information, while too little context can cause it to repeat work or lose track of a constraint stated earlier.
How it works
In practice, context engineering covers a handful of recurring decisions: what belongs in the system prompt versus what's fetched just-in-time; which tools are exposed at all (a shorter tool-manifest is often easier for a model to use well than an exhaustive one); how retrieved documents or file contents are filtered down to what's relevant instead of dumped wholesale; when older conversation turns get summarized or truncated to control context size; and what's written to and read back from agent-memory across sessions. None of this is a single fixed technique — it's closer to an ongoing engineering discipline that a coding-agent-harness or an individual skill definition has to get right, and it typically changes as an agent session gets longer.
Example
Consider a coding agent partway through a multi-hour refactor. Its context window could contain: the original task description, a summary of decisions made twenty turns ago (rather than the full transcript), the current contents of the three files being edited, the last test-run output, and a short list of available tools. A context-engineering decision might be to drop the full test output after a run succeeds, keeping only a one-line summary, to leave more room for the next file the agent needs to read.
How it differs
Context engineering is often confused with agent-memory, but they solve different problems. Agent memory is the storage — often external and persistent — that holds information across steps or sessions (a database, a file, a vector store). Context engineering is the ongoing decision of what to pull from that memory, and everything else, into the model's context window right now. Memory is where information lives between uses; context engineering decides what actually makes it into a given step.
Common misconceptions
FAQ
What is context engineering vs prompt engineering?
Is context engineering an official Anthropic term?
Why does context engineering matter more for agents than for chatbots?
Last checked: 2026-08-28