What is the difference between context engineering and prompt engineering?

Prompt engineering is writing the text somebody drafted well: the instruction, the requested format, the examples. Context engineering is deciding everything that fills the window on that call — that text, plus the history, the tool definitions and the retrieved documents. The second contains the first. They are not rivals, and the newer one did not retire the older one.

The confusion has a concrete cause. When each term appeared, the work looked different. In 2020 you sent a block of text and got a block of text back, and improving the result meant improving that block. That is prompt engineering, and for a single call it still covers almost everything that matters.

In 2026, a good share of applications run an agent that calls tools in sequence. What the model reads on the tenth iteration was written by nobody: it came from a search, a file read, an API response. Deciding what stays and what goes is context engineering, and it is a problem the older discipline never had to solve.

What each one decides

The model does not see the split. It receives a sequence of tokens and answers. The separation lives in your code, and it is useful because the two halves fail in different ways and get fixed with different tools.

Prompt engineering decides what is written. Which role the model takes, what shape the output has, what to do with ambiguous input, how many examples to show and which ones. It is technical writing, evaluated by running variations against a set of cases. The cycle is short: change a sentence, measure in minutes.

Context engineering decides what arrives. How much space each category gets, what is fetched on demand and what is preloaded, when history is summarised, in what order the blocks go in, and what is dropped when the window tightens. It is systems work, evaluated with instrumentation: how many tokens went to each category, on each call.

The two green bands in the figure are the overlap. The system prompt and the user’s question are hand-written text, and therefore territory of both disciplines at once. Anyone working only with single calls spends their whole life in that overlap, which is why the distinction feels academic — until the first time a 30,000-token tool result lands in the window unannounced.

The fastest way to feel the difference is to look at the shape of the failure. A prompt failure is consistent: the model fails the same way across similar cases, because the instruction is ambiguous the same way every time. A context failure is irregular: the same request works in one session and fails in another, and the variable that moved was what was already in the window when it arrived. If your bug only shows up in long conversations, or only after the tenth tool call, it is not about wording.

Where each term came from

The practice predates both names, but the order they arrived in explains what each was trying to solve.

The prompt became the interface in 2020. The GPT-3 paper showed that a task could be specified without updating a single weight, just by describing it and putting a few examples in the input — what the authors called in-context learning¹. From then on, the input text stopped being a usage detail and became the place where the work happens.

The name got a sharper outline in 2021. A paper that year argued prompts should be thought through the lens of natural language rather than as configuration — and measured something that ran against the received wisdom of the time: well-written zero-shot prompts could beat prompts carrying examples. The explanation they offer is that examples, in those cases, serve less to teach the task than to locate a task the model already knew².

Context engineering is from 2025. The term circulated mid-year and got systematic treatment when Anthropic published an engineering guide defining the discipline as curating the set of tokens available during inference, with four techniques: compaction, structured note-taking outside the window, sub-agents, and just-in-time retrieval³. That July, an academic survey formalised the field out of more than 1,400 papers, decomposing it into context retrieval and generation, context processing and context management⁴.

Note what the two terms have in common: neither invented a technique. Both named a set of practices that already existed, at the moment those practices grew too large for the previous name.

There is a less discussed and more practical difference between them: how each gets measured. A prompt is evaluated by running variations against a set of cases with expected outputs, and the number that comes out is an accuracy rate. A context is evaluated by instrumentation — how many tokens went to each category, where in the window the answering information sat, how many iterations passed before the answer appeared. Different instruments, and a team holding only the first can improve prompts indefinitely without ever seeing the assembly problem.

What changed is the loop

An agent works like this: the model reads the window, decides to call a tool, the tool’s result goes back into the window, and the model reads everything again. Repeat twenty times.

Each turn adds content nobody wrote and nobody reviewed. A large git diff, a failing test log, a page’s HTML, a paginated API response: any of those clears 10,000 tokens without trying. By the tenth iteration, the system prompt you wrote so carefully is a small fraction of what the model is reading.

That is where questions appear that prompt engineering cannot answer, because they are not about text:

• Which tool result still matters at iteration 15?
• Should the 40,000-token log go in whole or be cut at the source?
• Should history be summarised at 60% of the window or at 90%?
• Are fifteen tools described on every call worth the tokens they cost?
• Is the right answer sitting in the middle of the context, where the model reads worst⁵?

