Context engineering

Deciding what information goes into the model's context — instructions, documents, examples, history, tool results — and in what order and form.

Last updated: November 9, 2026 · Markdown version

← Back to glossary

How to apply it in prompts

Use this concept to reduce ambiguity and improve consistency. If you need strict formatting, combine it with a JSON guide and a per-model template.

Strict JSON Models Packs

What it means

Definition: context engineering widens prompt writing from 'how do I phrase the request' to 'what should the model see, from where, and in which shape' — everything in the window, not just your last message.
Why it matters: the quality of an answer depends on the quality of its context. Missing facts cause guesses; irrelevant text dilutes attention and costs tokens.
How to apply it: select only what the task needs, label each piece (instructions, data, examples), put stable rules first and the question last, trim or summarize history, and re-check what is actually being sent.
Pair it with evaluation: change the context, rerun your test inputs, and keep what measurably helps.

Copy-paste example

<instructions>
You are a support analyst. Answer only from <policy> and <ticket>. If the policy does not cover the case, say so.
</instructions>

<policy>
[paste only the relevant policy section]
</policy>

<ticket>
[paste the ticket]
</ticket>

Task: draft a reply of at most 120 words and name the policy rule you applied.

Opens the analyzer with the prompt prefilled.

Open in Promptea

FAQ

Is context engineering the same as prompt engineering?

It includes it. Prompt engineering focuses on the wording of the request; context engineering also covers which documents, examples, history and tool results are sent along.

How much context is too much?

When added material stops improving your test results. Beyond that it only costs tokens and can bury the facts that matter.