What is context engineering, and how is it different from prompt engineering?

The shortest distinction

Prompt engineering is the act of writing the instruction that frames a task. Context engineering is the broader act of deciding what the model sees across an entire run: the system prompt, the retrieved documents, the prior turns, the tools, the memory, the runtime state, and the way the model output is fed back into the next step.

When a workflow is a single question with a single answer, prompt engineering is enough. When the workflow is a multi-step agent, a coding task across a repository, a long-running assistant, or a system that has to read a knowledge base before it can answer, the prompt alone is the smallest piece of the design.

What context engineering actually changes

The Anthropic engineering blog that helped popularize the term divides the work into four moves: writing the system prompt that frames the agent, choosing the tools the agent can call, deciding what to retrieve and when, and managing the long-running context that the agent builds across a session. The model prompt is one of those four moves; the other three are unique to context engineering.

Practically, that means the work shifts from crafting a clever instruction to designing a pipeline. Which snippets of the codebase does the agent see? Which retrieved documents make it into the context window before the answer? Which tool definitions get loaded and which stay out? Which prior turns are summarized and which are kept verbatim? These are pipeline questions, not prompt questions.

• System prompt: the framing that does not change across a run.
• Tools: the actions the agent can take, the schemas it sees, and the description that helps it pick the right one.
• Retrieval: the documents the system pulls in to ground the model in the current task.
• Memory and state: the summary, the scratchpad, and the persistent facts that survive across turns or sessions.

When the distinction matters in practice

A simple chat assistant often does not need context engineering. The prompt is the system, the user message is the input, and the model reply is the output. Adding retrieval, memory, or a tool list without a clear reason will usually make the chat assistant less reliable, not more.

A coding agent does. The agent needs the right slice of the codebase, the right tool definitions, the right test results, the right prior-turn summary, and the ability to interrupt itself when the context window fills up. Tuning the prompt is a small fraction of the work; tuning the context is the work.

• Single-turn chat: prompt engineering is usually enough.
• Retrieval-augmented question-answering: prompt engineering writes the framing; context engineering writes the retrieval pipeline.
• Multi-step coding agent: context engineering is the work; prompt engineering is the small piece at the top.
• Long-running personal assistant: context engineering covers memory, compaction, and session continuity.

The techniques that earn the name

Most of the techniques that practitioners are calling context engineering today fall into a few buckets. Retrieval writes the documents the model sees. Tool selection writes the actions the model can take. Memory writes the durable facts the model can recall. Compaction writes the summary of a long turn history so the model can keep working when the context window is full. Prompt caching writes the parts of the prompt that the model should not have to re-read on every token.

The mistakes that fail are well-known: stuffing the context window with low-value documents, loading every tool the agent could ever need, summarizing the recent turns too aggressively, and forgetting that the model cannot read what is not in its context. The same prompt that works on a single-turn chat will fail when the model is given a tool list, a retrieval result, and a five-turn conversation history, because the prompt is now competing for attention with everything else.

Risks worth budgeting for

Context engineering is not free. Every retrieved document, every tool definition, and every prior turn is a token that the model has to read and a chance for the model to get distracted. The risks are practical: the agent picks the wrong tool because the list is too long, the agent hallucinates a fact because the retrieved document is stale, the agent loses the thread of a long task because the compaction summarized too aggressively.

A useful mental model is that the context window is a budget, not a buffer. The discipline is to spend it on the things that actually move the answer, not on the things that are easy to load. Treat retrieval like a ranking problem, treat tool selection like a UX problem, and treat memory like a logging problem. The prompt is still the framing, but the context is the work.

A useful next action

Pick one workflow where the model prompt is not the limiting factor. Add retrieval, add a tool, or add a memory step, and measure whether the answer got more reliable, not just longer. If the workflow is a single-turn chat, invest in prompt engineering. If the workflow is a multi-step agent, invest in context engineering first, and treat prompt engineering as the small finishing move on top.