None of those decisions is about writing better. All of them are about assembling better. That is the gap the second term filled, and it is why it appeared when it did: agents in production are a 2025 thing, not a 2021 thing.

A case that separates them

It is worth following one real bug end to end, because the difference gets obvious when it costs money.

A support agent answers a refund question by citing the wrong policy. The right policy exists, it is in the knowledge base, it was indexed. The agent has a search tool and it called it.

The first reflex of anyone who works on prompts is to rewrite the instruction: “always cite the policy currently in force”, “check the effective date before answering”. That lifts the hit rate a little and does not fix it, because the cause lives outside the text.

What actually happened was different. Search returned six passages, two of them from a revoked version of the policy. All six entered the window in relevance order, and the right passage landed in fourth place, inside a context that already carried 18,000 tokens of conversation history. The model read everything and picked the one most similar to the question, which was the revoked one.

The fixes that work are all about assembly: filter by effective date in the search metadata, cut from six passages to two, put search results at the end of the window instead of the middle, summarise history before adding documents. None of them is a better-written sentence.

And there is one fix that genuinely belongs to prompt engineering, and is also needed: instructing the model to say it did not find anything when the passages do not answer. Without that it answers from whatever arrived, with its usual confidence.

Both jobs are real. The mistake is picking one out of habit rather than out of diagnosis.

Telling which one your problem is

There is a test that separates them in an afternoon, and it is worth more than any definition.

Take ten cases where the application fails. For each one, assemble the ideal context by hand: paste in the right document, the right paragraph of the policy, the right tool result. No search, no agent. Just the model, your prompt, and the content that should have arrived.

If the model gets them right that way, the problem is context. The right content existed and did not arrive, or arrived buried in the middle of another thirty thousand tokens. Editing the instruction will not fix it, and that is exactly where most teams spend the following two weeks.

If the model fails even with everything handed over, the problem is the prompt — the instruction is ambiguous, the format is undescribed, the hard case has no example — or the task is beyond what the model does. In both cases, optimising context assembly would be wasted work.

The test is cheap and almost nobody runs it, because it requires admitting up front that you do not know which of the two is broken.

Where the distinction stops helping

Renaming the work does not change the work. A good share of what was published about context engineering across 2025 and 2026 is the same material that was called prompt engineering in 2023, with new vocabulary. If your case is a single chat call, both terms describe the same job and the distinction does not repay the effort of learning it.

The boundary is porous on purpose. The system prompt is written text and it is a slice of the window. A few-shot example is a prompt and it occupies context. Arguing which side each thing falls on is the kind of conversation that consumes a meeting and changes no code.

Neither name often describes the actual bottleneck. A considerable share of the effort in both disciplines goes into tasks the model simply cannot do. The test in the previous section exists precisely to find that out first.

The newer term carries a promise it does not keep. “Context engineering” sounds like a settled discipline with established practice. It is not: the evidence on block ordering, compaction thresholds and summary format is thin and varies by model family. What is solid is the instrumentation — measuring where the tokens go — and that is diagnosis, not cure.

What to do with this

1. Instrument before naming. Log, per call, how many tokens went to system prompt, tools, history and documents. The dominant slice usually surprises, and it tells you which discipline your problem belongs to.
2. Run the ideal-context test on ten failing cases before rewriting any instruction.
3. Treat the system prompt as text, with the rigour of prompt engineering: versioned, tested against cases, reviewed by someone.
4. Treat everything else as a system, with an explicit budget per category and truncation at the source.
5. Redo the measurement on every model change. The point where context starts getting in the way moves, and your configuration was calibrated for the previous model.

If you only make single calls, stop at step 3. The rest is infrastructure for a problem you do not have yet.

Footnotes

1. Brown et al. (2020) showed a task can be specified in the input itself without updating weights, which turned the input text into the place where the work happens. ↩

2. Reynolds and McDonell (2021) measured zero-shot prompts beating prompts with examples in several cases, and proposed that examples serve more to locate an already-learned task than to teach it. ↩

3. Anthropic’s engineering guide, from September 2025, defines the discipline as curating the set of tokens available during inference and describes compaction, structured notes, sub-agents and just-in-time retrieval. ↩

4. Mei et al. (2025) systematised the field out of more than 1,400 papers, decomposing it into context retrieval and generation, processing and management. ↩

5. Liu et al. (2023) measured degraded performance when the relevant information sits in the middle of the context, including in models sold as long-context. ↩