Context Engineering vs Prompt Engineering: What Actually Changed

"Context engineering" started appearing in job titles and engineering blogs around 2025, and by now it has largely displaced "prompt engineering" in serious technical work. The obvious reaction is that somebody rebranded a skill to make it sound harder.

That is not quite what happened. The job genuinely changed, and the name changed to match. Understanding the difference is the difference between an AI feature that works in a demo and one that works in production.

What prompt engineering was

Prompt engineering, as it was practised in 2023 and 2024, meant writing better instructions. You sat in front of a chat box and worked out that specifying a role, a format and a set of constraints produced dramatically better output than asking a bare question.

That skill has not stopped being useful. Everything in our guide to prompt engineering still holds — a vague request still returns average output, because the model still has to guess at everything you did not say.

But it was a skill for one person talking to one model in one conversation. Almost nothing built on top of language models works that way any more.

What changed

Three things happened at roughly the same time.

Context windows got large. When a model could see 4,000 tokens, the question was how to phrase a request compactly. When it can see a million, the question becomes what to put in front of it — and the answer is no longer "everything", because filling a window degrades accuracy rather than improving it.

Models started using tools. A model that can search, call an API, read a file and run code is not receiving one prompt. It is receiving a stream of context that changes at every step, most of which no human wrote.

Applications replaced conversations. In a production system the end user does not write the prompt. They click a button. Something assembles the actual model input from a template, retrieved documents, conversation history, tool results and system rules — and that assembly is the thing that determines output quality.

Once that is true, "write a better prompt" stops being the lever. The prompt is one component in a much larger input, and often the least variable one.

So what is context engineering?

It is the discipline of controlling everything the model sees at the moment it generates — and, just as importantly, everything it does not.

In practice it covers:

Retrieval. Which documents get pulled in, how they are chunked, how relevance is scored, and how many make the cut. See our guide to RAG for the mechanics.

Compression. What to do when the relevant material exceeds the window. Summarising older conversation turns, dropping tool output that is no longer needed, deciding what can be discarded without losing the thread.

Ordering. Where material sits in the window. Accuracy degrades measurably for information buried in the middle of a long context — an effect well enough documented to have a name, "lost in the middle". Putting the critical material at the start or the end is a real intervention, not superstition.

Isolation. Deciding what a sub-agent or a tool call should be allowed to see. Passing an entire conversation into every step is the default and it is usually wrong, because irrelevant context does not sit inertly — it competes for attention.

State. What persists between turns, what resets, and what gets written down somewhere the model can retrieve later rather than carried in the window.

The failure mode nobody expects

The instinct with a large context window is to fill it. More information should mean better answers.

It does not, and the reason is worth internalising: attention is a finite resource that gets divided across everything in the window. Adding a marginally relevant document does not add its value and cost nothing — it dilutes the model's attention on everything else. Ten well-chosen paragraphs routinely beat a hundred pages containing those same ten paragraphs.

This is the single most common mistake in production AI systems, and it looks like diligence. The team added more source material and quality got worse, which is not the direction anyone expects, so it takes a long time to diagnose.

What this means for what you should learn

Prompt engineering is still where to start, and it is still learnable in an afternoon. It is the foundation, and someone who cannot write a clear instruction cannot engineer context either.

But if you are building anything beyond a chat interface, the questions that determine whether it works are context questions. What goes in the window. In what order. How much. What gets thrown away when there is too much. How state carries between turns.

Those are engineering problems with measurable answers, which is why the name changed. "Prompt engineering" described a writing skill. "Context engineering" describes a systems design problem — and it is the one that actually decides whether your application is any good.

Our context window calculator shows what fits, and the glossary covers the terminology you will hit as you go deeper.