There's a rename going through the agent world, and like most renames it's really an argument about where the hard part lives. For two years the marquee skill was prompt engineering — get the wording right and the model does what you want. Sometime in 2025 the people building actual agents started saying context engineering instead. It sounds like rebranding. It isn't. The two describe different jobs, and knowing which one you're doing tells you where to spend your next hour.

If you only take one line: prompt engineering optimizes a string you write once; context engineering optimizes a process that runs every turn.

Prompt engineering: the sentence#

Prompt engineering is the craft of wording a single instruction well. It's a real discipline with a real toolkit — few-shot examples, a clear role, chain-of-thought to slow the model down, delimiters to separate instruction from data, an explicit output format so you can parse the result. Point it at a single-shot task — classify this ticket, extract these fields, rewrite this paragraph — and a good prompt is most of the battle. The Prompt Engineering Guide catalogs the moves, and they still work.

What defines prompt engineering is when it runs: once. You author the string, you reuse it, and the context around it is small and roughly fixed. Your only lever is the wording, so you polish the wording.

Context engineering: the window#

Now put that same model inside an agent that loops fifty times — reasoning, calling a tool, reading the result, reasoning again. Each turn, something has to decide what tokens are in the window: the system prompt, the tool definitions, whatever documents you retrieved, long-term memory, the conversation so far, and — the part that quietly dominates — the growing pile of tool outputs.

That deciding is context engineering. Andrej Karpathy's definition is the one that stuck: the art of "filling the context window with just the right information for the next step." Anthropic's engineering team frames it as resource management — context is finite, attention degrades as it fills, so the goal is the smallest high-signal set of tokens that gets the job done. LangChain makes the same case from the framework side.

The crucial difference from prompt engineering is when it runs: every turn. And it doesn't run in your head — it runs in code. Retrievers, memory stores, summarizers, and tool-result handlers assemble the window fresh on each step. That's why the skill moved from writer to systems engineer.

A prompt is authored. A context is assembled — on every turn, by code you wrote. The bottleneck didn't get harder to word; it stopped being about words at all.

What actually moves the needle#

Once an agent is long-horizon, the payoff structure inverts. A sharper sentence buys you almost nothing; the wins are structural, and there are about six of them:

Every one of these is code that runs each turn, and every one is a lever prompt engineering simply doesn't have.

The failure mode has a name#

The reason curation matters is context rot: past a point, adding tokens makes a model slower, more expensive, and less accurate — the right fact is in the window, but it's buried under low-signal text and attention slips off it. We've written about why long context degrades; the operational takeaway is that more context is not more capability. Treat the window as a budget you spend, not a bucket you fill. That single reframe is most of what "context engineering" actually means.

So which are you doing?#

Use the run length as your test. One turn, small fixed input → prompt-engineer it. The wording is your only lever, so make it excellent. Many turns, state that grows → context-engineer it. The wording still matters, but it's now one component sitting inside a system that decides, every step, what the model gets to see. Prompt engineering didn't die in 2025. It got demoted to a subroutine — and the job around it got a lot more interesting. If you're building the loop from scratch, that system is the agent you're building, and the window is the product.