Context Engineering: The Complete 2026 Guide

Context engineering refers to the activity of choosing, shaping, and controlling the context that a language model can see so that it successfully completes the task. This domain encompasses system prompts, available tools, retrieved documents, conversation history, and memory, not only the formulation of prompts.

There have been three companies that have created relevant yet incomplete frameworks for this field. LangChain has introduced four types of agent behavior. Anthropic provided an explanation of the relevance of the field from a technical point of view. Finally, IBM has provided a six-step process. This document brings together the three frameworks into one, provides the origin of the terminology, and creates a checklist, stat block, and trouble-shooting table, which the three documents lack.

What Is Context Engineering?

Context engineering is the carefully considered choice and arrangement of all inputs provided to the large language model for generating a response. Such inputs include the prompt, the message from the user, documents fetched, tool outputs, and previous turns of the conversation. The aim is the exact result – the generation of a true response right at the first try, without making up any facts or forgetting about the task.

This term generalizes two other concepts that relate to its aspects. The concept of prompt engineering considers only the construction of prompts themselves. The retrieval-augmented generation (RAG) approach considers only the integration of documents into the context window.

Three categories of information make up most production context windows:

• Instructions — system prompts, few-shot examples, and tool descriptions.
• Knowledge — retrieved facts, documents, and stored memories.
• Tool outputs — results returned from function calls, searches, or code execution.

Who Coined “Context Engineering”?

The term was coined by Shopify’s CEO Tobi Lütke on X on June 19, 2025. According to him, the use of the word “prompt” belittles a very sophisticated skill as it does not include much more than instructions, which a model executes. Exactly six days later, AI specialist Andrej Karpathy adopted the term. According to him, context engineering means providing exactly the required information into the context window at every point of performing any task.

It took just two more events to firmly establish the term within a quarter. On September 29, 2025, the Applied AI team of Anthropic published a framework of the technology. Research firm Gartner listed context engineering among enterprise AI capabilities in mid-2025 and advised that the technology should be owned by a specific team.

Context Engineering vs. Prompt Engineering vs. RAG

Context Engineering is the more comprehensive field, while prompt engineering and Retrieval-Augmented Generation are some parts of context engineering. Prompt engineering involves crafting instructions that give the best results. RAG involves crafting queries that result in accurate document retrieval.

Dimension	Prompt Engineering	RAG	Context Engineering
Primary focus	Instruction wording	Document retrieval	Full context window design
What it optimizes	System and user prompt text	Relevance of retrieved passages	Instructions, tools, memory, history, and retrieved data together
Typical output	One improved prompt	A ranked list of retrieved passages	A complete, token-budgeted context assembly
Best suited for	One-shot classification or generation tasks	Knowledge-intensive question-answering	Multi-turn agents and long-running tasks
Scope	Narrowest	Narrow	Broadest

Engineered prompts will continue to be essential in context engineering itself, since a properly engineered context window still needs to be accompanied by well-defined instructions for the system prompt. RAG will continue to be one of the main techniques used to populate that context window with outside knowledge.

Why Context Engineering Matters: Context Rot Explained

The higher the number of tokens in the context window, the lower is the accuracy of the models, a phenomenon known as context rot. The July 2025 research by Chroma involving 18 frontier language models, which includes GPT-4.1 and Claude 4, shows that all these models exhibit context rot. A second study done by researchers from Stanford and UC Berkeley in 2023, called “Lost in the Middle,” reveals that models better remember information from the beginning and end of long contexts than information from the middle.

Context rot can be attributed to architecture. In a transformer model, the relationships between every two tokens in the context window are computed. If a context window is of n tokens, then there will be approximately n² such computations. Thus, the more the n, the less attention each token receives. According to Anthropic, this attention capacity can be described as a finite attention budget.

The 4 Ways Context Fails: Poisoning, Distraction, Confusion, Clash

Four documented failure patterns account for most context-related agent errors, a taxonomy first outlined by researcher Drew Breunig in 2025.

Failure mode	Definition	Typical trigger
Context poisoning	A hallucinated or incorrect fact enters the context and is treated as ground truth in later steps	An early model error is never corrected or removed
Context distraction	Critical instructions get buried under accumulated, less relevant context	Long conversation history or verbose tool outputs
Context confusion	Irrelevant information changes the model’s response despite having no bearing on the task	Overloaded system prompts or unfiltered document retrieval
Context clash	Two pieces of context contain contradictory information	Stale memory combined with newly retrieved data

However, a different solution is required for each mode of failure. Poisoning calls for the validation of output before it enters the context. Distraction and Confusion call for the filtering of irrelevant data before it is fed into the model. Clash calls for the timestamping of the context.

The Anatomy of a Context Window

Context window is the largest amount of tokens that a language model is able to process in one request, which consists of the prompt, retrieval results, tool output, and the model’s response itself. Usually, there are six items inside a context window in production:

1. System prompt – The basic set of instructions and rules that defines the function and behavior of the model.
2. User message – The current request or the description of the task.
3. Retrieved Knowledge – Document, passage, or record retrieved from vector databases, document store, or structured data sources.
4. Tool Outputs – The output generated from the tool or function calls, or any external API calls.
5. Message History – Previous turns of conversation, either complete or summarized.
6. Memory – Memory of facts or preferences that are stored independently of the current conversation.

