Context engineering is the practice of managing what a model sees on each inference call, the instructions, retrieved documents, prior steps, tool definitions, and memory, so an agent stays reliable as a task runs long. It is broader than writing a single good prompt, because the context now changes turn by turn, and it treats the context window as a finite budget to fill deliberately rather than cram full.
In plain language
A language model has no memory of its own. Each time you call it, the only thing it knows is the text you hand it on that call, and that text has to fit inside a fixed size called the context window. For a single question, filling the window is easy, you write a good prompt and you are done. That is prompt engineering, the craft of wording one request well.
An agent is different. It runs for many steps, calling tools, reading results, and deciding what to do next, and at every step someone has to assemble the text the model sees. That text keeps changing. It grows as the agent works, because each tool result and each earlier decision could be added to it. Left unmanaged, it fills up with old detail the model no longer needs, and two bad things happen. The window runs out of room, and the important instructions get lost in the noise, so the model starts to drift or repeat itself. Context engineering is the work of preventing that.
The core idea is that the context window is a budget, not a bucket. More text is not better. A model has a limited amount of attention to spread across whatever it is given, so padding the window with everything you have makes its answers worse, not more informed. The job is to put in what matters now and keep the rest somewhere else.
In practice the work falls into a few moves. You write things down outside the window, a running note or a file the agent can re-read, so nothing important depends on staying in the window. You select only the pieces relevant to the current step and pull them in when needed rather than holding everything at once. You compress long histories into short summaries so a hundred earlier turns become a few sentences. And you isolate sub-tasks, giving a helper its own clean context instead of dragging the whole conversation along. Those moves are what turn a model that works for one question into an agent that stays reliable over a long job.
An everyday picture
Think of the context window as the desk of someone doing focused work, and context engineering as keeping that desk usable. The desk has a fixed size. Pile every document you own onto it and you cannot find the one page that matters, so the work slows and mistakes creep in. A good worker keeps only the current task's papers on the desk, files the rest in a cabinet within reach, and writes a short note of where things stand before switching tasks, so nothing lives only in their head. Prompt engineering is like writing one clear instruction on a sticky note. Context engineering is running the whole desk over hours of work, deciding moment to moment what belongs on it, what goes back in the cabinet, and what gets summarised on a fresh index card. The model supplies the thinking, but a cluttered desk defeats even a sharp mind, and a well-kept one lets it stay sharp all day.
Where it shows up
Context engineering shows up wherever a model runs for more than a single turn. Coding agents are the clearest case, where the model has to hold the relevant files, the error output, and the plan without dragging an entire repository into the window, so tools fetch just the files a step needs and summarise the rest. Customer support and research assistants use it to carry the thread of a long conversation, compressing earlier turns into a running summary so the model remembers the gist without re-reading every message. A retrieval-augmented generation system is context engineering applied to documents, selecting the few passages relevant to the question rather than pasting a whole knowledge base. Long-running and managed agents depend on it most, because a task that spans minutes or hours will overflow any window unless state is written down outside it and pulled back in as needed. It sits close to memory, to RAG, to the agent's harness that assembles each turn, and to orchestration when several agents each need their own clean context. The common thread is any system where what the model should see changes step by step and has to be decided, not just dumped in.
A small example
Anthropic's engineering guidance, published under the title Effective context engineering for AI agents, is a clear read against this definition. It frames context as a finite resource with diminishing returns, an attention budget that depletes as more tokens are added, and it pairs that framing with concrete platform primitives, context editing that trims stale content out of the window and a memory tool that lets an agent store notes in files outside the window and re-read them when needed. Anthropic reports meaningful gains from this approach in its own evaluations, with context editing and a memory tool together lifting results on a long-running task and cutting token use sharply over many turns. Read against the definition, each piece is one of the moves the discipline describes, keeping the window lean, writing state down outside it, and pulling detail back in only when a step calls for it. The specific numbers, limits, and settings sit in Anthropic's own documentation; the shape is the point here, treating what the model sees as something to engineer, not just something to fill. The same pattern shows up across the field in 2026, in guidance from LangChain, Sourcegraph, and others, as the successor discipline to prompt engineering for anyone building agents rather than one-shot prompts.
Common misunderstanding
One line to take with you
Context engineering is the discipline of deciding what a model sees on each call and managing it as a task runs long, treating the context window as a finite budget to fill on purpose rather than a bucket to cram. The core moves are to write state down outside the window, select only what the current step needs, compress long histories into summaries, and isolate sub-tasks with their own clean context. It is broader than prompt engineering, which is one call's wording, and it is not solved by a bigger window, because attention stays finite. Reach for it whenever you build an agent rather than a one-shot prompt, because on a long task the difference between reliable and confused is usually not the model, it is what you chose to put in front of it.
Frequently asked
Prompt engineering is the craft of wording a single request so a model does what you want on that one call. Context engineering is the broader work of managing everything the model sees across many calls as a task unfolds, the instructions, retrieved documents, tool results, the record of earlier steps, and stored memory. The prompt is one item in that set. The difference matters most for agents, which run for many steps rather than answering once. For a single question, a good prompt is often all you need. For an agent that works for minutes or hours, the harder problem is assembling the right context at every step, keeping the window focused, and moving detail in and out as the task changes. In that sense context engineering is often described as the discipline that grew out of prompt engineering once systems stopped being one-shot and started being agents.
Yes, because a bigger window does not fix the underlying problem. A model has a finite amount of attention to spread across whatever it is given, and that budget does not scale up just because the window does. Fill a very large window with everything you have and the model still loses track of the important parts, its answers get less precise, each call costs more, and responses slow down. Larger windows raise the ceiling on how much can fit, but they do not decide what should fit, and putting in more low-value text often makes results worse rather than better. The core skill, choosing what belongs in front of the model right now and keeping the rest outside, stays necessary no matter how large the window grows. If anything a bigger window makes the discipline more valuable, because it makes overfilling easier to do by accident.
Most practical approaches come down to four moves. The first is to write state down outside the context window, a running note, a scratchpad, or a file the agent can re-read, so important information does not depend on staying in the window. The second is to select only what the current step needs and pull it in when needed, rather than holding the entire history at once, which is the same idea retrieval-augmented generation uses for documents. The third is to compress long histories into short summaries, so a hundred earlier turns become a few sentences the model can still act on. The fourth is to isolate sub-tasks, giving a helper agent its own clean context instead of dragging the whole conversation along. These are not a fixed recipe, and the right mix depends on the task, but together they describe how a system keeps the window focused while a job runs long. Platform features increasingly support them directly, such as tools that trim stale content or store memory outside the window, but the underlying decisions about what to keep, drop, or summarise remain the engineer's.