Context engineering
Last verified: June 2026· definition
As context windows grew and agents got longer-running, the bottleneck stopped being clever instruction phrasing and became information management: what to retrieve, what to summarize, what to keep from earlier turns, what to drop, and what to fetch on demand via tools.
The core insight is that context is a scarce, expensive resource even when the window is large. More context costs more, adds latency, and can actively hurt quality by burying the relevant detail among plausible distractors. Curation beats volume.
In practice it covers retrieval quality and chunking, compaction of long histories, cache-friendly ordering (stable content first, volatile last), context files that give an agent its priors, and tools that let the model pull what it needs instead of being handed everything up front.
More context is not free, even when it fits
A large window makes it possible to include everything, which makes it tempting. But every additional token costs money, adds latency, and competes for the model’s attention. Relevant detail buried among mostly irrelevant material is reliably harder for a model to use than the same detail presented alone. The discipline is deciding what to leave out, and the fact that something fits is not an argument for including it.
Long-running agents run out of room
Any agent working for an extended period accumulates history faster than intuition suggests — every tool call and result stays in the transcript. Eventually it approaches the window limit, and how that is handled determines whether the agent stays coherent. Naive truncation drops the oldest turns first, which is usually where the original instruction lives, so the agent quietly loses its goal and starts re-deriving its task from recent context. Summarising completed work while preserving the objective verbatim avoids this.
Position matters, not just inclusion
Where information sits in the context affects how reliably it is used. Instructions placed far from the point of use compete with everything in between, which is why the same instruction can work in a short prompt and fail in a long one. It is also why prompt caching interacts with this discipline: caches require a stable prefix, so the parts of your context that vary should sit late rather than early.
Tools are a context strategy
Anything an agent can fetch on demand does not need to occupy the window up front. Giving an agent a search tool rather than pre-loading a corpus, or a lookup tool rather than embedding a reference table, trades a possible extra round trip for a much smaller baseline context. This is often the cleanest way to handle information that is large, rarely needed, or changes frequently — and it scales better than trying to anticipate what will be relevant.
Common misconceptions
MythA bigger context window removes the need for retrieval.
RealityIt removes a hard limit, not the cost or the dilution. Retrieving the relevant ten thousand tokens is generally cheaper, faster, and more accurate than including a million and hoping the model finds them.
MythContext engineering is just a new name for prompt engineering.
RealityPrompt engineering is about how instructions are phrased. Context engineering is about what information is present at all, in what order, and what is dropped — which is an information architecture problem rather than a wording one.
MythIf the model missed something, it was not in the context.
RealityIt frequently was, and was crowded out. Verifying that a fact was included is different from verifying it was usable, and the fix is usually removing competing material rather than adding emphasis.
Frequently asked questions
How is context engineering different from prompt engineering?
Prompt engineering optimises the wording of instructions. Context engineering decides what goes into the window at all: which documents to retrieve, how much conversation history to keep, what to summarise, what to drop, and what to fetch on demand through tools instead of including up front. As windows grew and agents ran longer, wording stopped being the constraint and information management became it.
What should I do when an agent runs out of context?
Summarise rather than truncate, and protect the original objective. Compacting completed work into a short summary preserves what was learned while freeing space, and keeping the initial instruction verbatim stops the agent losing track of what it was asked to do. Plain truncation drops the oldest content first, which is exactly the content you most want to keep.
Does prompt caching change how I structure context?
Yes, meaningfully. Caching works on a stable prefix, so anything that varies between requests should sit after the parts that do not. Putting a timestamp, session identifier, or user-specific detail near the start of a prompt defeats caching entirely for every subsequent call, which is a common and expensive accident.