Ecosystem & Emerging Terms

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.

Prompt EngineeringContext Engineering
Context engineering widens the job from wording one prompt to curating everything in the context window.

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

Often assumed: Context engineering is just a rebrand of prompt engineering.
Actually: Prompt engineering is about the wording of an instruction; context engineering covers the full set of inputs a model sees for a step — tools, retrieved content, history, memory — and how that set changes over a long session.
Often assumed: More context always makes an agent perform better.
Actually: Irrelevant or stale context can crowd out what actually matters and increase cost per step; well-curated, relevant context typically outperforms simply including everything available.

FAQ

What is context engineering vs prompt engineering?
Prompt engineering focuses on writing a single good instruction; context engineering is the broader practice of managing everything in the model's context window across a multi-step agent session — tools, retrieved data, history, and memory.
Is context engineering an official Anthropic term?
No single organization owns the term — it's a practitioner label that's become common for describing how agent context is curated, not a formally standardized discipline.
Why does context engineering matter more for agents than for chatbots?
An agent's context accumulates over many steps, so decisions about what to keep, summarize, or drop directly affect its cost and behavior in a way a single chatbot reply never has to deal with.

Last checked: 2026-08-28

Related terms