What Is Context Engineering?
Context engineering is the practice of deciding what a request contains before it is sent: which instructions, which retrieved passages, which tool definitions, how much of the prior conversation, and in what order. It is assembly work rather than wording work. The unit it operates on is the whole request, and the constraint it works against is that a request is finite and is paid for by the token.
A request is built, not remembered
In the ordinary stateless arrangement nothing carries from one request to the next. A serving endpoint receives a request, returns a reply and retains nothing about the exchange; anything the next turn depends on has to be placed into the next request by the application that sends it. What looks like a continuous conversation is a sequence of separate requests, each assembled from scratch by code that decides, every time, what to put in. Context engineering is the name for the part of the application making that decision, and in most systems it exists long before anyone calls it that.
The decision has more parts than it first appears to. Instructions are written once and reused, or rewritten per turn. Retrieved passages have to be selected, deduplicated and bounded, since a retrieval step will return the same paragraph three times under three headings without objecting. Tool definitions occupy the request whether or not a tool is used, so a tool list that grew by accretion is paid for on every turn. Prior turns are replayed in full, summarised, or dropped. Tool results are the least bounded element of all, because their size is set by whatever the tool returned rather than by the application that asked for it.
| Decision | What it fixes |
|---|---|
| What is included | Which instructions, passages, definitions and prior turns are present at all on this turn. |
| In what order | Where each element sits in the request, which is what makes a leading portion reusable. |
| How much of each | The share of a finite budget given to history, to retrieved material, and to room for the reply. |
| What is dropped first | The rule applied when the assembled request does not fit, decided in advance rather than by a truncation. |
| What stays byte-identical | Which leading run of the request is the same on every turn, and therefore what a cache can be asked to reuse. |
| What is never included | The material a request is forbidden to carry at all: credentials, unbounded tool output, another user’s records. |
Only the first of those rows is usually written down anywhere. The other five are settled by whatever the code happens to do, which is why a context assembly step tends to be discovered rather than designed — it is already there in every application that sends more than one request, and it becomes a component with a name at the point somebody goes looking for where the budget went.
Where it stops being prompt engineering
Prompt engineering settles the wording of an instruction: what to ask for, how to phrase it, which worked example to supply. Context engineering settles everything else in the envelope, and most of it is not made of sentences at all. A retrieval budget, a history policy, a tool list, a cache boundary and a drop order each change what a request contains without changing a word of the instruction inside it. The two are ordinarily done by the same person and are routinely conflated, but they fail differently, and that is the practical reason for keeping them apart: a badly worded instruction produces the wrong shape of answer consistently, from the first turn, while a badly assembled request produces a good answer on Monday and a truncated one on Friday, when the conversation has grown.
Position is one of the decisions, and it is worth being exact about what can be said of it. Where material sits in a request is not neutral. The leading portion decides whether a cached prefix is reusable at all, which is mechanical and checkable. Beyond that, how a particular deployment weighs material at a particular position is a measurement taken on that deployment, and this registry has taken none, so no ordering rule is recommended on this page.
The failure this work exists to prevent is not an error message. A request that does not fit is rejected, which is loud, attributable, and fixed the same afternoon. The quiet failure is a request that fits, is well formed, is answered fluently, and is missing the one paragraph the answer depended on — because the history policy dropped it four turns ago, or the retrieval step returned three copies of a heading instead of the section under it, or a tool result was cut at a character limit in the middle of the row that mattered. Assembly failures arrive as content that is merely wrong, with nothing in the exchange to indicate that anything was left out.
How the Registry classifies a context-assembly task
Rewriting an agent repository’s context assembly step so that every request is composed under a fixed token budget is filed as a code modification task here. The classification follows the artefact rather than the subject matter: the deliverable is a changed file under version control, reviewed and merged like any other, and the budget it enforces is a constant inside it.
The Registry's canonical brief for this entry is filed as:
Rewrite the context assembly step in an agent repository so every request is composed under a fixed token budget.
Submitted for assessment it is
classified as Code modification, and its wording is hashed once — to
71de3d0442882596…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/code.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about context engineering
What that budget ought to be, which elements deserve which share of it, and which ordering a particular deployment rewards are all left open by the canonical brief above, and deliberately so: it names an operation, not its settings. This registry assembles no requests on any operator’s behalf, holds no retrieval store, and has never measured what a given ordering does to a given answer.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about context engineering
- What is context engineering?
- Context engineering is the practice of deciding what a request contains before it is sent — instructions, retrieved passages, tool definitions, prior turns and tool results — together with their order and their share of a finite token budget. It is the assembly of the request rather than the wording of the instruction inside it.
- How is context engineering different from prompt engineering?
- Prompt engineering settles the wording of an instruction. Context engineering settles everything else in the request: what is retrieved, how much history is replayed, which tools are declared, what is dropped when the budget is exceeded, and in what order the parts arrive. The two are usually done by the same people and fail differently — a wording problem is consistent from the first turn, an assembly problem appears once a conversation grows.
- Is context engineering the same as RAG?
- No. Retrieval-augmented generation is one supplier of material into a request. Context engineering is the decision about what to do with what retrieval returns: how many passages to keep, whether to deduplicate them, where to place them, and what to drop to make room for them. A system can retrieve with no assembly policy at all, and retrieved passages are frequently the first element to exhaust the budget.
- Why does the order of a request matter?
- For one reason that is mechanical and one that is not. Mechanically, prefix caching reuses computation only for a leading run that is byte-identical to a previous request, so stable material placed first is reusable and volatile material placed first is not. Beyond that, how a deployment weighs material at different positions is measured per deployment, and no ordering rule is asserted here.
- What usually consumes the most of a request?
- In systems that retrieve, the retrieved passages. In systems with many tools, the definitions, which are sent on every turn whether a tool is used or not. In long conversations, the replayed history. Tool results are the least predictable of the four, because their size is set by the tool rather than by the application. Which one dominates is a property of the application and is worth measuring before it is guessed at.
Related entries
Order an assessment for code modification tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.