Context engineering vs prompt engineering: what actually changes?

The difference is scope

The two overlap. A clearer prompt can improve an answer, but it cannot repair missing evidence, an outdated policy document or access to the wrong customer's record. Context engineering asks how those inputs are selected, assembled and kept appropriate for the task.

This is not proof that prompting is obsolete. It is a useful way to describe a broader application-design responsibility. The practical goal stays the same: give the model enough trustworthy, relevant information to do a bounded job, without drowning it in everything the application knows.

A policy assistant makes the distinction concrete

Imagine an employee asks whether an expense is reimbursable. A prompt-only improvement might tell the model to be concise, explain its reasoning and cite evidence. Those instructions help define the response, but they do not supply the current reimbursement policy.

The context design determines which policy version is retrieved, whether the employee may access it and whether an older exception is still valid. It also determines what happens when the question lacks a country, expense date or category. The model should not fill those gaps with a plausible-sounding assumption.

A well-designed request might include the employee's question, a small set of authorised current policy passages, the relevant effective dates and instructions to ask for missing facts. It would exclude unrelated documents and private records that the user does not need to answer the question.

• Prompt decision: how should the assistant answer and express uncertainty?
• Evidence decision: which accessible passages support this particular question?
• Freshness decision: which version applies to the date and context?
• Memory decision: which previous facts remain relevant and verified?
• Tool decision: which operations can the assistant request, and with what limits?

Make a context inventory before adding more text

For one representative request, list every piece of information sent to the model and why it is there. Include hidden instructions, retrieved passages, tool descriptions and previous messages. Applications often carry repeated or stale material that nobody consciously chose.

Mark each item by source, access scope and freshness. A retrieved policy passage and a user's description of a policy are not equally authoritative. A saved preference and a legally relevant account fact should not be treated as the same kind of memory.

Anthropic's context-engineering guidance emphasises selecting and maintaining useful information within the model's finite context. Turn that principle into a concrete review: if you remove an item, which task becomes harder? If you cannot answer, the item may not belong in every request.

Use a budget as a design tool

Here is a fictional planning example, not a provider limit: a team reserves 1,000 tokens for instructions, 2,000 for recent conversation, 4,000 for evidence and 1,000 for tool descriptions. That is an 8,000-token input plan, with additional room deliberately reserved for the output and any model-specific requirements.

The exact allocations should come from your workload. The value of the example is that each category has a purpose and a limit. Without a budget, one large tool result or an ever-growing conversation can crowd out the evidence needed for the answer.

When a category grows, improve selection before simply expanding everything. Deduplicate evidence, summarise older dialogue carefully and return structured tool results containing relevant fields. Keep provenance so an answer can still be traced to the source after the context has been shortened.

Separate memory from authority

An assistant may remember that a user prefers short answers. That is a useful preference. It should not remember an unverified statement about permissions and then treat it as authority on future requests. Durable memory needs rules about what is saved, who can inspect it and when it expires or is corrected.

Keep access decisions in the application. Retrieve documents only after checking the caller's permissions, and recheck them when the request changes. The model should not be asked to decide whether a persuasive user message grants access to a private source.

For developer tools, repository instruction files are another form of context. Anthropic documents CLAUDE.md and other memory mechanisms, but prose instructions remain distinct from enforced permissions. The same distinction applies to a business assistant: “do not send without approval” should be backed by an actual approval boundary.

Evaluate the whole assembled request

Test a current policy question, a question requiring clarification, an outdated-source case and a request involving inaccessible content. Inspect the evidence actually supplied to the model, not just the final answer. Otherwise, a retrieval or access error may be misdiagnosed as a prompting problem.

Compare changes using the same representative cases. If you improve the prompt and change retrieval at the same time, you cannot tell which change helped. Record context size, source selection, answer correctness and appropriate abstention on reviewed examples.

Does more context always help? No. Irrelevant or contradictory material can make the task harder and increase cost. Does context engineering replace prompt engineering? No. It places prompting inside a wider system that manages evidence, tools and memory. That wider view is useful because most production failures involve more than the wording of one instruction.