A couple of years ago, "prompt engineer" was a job title people put on LinkedIn with a straight face. The pitch was simple: learn the magic words, phrase your request just so, and the model gives you gold. Whole courses sold on the promise.
That skill hasn't vanished, but it has been demoted. In July 2025, Gartner put it bluntly: context engineering is in, prompt engineering is out. The wording of your one message, it turns out, is a small part of what actually determines whether an AI system gets the answer right. The bigger lever is everything else the model is looking at when it answers.
Here's the difference in a sentence. Prompt engineering is about the words you send. Context engineering is about the entire set of information the model sees on a given call: the system prompt, the tools it can use, the documents you retrieved, the memory it carries between sessions, the conversation so far, and yes, your prompt sitting inside all of that.
Prompt engineering, and why it was never enough
Prompt engineering is real and still useful. Asking a model to "explain this for a busy finance director who hates jargon" genuinely gets you a better answer than "explain this." Giving it a role, a format, and an example still works.
The catch is that prompt engineering operates one question at a time. You tune the phrasing, you get a better single reply, and then the next conversation starts from scratch. It was fine when we treated models like a clever search box. It falls apart the moment you try to build something that works reliably, across many turns, on top of your own data. A perfectly worded prompt cannot rescue a model that is missing the one document it needed, or drowning in ten thousand it didn't.
What context engineering actually means
Anthropic defines context engineering as the set of strategies for curating and maintaining the optimal set of tokens during model inference, including everything that lands in the window beyond the prompt itself. The key word is curating. You are the editor deciding what makes it in front of the model and what stays out.
Think about what fills that window on a real agent call:
- The system prompt that sets who the agent is and how it should behave.
- The tool definitions that tell it what actions it can take.
- The retrieved knowledge you pulled in for this specific question.
- The memory it kept from earlier sessions.
- The conversation history up to this point.
- And then the user's actual prompt.
Prompt engineering is you polishing that last item. Context engineering is you designing the whole stack, and doing it again on every call, because what should be in the window changes with each step the agent takes.
Here is the same idea side by side:
| Prompt engineering | Context engineering | |
|---|---|---|
| Scope | The wording of one message | The entire context window |
| When it runs | Per question | Continuously, every call |
| Main question | "What words should I use?" | "What is the smallest set of high-signal tokens that gets the right answer?" |
| Good analogy | Asking a smart question | Briefing a new hire with exactly the right file open |
| Where it lives | In the chat box | In your architecture: retrieval, memory, tools |
Why the shift happened: the model has an attention budget
The deeper reason context engineering exists is that a context window is not free real estate. It is a finite, depleting resource.
Anthropic describes this as context rot: as the number of tokens in the window grows, the model's ability to accurately recall any given one of them drops. It's the same reason a person skim-reading a hundred-page brief will miss the sentence that mattered. The model has a limited attention budget, and every token you add spends a little of it. The technical culprit is the transformer itself: attention compares every token to every other token, so cost and confusion grow faster than the length does.
This is the punchline that trips people up. Stuffing more into the prompt often makes answers worse, not better. Slower, more expensive, and more likely to lose the thread. So the goal of context engineering, in Anthropic's words, is finding the smallest possible set of high-signal tokens that get you the outcome you want. Less, but exactly the right less.
The tactics that actually move the needle
Curating the window well comes down to a handful of moves. None of them are about clever wording.
-
Set the system prompt at the right altitude. Specific enough to steer behaviour, general enough not to be a brittle list of hardcoded rules. Too vague and the agent wanders. Too rigid and it snaps the first time reality doesn't match your script.
-
Keep the toolset small and sharp. Give the agent a few clear, non-overlapping tools that return compact results. A pile of overlapping tools that dump huge outputs just burns the budget and confuses the choice.
-
Retrieve just in time. Rather than pre-loading everything the agent might conceivably need, let it pull in data at runtime using lightweight pointers like file paths or URLs, and only when the moment calls for it.
-
Give it memory outside the window. Let the agent keep structured notes in a file or store, so important decisions survive even when the live conversation gets trimmed. Its working memory shouldn't be the only place knowledge lives.
-
Compact long conversations. When a session runs long, summarise what happened so far and keep the decisions that matter, dropping the redundant back-and-forth. You preserve the thread without dragging the whole transcript along.
-
Split work across sub-agents. Hand focused sub-tasks to specialised agents that each work in a clean window, then return a tight summary to the main one. Each agent gets a fresh attention budget instead of everyone sharing one crowded room.
So is prompt engineering dead?
No, and anyone who says so is overselling the headline. Prompt engineering is now a subset of context engineering. The words in your system prompt and your instructions still matter, and writing them clearly is still a skill worth having. What changed is that the words are no longer the whole game. They are one slice of a much bigger design problem.
The honest framing: prompt engineering asks what to say. Context engineering asks what the model should be looking at when you say it. If you are just chatting with an assistant, the first question is most of what you need. If you are building an agent or a product on top of a model, the second question is where the reliability actually comes from.
What this means if you're building with AI
If your AI feature works great in the demo and gets flaky in the real world, the problem is almost never the prompt. It's the context. Either the model isn't seeing something it needs, or it's buried under things it doesn't. That's a retrieval, memory, and curation problem, and no amount of prompt-tweaking fixes it.
The practical move is to stop treating the prompt as the product and start treating the whole context pipeline as the product. Decide deliberately what goes into the window, keep it lean, and revisit that decision on every call. Gartner expects context engineering to show up in most AI tools within a few years, and standards like the Model Context Protocol exist precisely to make this pluggable rather than bespoke. The teams that get good at it now are the ones whose AI actually holds up once real users show up.