Curating the whole set of tokens a model sees at inference — instructions, tools, references, memory, retrieved data — not just the wording of one prompt.
Last verified · 2026-07-26 · by Moe Ameen
Context engineering is the practice of curating and maintaining the optimal set of tokens a language model sees during inference — and keeping that set optimal as a task runs. It is broader than the prompt. The context a model reasons over includes the system prompt and the user message, but also the tool definitions you expose, the files and references you pull in, the data a retrieval step injects, and the memory carried between turns. Where prompt engineering asks "how should I phrase this instruction?", context engineering asks the larger question: "what configuration of context is most likely to produce the behavior I want?"
Anthropic describes context engineering as the natural progression of prompt engineering. After a few years in which the field obsessed over finding the right words for a prompt, the harder and more valuable problem turned out to be assembling and pruning the entire context — of which the prompt is one component. Prompt engineering still lives inside it; you still write clean instructions and clear tool descriptions. But for any system more complex than a single-turn chatbot, the prompt is one input into a pipeline, and the pipeline is the thing you are really engineering: what belongs in the window this turn, what should load only when needed, what should be a tool the model calls rather than text it reads, and what to leave out entirely.
The discipline came into sharp focus with the Claude 5 generation of models in 2026. Anthropic reported deleting more than 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on its coding evaluations — because much of that text had been guardrails written to stop failure modes of older, weaker models that the newer ones no longer produce. The lesson reframed the whole field: on a capable model, context engineering is often a subtraction discipline. The winning move is frequently to remove context — conflicting rules, redundant instructions, prose that restates what a reference already says — rather than to add it. Capacity is not attention: a model reasons best over a focused, high-signal context, so stuffing a large window with everything you have degrades output rather than improving it.
The term rose to prominence through 2025 and into 2026 as building with language models shifted from single-turn chatbots to multi-step agents that call tools and carry state. As long as an interaction was one prompt and one reply, "prompt engineering" captured the whole job. Once systems started running loops — pulling in files, calling tools, retrieving documents, and remembering across turns — practitioners needed a word for the larger task of managing everything that lands in the model's context, and "context engineering" is the one that stuck. Anthropic and others framed it explicitly as the successor to, and superset of, prompt engineering. The Claude 5 generation gave the concept its landmark example: in a July 2026 write-up on the new rules of context engineering, Anthropic showed that removing the bulk of a carefully accumulated system prompt improved rather than hurt a highly capable model — using "unhobbling" (a term coined by Leopold Aschenbrenner in 2024) for the pattern of getting better results by taking constraints away. That result turned context engineering from a niche practitioner phrase into the default way experienced teams talk about building with frontier models.
| Platform | Behavior |
|---|---|
| System prompt / instructions | The always-on context: what the product is and what the model is doing. Context engineering keeps this small and principle-based — a rule that scales ("match the surrounding code's comment density") over an enumerated list of prohibitions, which tends to conflict and to be wrong in edge cases. |
| Tools | Tool definitions are context. Well-designed, expressively-named parameters with enumerations and constraints teach correct usage better than pasted examples — and deferred-loading means a tool's full definition arrives only when the model actually needs it, keeping the working context lean. |
| Retrieval / RAG | Injecting only the documents relevant to the current query is a core context-engineering technique. The goal is precision, not volume: retrieving fewer, more relevant chunks beats flooding the window, because irrelevant retrieved text dilutes the signal the model attends to. |
| Memory | What persists across turns. The shift on capable models is from hand-maintained memory files the model re-reads every turn toward auto-memory the model manages itself, so the persistent context stays a lightweight orientation rather than a growing database. |
| References | Point the model at the real artifact instead of describing it. A code file, an HTML mockup, or an entire codebase brought in by reference is higher-fidelity and lower-effort than a prose spec that tries — and loses information trying — to summarize it. |
The most useful reframe is that context engineering has escaped the terminal. It sounds like a developer discipline — system prompts, tool schemas, retrieval pipelines — and at the frontier it is. But the underlying idea, curate the context a model reasons over and reuse the good configuration instead of re-deriving it every time, is exactly what a well-built content product does on your behalf. Kompozy is a clean example: its Persona Brief is context engineering expressed as a UI. You define voice, angle, banned words, and reference assets once, and that curated context is what every generation reasons against — across shorts, carousels, blogs, and newsletters — rather than you re-explaining your brand in a fresh chat each time. The banned-word filters and quality gates are the verification layer at the output boundary, not constraints smeared through a prompt. The Claude 5 lesson applies here too: the win is a tight, high-signal brief, not a sprawling one. The people who will benefit most from understanding context engineering are not only the ones writing prompts — they are the ones choosing tools, because the good tools are already doing it for them.
Context engineering is the practice of curating the entire set of tokens a model sees at inference — the system prompt, tool definitions, references, retrieved data, and memory — and keeping that set optimal as a task runs. It asks "what configuration of context produces the behavior I want?" rather than only "how do I phrase this prompt?" It treats the prompt as one input into a larger context pipeline that you engineer as a whole.
Prompt engineering is a writing task — finding the right words and structure for an instruction. Context engineering is a systems task — deciding what belongs in the context this turn, what should load only when needed, what should be a tool the model calls, and what to leave out. Anthropic frames context engineering as the natural progression of prompt engineering: prompt engineering is one part of it, but for anything beyond a single-turn chatbot the surrounding context matters as much as the wording.
Because the Claude 5 generation made "remove context" the right answer far more often. Anthropic reported deleting over 80% of Claude Code's system prompt for Claude Opus 5 and Claude Fable 5 with no measurable loss on coding evals — most of it was guardrails for failures older models made and newer ones do not. That result reframed context engineering as often a subtraction discipline: curate toward a smaller, higher-signal context rather than accumulating rules.
No. A large window is capacity, not attention. A model still reasons best over a focused, relevant context, and filling the window with everything you have degrades output through dilution. Bigger windows and more capable models raise the payoff of curating context well — they do not remove the need to. The common mistake is treating a million-token window as a reason to stop pruning.
Yes. Deciding what to retrieve and inject into the context — and, crucially, what not to — is a core context-engineering technique. The goal is precision: returning the few passages actually relevant to the query beats flooding the window with loosely-related documents, because irrelevant retrieved text dilutes the signal the model attends to and can pull it off the correct answer.