Context Engineering vs Prompt Engineering: What's the Difference?

Prompt engineering is crafting the instructions you give a model: what to do, in what format, with which examples. Context engineering is managing everything the model sees on each call: the instructions plus tool definitions, retrieved documents, conversation history, memory and the results of earlier tool calls. Prompt engineering is one part of context engineering. For a single question to a chatbot the prompt is most of the context; for an AI agent running fifty steps, the prompt is a small and fixed part of a context that changes every turn.

Side-by-side comparison

What prompt engineering covers

Anthropic's prompting best practices is a good map of the discipline. Its core techniques are:

• Be clear and direct: the docs suggest treating the model like "a brilliant but new employee who lacks context on your norms and workflows."
• Add context to improve performance: explain why a rule exists, not just the rule.
• Use examples effectively: a few well-chosen demonstrations.
• Structure prompts with XML tags: separate instructions, documents and examples.
• Give the model a role: set the perspective and expertise in the system prompt.
• Long context prompting: put long documents at the top and the question at the end; Anthropic says this can improve response quality "by up to 30 percent in tests".
• Chain complex prompts: split a big task into steps.

Anthropic's overview adds an important frame: first define success criteria and a way to test against them, and recognize that not every failure is a prompt problem. Sometimes the fix is a different model.

What context engineering adds

Anthropic's context engineering post describes it as the natural progression of prompt engineering: the set of strategies for "curating and maintaining the optimal set of tokens (information) during LLM inference." It adds questions prompt engineering never had to ask:

• Which tools should the model see? Each tool definition costs tokens and adds a choice. Fewer, clearer tools beat many overlapping ones.
• What should be retrieved, and when? Load a few relevant passages just in time rather than whole document sets up front.
• What happens when the window fills? Summarize (compaction), clear old tool results, or hand work to a sub-agent with a clean window.
• What should persist outside the window? Notes, to-do lists and memory that can be reloaded later.
• What is stale or contradictory? Old instructions and outdated facts cause "context clash".

LangChain sums these up as four strategies: write, select, compress and isolate. Our pillar on context engineering covers each technique in depth.

A worked example: the same support assistant, two ways

The prompt engineering version. You write a careful system prompt: role ("You are a support agent for Acme"), tone, a refund policy summary, an output format and three example replies. For simple questions this works well.

Where it breaks. Customers ask about specific orders. The policy has 40 pages of exceptions. Conversations run long. The assistant starts quoting an outdated policy, forgets the customer's order number from twenty turns ago, and sometimes calls the refund tool when it should only look up status.

The context engineering version. You keep the system prompt (prompt engineering still matters), then design the rest of the context:

Nothing in the second version required better wording. It required better decisions about what the model sees.

Why the shift happened

Two things changed between 2023 and 2025.

Systems got longer-running. A chatbot answers one message. An agent plans, calls tools, reads results and repeats, sometimes for hours. Its context is assembled dynamically, so the craft moved from writing text to designing what gets assembled.

Bigger windows did not solve it. Chroma's Context Rot study of 18 models found reliability tends to decline as inputs get longer, even on simple tasks. Anthropic calls the limit an "attention budget". Filling a big window carelessly makes results worse, not better.

The terminology followed. In June 2025, Tobi Lütke said context engineering "describes the core skill better", and Andrej Karpathy agreed that people associate prompts "with short task descriptions", while industrial-strength apps need the "delicate art and science of filling the context window with just the right information for the next step."

When to focus on which

Focus on prompt engineering when:

• The task is single-turn: summarize this, classify that, draft an email.
• All the needed information fits comfortably in one prompt.
• Outputs are inconsistent in format or tone.

Focus on context engineering when:

• You are building an agent or anything with tools. See how to build an AI agent.
• The model needs your documents or live data (RAG, MCP tools).
• Quality degrades as conversations or runs get longer.
• Costs grow with every turn.

In practice you do both: get the prompt right on a small test set, then engineer the context as the system grows.

Skills to learn for each

If you are building your skills, the two disciplines stack:

Prompt engineering foundations

• Writing clear, specific instructions and output formats.
• Choosing a few good examples instead of many rules.
• Structuring inputs with tags or sections so the model can tell instructions from data.
• Defining success criteria and testing prompts against a small evaluation set, which Anthropic lists as the step before any prompt work.

Context engineering on top

• Retrieval: chunking, embeddings, hybrid search and re-ranking, and returning only the top few results.
• Tool design: small, distinct tools with precise descriptions and compact outputs, often delivered through MCP servers.
• State and memory: what to store outside the window, how to reload it, and how to keep it accurate.
• History management: compaction, clearing old tool results, and knowing when to start a fresh sub-agent.
• Measurement: tracking tokens per task, cost, latency and failure modes across long runs, not just single answers.

A useful test for which one you need: if your system fails on the first turn, look at the prompt. If it works on the first turn and fails on the twentieth, look at the context.

Common mistakes when moving from prompts to context

• Fixing context problems with more prompt text. Adding "always remember the order number" to the system prompt does not help if the order number has been pushed out of an overflowing history. Store it in a summary instead.
• Treating the context window as storage. Big windows are for working memory, not archives. Retrieve what each step needs.
• Letting tool output pile up. Raw tool results are often the largest part of an agent's context. Trim or clear them once used.
• Changing the prefix every turn. Timestamps or reordered tools at the top of the prompt defeat prompt caching. Keep the stable parts first and unchanged.

Is prompt engineering dead?

No, but the job title is fading into a broader skill set. Writing clear, structured instructions is still the base layer, and model vendors keep publishing detailed prompting guides for every new model. What changed is that, for most production AI work, the prompt is the easy part. The hard part, and the part that separates a demo from a reliable product, is everything else in the context window.