Prompt Engineering vs Context Engineering

Prompt engineering is wording a single instruction well. Context engineering is deciding what information belongs in the model's context at all — instructions, history, retrieved documents, tool results — before any wording even happens. Prompt engineering is what matters most typing into a chat box. Context engineering is what matters most once you're building a system, where most of what the model sees was never typed by a person at all.

What prompt engineering is

Writing and structuring the instructions given to a model to get a more reliable, useful response — how a task is phrased, what examples are included, what output format is requested. It's the layer closest to the actual words sent to the model. The Prompt Engineering page covers what makes one actually work; Prompt Engineering Interview Questions covers the practical depth on debugging and evaluating prompts.

What context engineering is

Deciding what information actually goes into a model's context for a given task — which instructions, which retrieved documents, how much conversation history, which tool results — rather than treating everything as if it should just be included. In a real application, most of what a model sees was never hand-typed: it's assembled from a system prompt, a RAG retrieval step, prior turns of a conversation, and whatever a tool just returned. Get this wrong and no amount of careful wording fixes it: the model simply won't have what it needs, or will have so much irrelevant material that what matters gets lost in it. The Context Engineering page covers what it actually consists of — selection, compaction, isolation, and ordering — in more depth.

Why it became its own discipline

As long as most AI usage was one person typing one question into a chat box, wording was most of the problem — there wasn't much else in the request to manage. That stopped being true once systems started running agents across many steps, retrieving documents, calling tools, and carrying long conversation histories. The question shifted from "how do I phrase this" to "what does this request even contain," and that's a different problem with different techniques — retrieval and filtering, summarizing or dropping stale history, keeping one part of a task's context from bleeding into another, and taking into account that a model uses information near the start or end of its context window — the fixed amount of text it can take in for one request — more reliably than information buried in the middle.

Side by side

Not a rebrand

The two are genuinely different skills, not a new name for an old one. A prompt can be worded perfectly and still fail if the context around it is missing the one document that actually answers the question, or is so cluttered with irrelevant history that the model can't find it. A context assembly can be exactly right — the perfect retrieved passage, the right amount of history — and still produce a poor answer if the instructions wrapped around it are vague. Neither one substitutes for the other; a real application generally needs both done well.

Which one your problem calls for

Reach for prompt engineering when the information the model needs is already there and the output is inconsistent, unclear, or in the wrong format — the fix is in how the task is phrased, not what's supplied alongside it.

Reach for context engineering when the model seems to be missing information it should have, seems distracted by irrelevant material, or the request is assembling documents, history, and tool results from multiple sources at once. A support chatbot with one static system prompt and no retrieval is mostly a prompt-engineering problem. A RAG-based internal assistant juggling retrieved documents, conversation history, and tool results on every request is mostly a context-engineering problem — no amount of rewording the instructions fixes the wrong documents being in the request.