Context engineering replaced prompt engineering

The phrase "prompt engineering" described a real skill for about two years: finding the wording that got a model to do the thing. Most of that skill has been absorbed into the models themselves. Current frontier models do not need to be told to think step by step, do not need role-play framing to take a task seriously, and are not meaningfully improved by threatening them.

What replaced it is less quotable and much more consequential. In an agent, the prompt is not something you write — it is something your system assembles, fresh, on every turn, out of instructions, tool definitions, retrieved documents, conversation history, tool results and whatever state you're carrying. Deciding what goes in that assembly is context engineering, and it's now where most of the quality difference between two agents on the same model comes from.

The window is a budget, not a container

A large context window invites a lazy strategy: put everything in, let the model sort it out. This fails in three separate ways, and they compound.

Attention is not uniform. Material at the start and end of a long context is used more reliably than material buried in the middle. This has improved considerably but has not gone away. If the critical constraint is on line 4,000 of a 12,000-line dump, expect it to be missed some fraction of the time — and a fraction is enough to matter in an agent that takes fifty turns.

Irrelevant content is not free. It costs money and latency, and it actively degrades quality: the more plausible-but-wrong material sitting in the window, the more chances the model has to anchor on it. Six retrieved documents where two are relevant is often worse than the two alone.

Everything you add competes. A system prompt with forty rules does not enforce forty rules. Somewhere past a dozen, the rules start trading off against each other, and the ones that lose tend to be the ones stated most politely.

Order carries meaning

Position within the window is a design decision. A layout that holds up:

┌─ system: role, hard constraints, output contract  ← stable, cached
├─ tool definitions                                ← stable, cached
├─ long-lived reference material                   ← stable, cached
├─ conversation history                            ← grows
├─ retrieved / just-fetched material               ← volatile
└─ the current request                             ← last, most attended

The ordering is driven by two forces pulling the same way. Recency helps: the model attends most reliably to what's nearest the end, so the immediate task goes last. And caching demands it: prompt caching works on a prefix match, so anything that changes between turns must sit after everything that doesn't. Insert a timestamp into your system prompt and you have just disabled caching for the entire conversation. This happens more often than you'd think, and the symptom is a bill that doesn't match the design.

Retrieval is a precision problem now

When windows were small, retrieval was about fitting: get the most relevant chunks in, because only a few fit. Now that a hundred chunks fit, the discipline has to come from somewhere else, and top-k with a fixed k is the wrong instrument — it returns exactly k results whether five are relevant or none are.

What works better in practice:

• Threshold on relevance, not on count. Return what clears the bar. Returning nothing is a valid, useful answer, and an agent told "no matching documents" behaves far better than one handed five irrelevant ones.
• Let the agent search rather than pre-loading. Giving a coding agent a grep tool consistently beats embedding the repository and stuffing the top twenty chunks in. The agent knows what it's looking for after turn three; your retrieval pipeline only knew what the user typed at turn one.
• Give it identifiers, not just content. Chunks with file paths and line numbers can be re-fetched at full fidelity. Chunks without them are a dead end the moment the agent needs more.

Compaction is a first-class feature

Any agent that runs long enough will hit the limit. The question is only whether you handled it or the API did. Covered in more detail here, but the context-side point is this: a compaction summary is not a recap for a reader. It is a state handover. It should preserve the goal verbatim, the constraints verbatim, what has been tried and ruled out, the identifiers currently in play, and the immediate next step. Prose quality is irrelevant; recoverability is everything.

A useful test: take a compacted context, hand it to a fresh session, and see whether it can continue without asking a question a human would find obvious. Most first attempts fail this, and the failure is always the same — the summary kept the narrative and dropped the specifics.

What to do on Monday

• Print your assembled context for one real turn and read all of it. Almost everyone finds something surprising: a duplicated block, a stale instruction, a tool description contradicting the system prompt.
• Check your cache hit rate. If it's low, find what's mutating early in the prefix.
• Count the rules in your system prompt. If it's over a dozen, decide which three actually matter and demote the rest — or move them into the tool descriptions where they're read at the point of use.
• Try deleting your retrieval step and giving the agent a search tool instead. Measure. It is not always better, but it is better more often than people expect.

None of this is glamorous, and none of it produces a screenshot worth posting. It is, reliably, where the wins are.