Context Engineering vs Prompt Engineering

Prompt engineering is the craft of writing and organising the instructions you give a model: the wording, the examples, the structure, the role. Context engineering is the wider job of deciding everything the model has in front of it when it acts: those instructions, plus the tool definitions, the documents and search results it has fetched, the conversation so far and anything it remembers from earlier sessions. The prompt is one part of the context. The difference matters most for AI agents, which run for many turns and fill their own context as they go, so most of what the model reads at step forty was never written by a person at all.

What prompt engineering covers

Prompt engineering grew up around a single exchange: you write a request, the model answers, you judge the answer and rewrite the request. Anthropic’s prompting best practices↗ (opens in a new tab) is a good map of what the discipline includes:

• Being clear and direct about the task, the audience and the format you want back.
• Giving examples of good output, so the model can copy the pattern rather than guess it.
• Structuring long inputs, for instance by wrapping documents and instructions in labelled sections.
• Setting a role in the system prompt, so the model answers as a reviewer, a tutor or an analyst.
• Asking the model to think before it answers, or splitting a job into a chain of smaller prompts.

The unit of work is the prompt, and the test is whether one response meets your criteria. Anthropic’s prompt engineering overview↗ (opens in a new tab) even starts by asking whether you have success criteria and a way to test against them, and notes that not every failing test is a prompt problem: sometimes a different model is the better fix for cost or speed.

What context engineering covers

Anthropic’s engineering team defines context engineering as the strategies for curating and maintaining the optimal set of tokens↗ (opens in a new tab) during inference, “including all the other information that may land there outside of the prompts”. Their list of that other information is the useful part: system instructions, tools, MCP servers, external data and message history. Context engineering asks what should be in the window at this step, what should be left out, and what should be kept somewhere else until it is needed.

That list is not a figure of speech. The Claude API documentation on context windows↗ (opens in a new tab) spells out that everything in a request counts: the system prompt, every message including tool results, images and documents, and the tool definitions themselves. A carefully worded prompt can end up as a small fraction of what the model reads on any given turn.

The two side by side

• The question it asks. Prompt engineering: how should I phrase this? Context engineering: what does the model need to see right now, and what is in the way?
• The unit. Prompt engineering works on one prompt or system prompt. Context engineering works on the whole state of the window across a run of many turns.
• Who writes the material. In prompt engineering, you do. In context engineering, much of it is written by tools, files, earlier turns and the model itself.
• How it goes wrong. A weak prompt gives a vague or off-target answer. Weak context gives an agent that lacks the one fact it needed, or has it buried under pages of irrelevant tool output.
• What you adjust. Prompt engineering changes words, examples and structure. Context engineering changes which tools are connected, what gets fetched and when, how history is summarised, and what is written down outside the window.

Where one ends and the other begins

The boundary is easiest to see as two decisions. Prompt engineering decides how the words you control are written. Context engineering decides which words, from any source, are present at each step. Writing a good system prompt is still prompt engineering; choosing to load it on every turn, and keeping it short because it is paid for on every turn, is context engineering.

Some work sits squarely in the overlap. Anthropic’s advice about finding the “right altitude” for a system prompt, specific enough to guide behaviour but flexible enough to give the model strong heuristics, is prompt craft applied to a context problem. So is writing clear descriptions for tools, because a tool description is prose the model reads in order to decide what to do.

A quick way to tell which one you are dealing with: if the model had exactly the right information and still did the wrong thing, look at the prompt. If it did something reasonable given what it could see, but what it could see was wrong, missing or crowded out, look at the context.

Why the term shifted

Anthropic describes context engineering as “the natural progression of prompt engineering”, and the reason is agents. A chat exchange has one prompt and one answer, so the prompt really is most of the context. An agent works in a loop: it calls a tool, reads the result, calls another, and every result stays in the window. After an hour of work the window is mostly file contents, command output and its own earlier reasoning. No amount of care over the opening instruction controls that material, so the craft had to widen from writing text to managing a changing collection of text.

Three other changes pushed in the same direction:

• Tools arrived in bulk. Connecting several MCP servers can put dozens of tool definitions in front of the model before the task starts, and choosing which to connect is a context decision.
• Work began to span sessions. When a job takes days, what the model knows at the start of Tuesday’s session depends on what was written down on Monday, in instructions files, memory files or tasks.
• Bigger windows did not remove the problem. More room lets more in, but more material is not automatically more useful; the documentation itself warns that accuracy and recall degrade as the token count grows. That effect has its own name and its own post: context rot.

Does prompt engineering still matter?

Yes. Context engineering contains prompt engineering rather than replacing it. The system prompt, the instructions file, each tool description and each task brief are still pieces of writing, and badly written ones still produce bad results however well the rest of the window is managed. What changed is the scope of the job: a good prompt is necessary, and it is no longer sufficient once the model is acting over many steps.

The skills also carry across. Someone who writes tight prompts tends to write tight instructions files, clear tool descriptions and task notes an agent can act on, which is most of the writing context engineering asks for.

What the shift means for a team

Prompts are usually personal: one person, one chat, one request. Context increasingly is not. An instructions file such as CLAUDE.md is committed to the repository and read by everyone’s assistant; Claude Code’s memory documentation↗ (opens in a new tab) describes project instructions as shared with team members through source control, and is candid that the model treats them as context, not enforced configuration. The plan for a piece of work, the decisions made about it and the gotchas someone found last week are context too, and they are most useful when they live somewhere every assistant and every person can read.

That is the part fenbs takes on. A board keeps AI context, short notes each connected assistant reads on arrival with fenbs_get_context, and an assistant that learns something can leave a signed note with fenbs_add_context_note. Each task carries its own note, plan and comments, so the state of the work is context the next session can fetch rather than something that lived only in yesterday’s chat. How to put all of this into practice, step by step, is covered in context engineering for AI agents.