
What Is Context Engineering?
Context engineering is the discipline of controlling everything an AI model sees at inference time: which files, documents, conversation history, instructions, and tool results enter the context window, in what form, and in what order. Where prompt engineering shapes a single instruction, context engineering manages the model's entire field of view across a long-running task.
Key Takeaways
- Model output quality is mostly a function of input quality. The majority of agent failures in practice are context failures: the right information was missing, buried, or stale.
- The context window is a budget, and every token competes. The job is curation under a constraint, deciding what earns a place and what gets summarized or dropped.
- More context is a cost, not a free upgrade. Irrelevant material degrades accuracy and attention as well as increasing spend, a failure pattern known as context rot.
- In agentic systems this discipline is where the leverage lives, which is why instruction files, retrieval design, compaction, and subagent boundaries are the load-bearing decisions.
How It Works
Everything a model knows about your task arrives through one channel: the tokens in its context at inference time. The model has training knowledge, but nothing about your codebase, your ticket, or the last hour of work unless those tokens are present. Context engineering is the design of that channel, and it decomposes into three recurring problems. Selection: of everything available, what does this step of the task actually need? Compression: for material that matters but is large, what survives, full text, a summary, or just a pointer the model can follow later? Ordering and framing: where does each piece sit, and how is it labeled so instructions, reference material, and untrusted data stay distinguishable?
In agentic workflows these decisions show up as concrete machinery. An AI coding agent does not receive the repository; it receives search results, the files it chose to open, and the output of commands it ran, which means the tools and their descriptions are themselves context-engineering surfaces. Instruction files like AGENTS.md inject durable project knowledge, conventions, commands, and boundaries at session start so it never has to be rediscovered. Retrieval-augmented generation pulls relevant documents in on demand rather than resident in every request. On long tasks, compaction summarizes older history to reclaim budget, and agent memory persists what should outlive the session. When one window cannot hold a problem, orchestration splits it: subagents work in fresh windows and return conclusions instead of transcripts, which is context engineering applied at the architecture level.
The through-line is that all of this is engineering in the ordinary sense. There are budgets, trade-offs, failure modes, and measurable outcomes, and teams that treat the context as a designed artifact get categorically better agent behavior than teams that concatenate everything and hope. The stakes are quantifiable: in Anthropic's 2025 BrowseComp evaluation of its multi-agent research system, token usage by itself explained 80% of the variance in performance [1].
Example
An agent keeps producing wrong fixes in a large monorepo: plausible patches referencing modules that do not exist, conventions from the wrong service. The team's instinct is to blame the model, but the transcript shows the real problem, a context stuffed with an enormous generic instruction file, three stale architecture docs, and whole-file dumps from earlier steps, with the actually relevant service conventions nowhere present. They rebuild the context pipeline: a trimmed root instruction file, per-service convention files loaded only when the agent touches that service, retrieval that returns the ten most relevant code chunks instead of entire files, and compaction after every subtask. Same model, same prompts, and the hallucinated-module problem largely disappears. Nothing about the model changed; its field of view did.
What People Get Wrong
The intuition that fails hardest is "when in doubt, include it." Large context windows make dumping everything possible, so teams ship agents whose every request carries the full instruction file, an entire wiki export, and thousands of lines of open files. The result is worse, not safer. Attention over very long inputs is imperfect, so critical details get lost among the filler; near-relevant but wrong material, an outdated doc, a similar function from another service, actively pulls the model toward wrong answers; and every wasted token is paid for on every call. Chroma's 2025 technical report on context rot evaluated 18 models, including GPT-4.1, Claude 4, and Gemini 2.5, and found all of them become less reliable as input length grows, even on simple tasks [2]. Relevance beats volume. The discipline is called engineering precisely because it means making choices, and refusing to choose is itself a choice with the worst properties.
FAQ
Is context engineering replacing prompt engineering? It absorbed it. Prompt engineering survives as the craft of writing one component well, the instruction, the tool description, the template. Context engineering is the system-level discipline those components live inside, and in agentic work the system-level decisions dominate outcomes.
Why did context engineering emerge as its own discipline? Because agents made the input problem dynamic. A chat prompt is composed once by a human; an agent's context is reassembled at every step from tool results, files, and history, over tasks that run for hours. The volumes are different too: Anthropic found in 2025 that agents typically use about 4x more tokens than chat interactions, and multi-agent systems about 15x more [3]. Managing that stream well turned out to be where most of the difficulty and most of the leverage in agent building actually sits.
What are the basic techniques to start with? Keep instruction files short and true, retrieve narrowly instead of dumping files, summarize or drop stale history on long tasks, isolate big subproblems into subagents with fresh windows, and read your agent's actual assembled context regularly. The last one is the highest-value habit: most context failures are obvious the moment a human finally looks.
Sources
- Anthropic Engineering. "Token usage explained 80% of performance variance in the BrowseComp evaluation of Anthropic's multi-agent research system." https://www.anthropic.com/engineering/multi-agent-research-system. Accessed August 2026.
- Chroma Research. "Context rot report: 18 LLMs become increasingly unreliable as input context length grows." https://www.trychroma.com/research/context-rot. Accessed August 2026.
- Anthropic Engineering. "Agents use about 4x more tokens than chat interactions; multi-agent systems about 15x more." https://www.anthropic.com/engineering/multi-agent-research-system. Accessed August 2026.
Related terms
Related Topics
Ready to build your product?

