Context engineering.
The single biggest lever on whether an agent works is not the model you picked or how cleverly you worded the prompt — it is what you decide to put in the context window on each step, and what you deliberately leave out. This entry defines context engineering, separates it from prompt engineering, names the failure it exists to prevent, and gives you the concrete levers you actually pull.
Prompt engineering words one message; context engineering curates the whole window.
Prompt engineering is the craft of phrasing a single instruction well — clear task, good examples, the right output shape. It still matters. But an agent does not run one prompt; it runs a loop, and on every turn the model sees a whole assembled payload: the system prompt, the running instructions, retrieved documents, memory pulled from an external store, the results of previous tool calls, the conversation history, few-shot examples, and the current task. Context engineering is the discipline of deciding what goes into that payload, in what form, at which step.
The context window is a finite, shared budget. Context engineering is the editorial job of spending it well: you are not writing one message, you are curating everything the model reads before it acts. As the framing that displaced "prompt engineering" for agent builders through 2025, it reflects a simple observation — once a system has memory, tools, and retrieval, the wording of any one instruction is a small part of what determines the output.
A useful image: the window is a desk. Prompt engineering writes a clear note and sets it on the desk. Context engineering decides which reference books, tool printouts, and sticky-notes are on the desk at all — and clears the ones that are no longer needed so the model can find the note.
The failure it prevents: more context is not better context.
The naive instinct is to stuff everything possibly relevant into the window "just in case." This backfires. Long contexts degrade in a measurable way often called context rot or lost in the middle: as the window fills, the model attends less reliably to any given token, and material buried in the middle of a long payload gets effectively ignored. Irrelevant, stale, or contradictory context does not sit there harmlessly — it distracts the model, dilutes the signal, invites it to act on outdated facts, and costs you tokens and latency on every single turn.
- Distraction. Ten loosely-related documents make the one relevant sentence harder to use than a single well-chosen snippet.
- Staleness. A tool result from twelve steps ago may now be wrong; leaving it in the window invites the model to trust it.
- Cost and latency. Every token in the window is re-processed on every turn of the loop — a bloated context is a recurring tax, not a one-time one.
The goal is therefore not the most context but the right context: the smallest set of high-signal tokens that lets the model take the next correct action.
The levers you actually pull.
Context engineering is a handful of concrete techniques for getting the right tokens in and the wrong tokens out:
- Retrieve, don't preload. Instead of pasting a knowledge base into the prompt, fetch only what this step needs with retrieval (RAG). The window holds the query result, not the corpus.
- Compact the history. When the conversation or tool-call log grows, summarize the old turns into a compact note and drop the raw transcript. The agent keeps the gist, not every byte.
- Offload to memory. Push durable state — decisions, user facts, task progress — into an external memory store and read it back on demand, rather than carrying it in the window for the whole session.
- Isolate sub-tasks. Hand a self-contained sub-problem to a sub-agent with its own clean window, and return only the answer to the main loop — so a noisy sub-task never pollutes the parent's context.
- Trim tool output. A raw API response can be thousands of tokens of which three matter. Post-process tool results down to the fields the model needs before they ever enter the window.
These are not five separate topics — they are five moves in one game. RAG, memory, and history compaction all exist to serve the same objective: keep the window small, current, and relevant.
How this lands in agent design.
Treat context assembly as a first-class, per-step decision, not an afterthought. On each turn ask: what is the minimum this model needs to see to choose the next action correctly? Then build the window to exactly that — pull the relevant memory, retrieve the relevant docs, compact what has gone stale, and leave everything else out.
The uncomfortable part is that the model cannot tell you what it is missing or what is drowning it. It will confidently act on whatever window you hand it. That makes context the window your responsibility, measured the only way anything in this section is reliably measured: with an evaluation set on tasks that look like yours, comparing outcomes as you change what goes in. When you are ready to go deeper, the wiki's context-budgeting, context-compaction, and effective-vs-advertised context deep-dives carry these levers into production detail.