Context engineering: the discipline that replaced prompt engineering

The shift, and why it happened

The discipline changed because the artefact changed. A single-shot classification prompt is something you write by hand and tune word by word — prompt engineering, done. But an agent on its tenth turn is looking at a context nobody wrote: an assembled document of prior actions, tool results, retrieved passages and a system prompt, most of it generated at runtime. You cannot word-tune a document you did not author. You can only decide what goes into it.

This is not a claim that prompt engineering is obsolete — the instructions still have to be good. It is a claim that for any agentic system, instruction wording is now a small part of a larger problem, and the larger problem has different rules.

The window is a budget, not a container

The reframe matters because “we have a million-token window” invites the wrong instinct — fill it. But every token is paid for on every request, and, as the degradation section below shows, marginal tokens canlower quality. A large window is permission to include what matters, not an obligation to include everything.

Why prefix stability is money, not tidiness

This is the mechanism that turns a style guideline into a cost model, and it is the single most valuable thing to understand in this article. “Don’t put a timestamp in the system prompt” is not advice about cleanliness. It is advice about a recurring charge.

# ✗ Volatile-first. The timestamp changes every request, so the ENTIRE
#   prompt after it is recomputed every time. Cache hit rate: ~0%.
system:
  Current time: 2026-07-30T14:32:07Z     ← changes every request
  [8,000 tokens of stable instructions]  ← recomputed every request anyway

# ✓ Stable-first. The instructions are byte-identical across requests, so
#   they are served from cache. Volatile content moves after the breakpoint.
system:
  [8,000 tokens of stable instructions]  ← cached after the first request
messages:
  [conversation, with the timestamp injected HERE if needed]

The diagnostic is equally concrete: the usage figures on every response report cached versus uncached input tokens. If your cache-read count is zero across requests that look identical, something in the prefix is changing — a timestamp, a session ID, a non-deterministically serialised object, a tool list that varies by user. Find it and move it after the stable prefix.

For the placement rules in full, and the economics of the different cache tiers, the mechanics are the same ones that govern why semantic caching rarely fires inside an agent loop — prefix stability is the thread connecting both.

The four consumers of the window

The order of attention should follow cost times variability, not size alone. History and retrieval are where the waste is, because they grow and because their usefulness is uneven — a retrieved passage that turned out to be irrelevant cost the same as one that answered the question.

Retrieval is the hard part, and it is upstream

Two failure modes bracket the retrieval decision. Over-retrieval fills the window with marginally-relevant passages that dilute attention and inflate cost. Under-retrieval starves the model of the fact it needed. The window between them is narrower than it looks, and it moves per task.

The deeper point is that retrieval quality is decided before retrieval runs. If your chunks break mid-argument or strip their heading context, the embeddings represent nothing precisely and no retrieval strategy recovers a good answer from them. That is why teams who “fix retrieval” by changing the vector store are usually disappointed — the problem was upstream, in the splitting, as developed in choosing the data layer.

Retrieve on demand, not upfront

The context-engineering move that most reduces both cost and noise is to give the agent retrieval as a tool rather than pre-loading documents into the window. Pre-loading pays for everything on every turn whether or not it is used; a retrieval tool pays only when the agent decides it needs something, and puts only that in the window. The tradeoff is a round trip, which is usually worth it.

Long context degrades — plan for it

This is the finding that most contradicts intuition and most changes design. The instinct behind a large window is “include more, get better answers”. The reality is a curve that rises, plateaus, and then falls as the genuinely relevant content is drowned by the merely plausible.

The practical instructions that follow: put what matters at the edges, not the middle; prefer a short curated context to a long comprehensive one; and when a critical fact must be present, place it near the question rather than trusting the model to find it three thousand tokens back. A long context is a place to lose information, not a place to store it safely.

Compaction and clearing

The three compose into the right shape for a long-running agent: clear what is definitely finished, compact what is probably finished, and rely on retrieval to recover the specific fact that turns out to matter after all. Designing that flow — what to keep verbatim, what to summarise, what to evict and re-fetch — is context engineering at its most concrete.

One handling detail worth stating because it silently breaks things: compaction returns a block the model needs on subsequent turns, so the full response content must be preserved and passed back, not just the extracted text. Dropping it loses the compaction state and the window rebuilds from scratch.

The discipline, in one page

The reason this replaced prompt engineering as the load-bearing skill is simple: for a single prompt, the words are almost everything. For an agent, the words are a small, stable header on a large, dynamic document — and the document is where the cost lives, where the quality is won or lost, and where the actual engineering is. The instructions still matter. They are just no longer the hard part.

Where this sits relative to everything else an agent needs — and why the context layer is one of seven — is laid out in the seven-layer stack.