Context engineering vs prompt engineering

Prompt engineering is writing and organizing the instructions you give a model. Context engineering is deciding everything the model sees at each step: instructions, retrieved documents, tool definitions, tool results, memory and message history. Anthropic describes context engineering as “the natural progression of prompt engineering”, so the two overlap and the prompt is one input to the context.

What each term means

Anthropic defines prompt engineering as “methods for writing and organizing LLM instructions for optimal outcomes” and context engineering as “the set of strategies for curating and maintaining the optimal set of tokens” in a September 2025 post.

Andrej Karpathy wrote the version LangChain and others quote: people associate prompts with short task descriptions, while in an industrial-strength LLM app, “context engineering is the delicate art and science of filling the context window with just the right information for the next step.” He lists what goes in: task descriptions and explanations, few-shot examples, RAG, related data, tools, state and history, and compacting.

Tobi Lutke put the case in one line: the term “describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.”

Comparison

	Prompt engineering	Context engineering
What you shape	The instructions and examples you write	Everything in the request: system prompt, messages, tool definitions, tool results, retrieved data, memory
When it happens	When you write or revise the prompt	At every step of a run, as the window fills
Typical question	Are the instructions clear enough?	Does the model have the right information and tools for this step?
Main failure	Ambiguous or badly organized instructions	Missing, stale, irrelevant or too much information
Typical tools	Clearer wording, examples, structure, role, chaining	Retrieval, compaction, tool result clearing, memory, sub-agents
Fits best	Single calls and fixed tasks	Agents and multi-turn apps

The “fits best” row is a summary of the sources, not a rule from any of them. Anthropic, for instance, discusses system prompt wording inside its context engineering post.

Where sources disagree

Harrison Chase argued that “prompt engineering is a subset of context engineering.” On whether clear behavior instructions count as one or the other, he said “I think it’s a bit of both.”

Karpathy goes the other way on scope. Karpathy calls context engineering “just one small piece of an emerging thick layer of non-trivial software” that also breaks problems into control flows, dispatches calls to the right model, handles generation-verification UI, and covers guardrails, security, evals, parallelism and prefetching.

So one source puts prompts inside context engineering, and another puts context engineering inside a larger application layer. They agree on the practical point: the prompt alone does not decide what the model sees.

Why context needs engineering

The context window is finite and bigger is not automatically better. The Claude docs say [“As token count grows, accuracy and recall degrade, a phenomenon known as context rot”](https://platform.claude.com/docs/en/build-with-claude/context-windows), which makes curating what is in context as important as how much space is available. Anthropic’s post says context must be treated as “a finite resource with diminishing marginal returns” and that models have an “attention budget”.

Karpathy describes both directions: with too little, or the wrong form, the model lacks what it needs, and with too much or irrelevant material, “the LLM costs might go up and performance might come down.”

Everything in a request counts, per the Claude docs: the system prompt, every message, tool results, images, documents and tool definitions.

The techniques

LangChain sorts context engineering for agents into four strategies.

Strategy	Meaning (LangChain)	Examples in the sources
Write	Save context outside the window	Scratchpads and long-term memory; Anthropic’s structured note-taking
Select	Pull the relevant context into the window	Retrieval; Anthropic’s just-in-time loading via lightweight identifiers such as file paths and stored queries
Compress	Keep only the tokens the task needs	Summarization and trimming; Anthropic’s compaction and tool result clearing, which it calls “one of the safest lightest touch forms of compaction”
Isolate	Split context up	Sub-agents with clean windows that return a condensed summary

Some of these are available as API features. The Claude docs list context editing (tool result clearing and thinking block clearing) and server-side compaction, in beta for Claude 4.6 and later models as of October 2026.

What stays prompt engineering

Context engineering does not remove the work of writing instructions. Anthropic’s advice for the system prompt is to find the “right altitude”, between two failure modes, and to use the “minimal set of information that fully outlines your expected behavior.”

The Claude docs also say when prompting is the wrong lever. Prompt engineering assumes you already have defined success criteria, a way to test against them and a first draft, and “Not every success criterion or failing eval is best solved by prompt engineering”: a different model can fix latency or cost more easily.

Telling a prompt problem from a context problem

Chase wrote that the framing “helps separate the failure modes”: is the agent failing because it was not given the right information or tools, or because it had them and still got it wrong? Those have different fixes. Look at what the model received at the step that failed:

• If the needed fact or tool was missing, stale or buried, it is a context problem.
• If the needed material was present and the model ignored or misread it, look at the instructions, the model, or whether too much else was competing for attention.

Chase also pointed at format: “A short but descriptive error message will go a lot further a large JSON blob.” That is a context fix, since it changes what a tool result puts in the window.

Seeing the context in HoneyHive

You can only fix context you can inspect. HoneyHive stores each run as a session, and its model events record the input messages and parameters and the outputs of each LLM call, so you can read what the model received at the step that failed. For the broader practice, see agent observability and LLM observability, and for testing changes, LLM evaluation.

FAQ

Is prompt engineering dead?

No source in this comparison says so. Anthropic calls context engineering "the natural progression of prompt engineering", and Harrison Chase argues that prompt engineering is a subset of context engineering. The instructions still have to be written well.

Who coined the term context engineering?

Nobody can be shown to have invented it. In June 2025 Shopify CEO Tobi Lutke wrote that he liked it over prompt engineering, and Andrej Karpathy followed with a definition. Harrison Chase wrote that his own definition builds on recent takes from Lutke, Ankur Goyal and Walden Yan.

Is context engineering the same as RAG?

No. Karpathy lists RAG as one input among many, next to task descriptions, few-shot examples, tools, state and history, and compacting. RAG is one way to select what goes into the window.