Context Engineering Replaced Prompt Engineering

Pull-quote: “Prompt engineering asked how to phrase the request. Context engineering asks what the model should be allowed to see.”

Why this matters

Prompt engineering was a real skill for about eighteen months. Then the systems got bigger than the prompt. In an agentic application, the words a developer wrote by hand are a small fraction of what the model actually receives: retrieved documents, conversation memory, tool results, schemas, and policy all compete for the same window. The discipline that matters now is deciding what enters that window, in what order, at what cost, and with what evidence that it helps. That discipline is context engineering, and it behaves less like copywriting and more like resource management.

The window is a budget

Treat the context window as a budgeted resource with named line items, because that is what it is:

Two consequences follow. First, the system prompt is policy, not prose: it defines what the agent may do, how it must format output, and what it must refuse, and it deserves version control and review like any other policy artifact. Second, everything variable needs an eviction strategy. History that accumulates without compaction eventually crowds out the evidence that would have answered the question.

Position matters

Long-context models do not attend uniformly. Content in the middle of a long window is recalled less reliably than content near the beginning or end, the well-documented “lost in the middle” effect. Engineer for it:

   Window layout (top ──► bottom)
   ───────────────────────────────
   System prompt / policy          ◄── strong position: rules live here
   Tool definitions
   Compacted memory summary
   Retrieved evidence (ranked)     ◄── weakest positions: middle
   ...
   Highest-relevance evidence      ◄── strong position: near the query
   Current request                 ◄── last thing the model reads

Rank retrieved evidence so the most relevant chunks sit closest to the request, not scattered by arrival order. And resist the temptation to fill the window because it is there: adding marginal chunks past the point of relevance measurably degrades answers by burying the material that matters.

Measuring context quality

Context engineering is only engineering if it is measured. Three practices carry most of the weight:

1. Score the window, not just the answer. Track retrieval precision against labeled relevant documents. A wrong answer over the right context is a model problem; a wrong answer over the wrong context is your problem.
2. Ablate by source. Remove one line item at a time (memory, retrieval, a tool result) and re-run the eval set. Sources that do not move accuracy are spending budget for nothing.
3. Version the whole assembly. The system prompt, the retrieval configuration, the compaction policy: a change to any of them is a release, with a regression suite behind it.

Closing

The prompt was never the system; it was the visible corner of one. Context engineering names the actual job: assemble the smallest window that contains the policy, the evidence, and the question, in the order the model attends to best, and measure that each component earns its tokens. Teams that treat the window as a budget ship agents that get better on purpose. Teams that treat it as a text box ship agents that got lucky.