Anthropic suggests that the system prompt should be divided into different segments and labeled appropriately, using XML tags or Markdown headings. Such organization will allow the model to find necessary instructions quicker compared to the same length but unorganized paragraph.

The Core Framework: Write, Select, Compress, Isolate

There are four main strategies used in production context engineering, categorized in a classification introduced by the LangChain team in July 2025. These strategies cover each stage in the execution loop of an agent.

• Write – retain information beyond the context window for future use.
• Select – select certain information from the external world to the context window.
• Compress – decrease the number of tokens in the context without losing the meaning of that context.
• Isolate – divide the context among various contexts.

Write Context

Context writing implies the persistence of information beyond the active context window to enable agents to access them at a later time. There are two approaches that can be used for this strategy.

Scratchpad is a short term storage implemented as either a tool call to write into a file or as a field inside the runtime state of the agent. The use of a scratchpad by an agent involves the storage of plans and intermediary results while performing one particular task.

Memory is the long term storage which survives independent sessions. There are three memory types depending on their functionality: episodic memory stores the examples of the desired actions, procedural memory stores the instructions and semantic memory stores the facts. Coding assistants Cursor and Windsurf implement their own instruction files as procedural memory, and ChatGPT implements user-specific fact bases as semantic memory.

Select Context

Context selection involves retrieving existing information back to the active context window. The process depends on how much information is stored.

In case of small and fixed sets of files such as one instruction file, there is no need for ranking because the agent loads the whole file. In case of large numbers of memories and documents, ranking is necessary prior to the retrieval process. Two ranking strategies dominate in production systems: semantic search based on embeddings and knowledge graph search.

The same logic applies to the process of tool selection. Retrieval of the tool description by filtering the available tool list to obtain only those tools useful for the task can increase accuracy. It was demonstrated in one study that accuracy increased by three times when compared to exposing the whole tool list.

Compress Context

Context compression entails minimizing the number of tokens but maintaining the amount of information necessary for the task. There are two ways through which this compression is achieved.

The first method entails using the model to compress a long history into a compressed version. The Claude code developed by Anthropic automatically summarizes a conversation after it is 95% full, keeping architectural details and open problems while eliminating raw tool outputs.

The second method involves removal of messages based on some set criteria without involving any judgment from the model – an example being elimination of messages that are older than a specified number of turns.

Isolate Context

Context isolation is the process of distributing a problem among several agents that each have their own context window. There are two approaches prevalent in industry practice.

One approach involves using a multi-agent architecture wherein each sub-agent has its own narrow scope of responsibility, set of tools, and context window. The multi-agent system used for research purposes at Anthropic reported that context isolation across sub-agents explained 80% of the variation in its internal BrowseComp test results – far more than the type of model or number of tool invocations.

Another approach to context isolation involves creating a sandboxed environment for code execution. It involves keeping large objects, such as images and datasets, out of the model’s context and returning only variable references to the model.

Managing Context in Long-Running Agents

Activities that span tens of minutes to several hours, for example, codebase migration, will need more than the four levers. Anthropic has discovered three more levers that can be used for long-horizon tasks.

In compaction, an interaction which is nearing the end of the context window is summarized, and a new context window is initiated using this summary plus the most recently accessed files. The difference between compaction and normal compression is that in compaction, there is a combination of summarization and context refreshment, unlike in compression.

Structured note-taking involves keeping a copy of the agent’s work outside of the context window in an external file on a regular basis. An example of structured note-taking is shown in Anthropic’s Claude playing Pokémon system. In this case, the agent keeps track of step count and goals through thousands of steps and then after every context refreshment, it reads the notes.

Finally, retrieval timing is another lever. Pre-retrieving all the necessary files for the task before the task is started makes things quicker. On the other hand, retrieval on-the-go as and when the agent realizes that it requires certain information is faster in terms of tokens consumed and allows the agent to use the name, size, and timestamps as signals of which files to read.

The 6-Step Context Engineering Process

Creation of a context engineering pipeline involves following six steps in sequence.

1. Select context. Filter out all the information that is available to only include information needed for the task at hand. Eliminate unnecessary information before it reaches the context window.
2. Structure context. Structure the chosen information into some consistent format like Markdown headings or JSON. Make sure to distinguish between instructions and data.
3. Design the prompt. Design the prompt with the instruction, constraints, and desired output format. Provide examples where the output has to be formatted precisely.
4. Compress Context. Perform summarization or deduplication so that more relevant information fits into the available token limit.
5. Sequence Context. Arrange the instruction/rule at the top, followed by the relevant context, and further followed by lower-priority history.
6. Integrate tools and memory. Define how to incorporate the tool output into context and when to call a tool and not depend on the training data of the agent.

The above steps are repeated at each step taken by an agent as the context evolves over time during the task.

Context Engineering vs. Fine-Tuning: When to Use Which

