Context engineering is the job
Prompt engineering was a phase. What actually determines whether your agent works in production is what you put in the window, in what order, and what you leave out.
Most teams shipping agents in 2026 have stopped tuning prompts. Not because prompting stopped mattering, but because it stopped being the bottleneck. The bottleneck moved to a harder question: given a finite context window and an unbounded corpus, what earns its place in the window?
That question is context engineering, and it is now the majority of the work.
The shift in one comparison
Prompt engineering asks how to phrase the instruction. Context engineering asks what the model should be looking at when it reads that instruction.
| Prompt engineering | Context engineering | |
|---|---|---|
| Unit of work | The instruction string | The whole window |
| Failure mode | Model misunderstands the task | Model has the wrong facts |
| Fix | Rewrite the wording | Change retrieval, ordering, compression |
| Scales with | Number of tasks | Size of the corpus |
The second column is where production systems live. A perfectly phrased prompt over the wrong five documents loses to a mediocre prompt over the right two, every time.
Three failures that look like model problems
When an agent underperforms, the instinct is to reach for a bigger model. In practice most of these are context failures wearing a model-shaped costume.
Lost in the middle. Attention is not uniform across position. Facts buried at 60% depth in a long window get recalled measurably worse than the same facts at the start or end. If your retrieval concatenates twenty chunks and the answer is in chunk eleven, you have built a system that fails for reasons unrelated to reasoning ability.
Distractor poisoning. Retrieving ten chunks where three are relevant is often worse than retrieving three. The seven near-misses are semantically similar enough to be plausible and wrong, and the model has no signal telling it which is which.
Stale state in long loops. An agent on turn forty is reasoning over a window containing its own turn-three conclusions, which may have been invalidated by turn twelve. Without explicit state compaction, the agent argues with a previous version of itself.
What actually helps
The interventions that move the needle are unglamorous:
- Retrieve less, rank harder. A reranker over five candidates beats raw vector search over fifty. The cost is one extra model call; the gain is not shipping distractors.
- Put the decisive content at the edges. Task instruction at the top, retrieved evidence at the bottom, nearest the generation point.
- Compact aggressively in loops. Summarize resolved sub-goals into a state block and drop the raw transcript. The agent needs conclusions, not history.
- Measure recall at position. Build an eval that plants a fact at varying depths and checks retrieval. If your system degrades at depth, no prompt fixes it.
The window is a budget, not a bucket. Every token you spend on a marginal document is a token unavailable to reasoning.
Where this goes
As windows grow, the temptation is to stop curating and simply put everything in. That gets the causality backwards. Larger windows raise the ceiling on what a well-engineered context can achieve; they do not lower the cost of a badly engineered one. A two-million token window filled indiscriminately is a more expensive way to be wrong.
The teams that will be shipping reliable agents in two years are the ones treating context assembly as a first-class engineering surface right now — versioned, tested, and measured like any other part of the system.