Context engineering and fine-tuning address different issues. Context engineering alters the information a model consumes at inference time without changing the model’s parameters. Fine-tuning, on the other hand, modifies the parameters by further training, thus changing the behavior of the model for any subsequent request irrespective of the context.

Three criteria are used to choose the appropriate method. If the knowledge required for a certain task changes constantly (e.g., current inventory levels or recently created documents), it should be provided as context rather than fine-tuning the model each time the information changes. The need for a particular output format and tone applicable to all requests irrespective of the input suggests fine-tuning. The ability of current state-of-the-art models to produce desired behavior given structured context calls for fine-tuning.

The combination of both methods is common practice in production systems. A fine-tuned model needs context engineering to provide task-related information at inference time.

The Context Engineering Tech Stack

Four categories of tools support production context engineering pipelines.

Category	Examples	Function
Vector databases	Pinecone, Weaviate, FAISS, OpenSearch	Store embeddings and retrieve passages by semantic similarity
Orchestration frameworks	LangChain, LlamaIndex, LangGraph	Chain retrieval, prompt construction, memory, and tool calls into one pipeline
Embedding models and APIs	OpenAI Embeddings API, open-source Hugging Face models	Convert text into vector representations for semantic search
Evaluation and monitoring tools	LangSmith, Weights & Biases	Track context construction and measure its effect on model output

Another category has emerged recently which is related to the integration of tools: Model Context Protocol (MCP). It is an open protocol used for connecting a model to external tools/data by using a single standard interface instead of separate integrations.

Context Engineering by the Numbers

Five figures quantify the scale of the problem and the size of the returns from solving it correctly.

Metric	Figure	Source
Current Claude context window	1,000,000 tokens (Opus, Sonnet, and Fable tiers)	Anthropic model documentation, 2026
Token reduction, full context vs. pruned context	2.68× fewer tokens per 50-task benchmark (1,480,996 vs. 553,374 tokens)	Long-horizon agent benchmark study, 2026
Removable tool-result tokens with no accuracy loss	Up to 59.7% of tool-result tokens in one SWE-bench measurement	Production token-cost analysis, 2026
Performance variance explained by token usage	Approximately 80% in Anthropic’s BrowseComp multi-agent evaluation	Anthropic engineering blog
Cost reduction from prompt caching	Roughly 10× lower cost for cached tokens versus uncached tokens	Production reporting, 2025–2026

It would be natural to draw one conclusion from these numbers: context window size, not modeling capacity, is what production teams control with respect to costs and accuracy. Larger context windows do not make it unnecessary to manage their content.

Common Context Engineering Mistakes (and the Fix)

Five symptoms recur across production agent deployments, each with an identifiable cause.

Symptom	Likely cause	Fix
Agent repeats the same failed action	Old tool errors remain in context and are treated as valid history	Clear or summarize failed tool calls before the next turn
Agent ignores instructions given early in a long conversation	Context distraction — instructions are buried under accumulated history	Move critical instructions closer to the current turn, or restate them after compaction
Agent uses an unrelated tool	Context confusion — too many overlapping tool descriptions	Apply retrieval to the tool list; expose only tools relevant to the current step
Agent gives contradictory answers within one session	Context clash — stale memory conflicts with newly retrieved data	Timestamp all stored context and prioritize the most recent source
Costs rise without an accuracy improvement	Context window fills with unfiltered tool output and unsummarized history	Set a compression trigger at a fixed token threshold, not only at the hard context limit

A Real Example: Cutting Agent Token Use in Half Without Losing Accuracy

ContextSniper, a token-efficient memory system, was used in a 2026 experiment for repository-level program repair – finding and fixing a bug in the entire program code base – using the SWE-bench Lite benchmark.

Compared to a baseline agent, ContextSniper reduced the average number of tokens used per task from 1.36 million tokens to 0.66 million tokens, a 51.5% decrease. Inference cost decreased by 36.4%, and the number of tool and action calls was cut down by 46.4%. The resolution rate was roughly equivalent for both models: the baseline resolved 26.0% of the tasks, while ContextSniper resolved 24.0%.

In the second test, performed with Claude Haiku 4.5 pricing, the average number of tokens per task was reduced from 1.45 million to 0.79 million tokens – a 38.9% decrease over 50 successful runs, decreasing the cost from $15.09 to $10.97.

This is clearly the fundamental compromise of context compression: token reduction by large amounts results in very little loss in accuracy, not a proportional one. A 51.5% token reduction results in a 2-percentage point accuracy loss, not a 51.5% accuracy loss.

Frequently Asked Questions

Where Context Engineering Is Headed

There are three trends that will influence context engineering for the remainder of 2026. Firstly, context windows are increasing beyond the 1 million token point on a number of frontier models; however, published research still indicates that accuracy declines before this point, so compression and selection remain necessary regardless of context window size. Secondly, context-editing application programming interfaces are shifting from custom solutions to built-in platform functionality. Lastly, observability tools are beginning to show token attribution per context window element rather than manual token counting.

None of these trends reduces the need for the skill itself. An increased context window influences how much the team can afford to put into it. It doesn’t influence the need for a decision on what to put into it.