In the field of artificial intelligence applications,prompt engineering（prompt engineering) once held the spotlight for a long time, but now an emerging term is gradually coming to the fore:context engineering（context engineering）. Building with language models is no longer limited to finding the perfect prompt wording, but has shifted to answering a broader question:"Which context engineering configuration is most likely to elicit the desired behavior from the model?"
Context refers to the set of tokens included when sampling from a large language model (LLM). The current engineering problem is how to optimize the utility of these tokens under the inherent constraints of the LLM, so as to reliably achieve the target outcome. Effectively harnessing an LLM usually requirescontext thinking—that is, comprehensively considering the overall state available to the LLM at any given moment, as well as what potential behaviors that state may elicit.
This article will explore this emerging context engineering technique and provide a refined mental model for building controllable and efficient AI agents.
Context Engineering vs. Prompt Engineering
In Anthropic's view, context engineering is a natural evolution of prompt engineering. Prompt engineering focuses on writing and organizing LLM instructions to obtain the best results (see our documentation for an overview and practical strategies); whereas context engineering is a set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all other information beyond the prompt that may enter the context.
In the early days of LLM engineering, prompt design was the core of AI engineering work, because most use cases beyond everyday chat required prompts optimized for a single classification or text generation task. As the name suggests, prompt engineering mainly focuses on how to write effective prompts (especially system prompts). However, as we shift to building agents that can operate across multiple rounds of inference and longer time spans, we need strategies for managing the entire context state (system instructions, tools, Model Context Protocol MCP, external data, message history, etc.).
An agent running in a loop generates more and more data that may be relevant to the next round of inference, and this information must be refined iteratively. Context engineering is precisely the art and science of curating, from an ever-evolving universe of information, what should enter the limited context window.
Why Context Engineering Is Critical for Building Powerful Agents
Although LLMs are fast and can handle increasingly large amounts of data, we observe that, like humans, they lose focus or become confused at some point. Research on "needle in a haystack"-style benchmarks has revealedcontext rot: as the number of tokens in the context window increases, the model's ability to accurately recall contextual information declines.
Although some models decay more slowly, this characteristic is widespread. Therefore, context must be treated as a limited resource with diminishing marginal returns. Similar to humans' limited working memory capacity, LLMs consume an "attention budget" when parsing large amounts of context. Each newly introduced token consumes part of that budget, further intensifying the need to carefully curate the tokens available to the LLM.
This scarcity of attention stems from the architectural constraints of LLMs. LLMs are based on the Transformer architecture, in which each token can attend to other tokens throughout the entire context, forming n² pairwise relationships (where n is the number of tokens). As context length increases, the model's ability to capture these relationships is diluted, resulting in a natural tension between context size and attentional focus. In addition, the model's attention patterns derive from the training data distribution (in which short sequences are usually more common), meaning the model has less experience with cross-context dependencies and insufficient dedicated parameters.
Techniques such as positional encoding interpolation handle longer sequences by adapting the model to the small context used in original training, but they weaken the understanding of token positions. These factors produce a performance gradient (rather than a hard cliff): the model remains highly usable in long contexts, but its precision on information retrieval and long-range reasoning may be lower than its short-context performance.
These realities mean that deliberate context engineering is essential for building robust agents.
What Makes Up an Efficient Context
Given that LLMs are constrained by a limited attention budget, good context engineering means findingthe smallest set of high-signal tokensthat maximizes the likelihood of achieving the desired outcome. Putting this practice into effect is easier said than done, and below we explain what this guiding principle means concretely across different context components.
System Promptsshould be extremely clear, use simple and direct language, and be suited to the high-level presentation of ideas for the agent. The right altitude is the "Goldilocks zone" between two common failure modes. At one end, engineers hard-code complex and brittle logic into the prompt to elicit precise behavior, which introduces fragility and increases maintenance complexity; at the other end, they provide vague high-level guidance that fails to give the LLM concrete signals about the expected output or wrongly assumes shared context. The optimal altitude requires a balance: specific enough to effectively guide behavior, yet flexible enough to provide strong heuristic guidance.
We recommend organizing prompts into distinct sections (such as <background information>, <instructions>, ## tool guidance, ## output description, etc.) and using techniques such as XML tags or Markdown headings to delineate these sections—although as model capabilities improve, the exact format of the prompt may become increasingly less important.
No matter how the system prompt is structured, one should aim forthe minimal set of informationthat fully outlines the expected behavior (note: minimal does not necessarily mean short; sufficient information must still be provided to ensure the agent complies with the expected behavior). It is best to start with a minimal prompt and, based on failure modes found in initial testing, add clear instructions and examples to improve performance.
Toolsallow the agent to interact with the environment and introduce new additional context during work. Because tools define the contract between the agent and its information/action space, tools must improve efficiency: both by returning token-efficient information and by encouraging efficient agent behavior.
In "Writing AI Agent Tools with AI Agents," we discussed building tools that are easy for LLMs to understand and have minimal functional overlap. Like well-designed codebase functions, tools should be self-contained, robust, and have extremely clear purposes. Input parameters should likewise be descriptive, explicit, and leverage the model's inherent strengths.
The most common failure mode is a bloated toolset that covers too many functions or creates ambiguous decision points about which tool to use. If a human engineer cannot determine which tool should be used in a particular situation, one cannot expect an AI agent to do better. As will be discussed later, curating a minimal viable toolset for the agent also enables more reliable context maintenance and pruning during long interactions.
Provide Examples(i.e., few-shot prompting) is a well-known best practice that we continue to strongly recommend. But teams often cram a long list of edge cases into the prompt in an attempt to clarify all the possible rules the LLM should follow when performing a specific task. We do not recommend this approach; instead, we suggest curating a diverse set of canonical examples that effectively depict the agent's intended behavior. For an LLM, examples are the "pictures" behind "a picture is worth a thousand words."
Our overall guidance for the components of context (system prompt, tools, examples, message history, etc.) is: be thoughtful, and keep context information-rich yet compact. Now let us take a deep dive into dynamically retrieving context at runtime.
Context Retrieval and Agent Search
In "Building Effective AI Agents," we emphasized the distinction between LLM-based workflows and agents. Since that article was published, we have leaned toward a simple definition of an agent:An LLM that autonomously uses tools in a loop。
In our work with customers, we have witnessed the field converging on this simple paradigm. As the capabilities of the underlying models increase, the level of agent autonomy can scale: smarter models allow agents to independently navigate nuanced problem spaces and recover from errors.
We are seeing a shift in how engineers design agent context. Today, many AI-native applications employ some form of embedding-based retrieval before inference to surface important context for agent reasoning. As the field moves toward more agentic approaches, teams are increasingly augmenting these retrieval systems with "just in time" context strategies.
Agents built with a "just in time" approach do not preprocess all relevant data; instead, they maintain lightweight identifiers (file paths, stored queries, web links, etc.) and use these references to dynamically load data into context at runtime through tools. Anthropic's agentic coding solution, Claude Code, uses this approach to perform complex data analysis on large databases. The model can write targeted queries, store the results, and use Bash commands such as head and tail to analyze large amounts of data without loading complete data objects into context. This approach mimics human cognition: we typically do not memorize an entire body of information; instead, we bring in external organization and indexing systems (such as file systems, inboxes, and bookmarks) to retrieve relevant information on demand.
Beyond storage efficiency, the metadata of these references provides a mechanism for efficiently optimizing behavior (whether explicitly provided or intuitively perceived). For an agent operating in a file system, a file named test_utils.py in the tests folder implies a different purpose than a file of the same name in src/core_logic.py. Folder hierarchy, naming conventions, and timestamps all provide important signals that help humans and agents understand how and when to use information.
Letting agents autonomously navigate and retrieve data also supportsprogressive disclosure(progressive disclosure)—that is, allowing agents to gradually discover relevant context through exploration. Each interaction produces context that guides the next decision: file size suggests complexity; naming conventions hint at purpose; timestamps can serve as a proxy for relevance. Agents can assemble understanding layer by layer, maintaining only what is necessary in working memory, and use note-taking strategies to achieve additional persistence. This self-managed context window keeps the agent focused on the relevant subset rather than drowning in exhaustive but potentially irrelevant information.
Of course, there are trade-offs: runtime exploration is slower than retrieving precomputed data. Moreover, it requires thoughtful engineering to ensure the LLM has the right tools and heuristics to effectively navigate its information landscape. Without proper guidance, an agent may waste context by misusing tools, chasing dead ends, or failing to recognize key information.
In some scenarios, the most effective agent may adopt ahybrid strategy: pre-retrieving some data for speed while autonomously deciding to explore further. The "appropriate" level of autonomy depends on the task. Claude Code is an agent that adopts this hybrid model: the CLAUDE.md file is simply pre-placed into context, while primitives such as glob and grep allow it to navigate the environment and retrieve files on the fly, effectively avoiding stale indexes and complex syntax tree issues.
A hybrid strategy may be more suitable for contexts with low content dynamism (such as legal or financial work). As model capabilities improve, agent design will trend toward letting intelligent models act intelligently, gradually reducing manual curation. Given the rapid development of the field, "do the simplest thing that works" may remain our best advice for teams building agents on Claude.
Context engineering for long-horizon tasks
Long-horizon tasks require agents to maintain coherence, context, and goal-directed behavior across action sequences whose token count exceeds the LLM's context window. For tasks lasting tens of minutes to hours (such as large codebase migrations or comprehensive research projects), agents need specialized techniques to circumvent context window size limitations.
Waiting for larger context windows seems like the obvious strategy. But predictably, context windows of all sizes may suffer from context pollution and information relevance issues—at least in situations with extremely high demands on agent performance. To enable agents to work effectively over extended time horizons, we developed several techniques that directly address these context pollution constraints:compaction、structured note-takingandmulti-agent architectures。
Compaction
Compaction is the practice of summarizing a conversation that is approaching the context window limit and using that summary to reinitialize a new context window. Compaction is often the first means of improving long-term coherence in context engineering. At its core, compaction distills the contents of the context window with high fidelity, allowing the agent to continue working with minimal performance degradation.
For example, in Claude Code, we summarize and compact the most critical details by passing the message history to the model. The model retains architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs or messages. The agent can then continue working with the compacted context and the five most recently accessed files. Users gain continuity without worrying about context window limits.
The art of compaction lies in choosing what to retain and what to discard, because over-compaction may lead to the loss of subtle but critical context (whose importance may only become apparent later). For engineers implementing compaction systems, we recommend carefully tuning the prompt on complex agent trajectories: first maximize recall to ensure the compaction prompt captures all relevant information in the trajectory, then iteratively improve precision to eliminate redundant content.
A low-hanging example of redundant content is clearing tool calls and results—once a tool has been called deep in the message history, why would the agent need to see the original result again? The safest and lightest form of compaction is tool result clearing, recently released as a feature on the Claude Developer Platform.
Structured note-taking
Structured note-taking (or agent memory) is a technique in which an agent regularly writes notes and persists them to memory outside the context window. These notes are later pulled back into the context window.
This strategy provides persistent memory with minimal overhead. Just as Claude Code creates todo lists, or custom agents maintain NOTES.md files, this simple pattern lets agents track complex task progress and preserve critical context and dependencies that would otherwise be lost across numerous tool calls.
Claude playing Pokémon demonstrated how memory transforms agent capabilities in non-coding domains. The agent maintained precise counts across thousands of game steps—tracking objectives such as "for the past 1234 steps I have been training Pokémon on Route 1, and Pikachu has gained 8 levels toward the target of level 10." Without any prompting for a memory structure, it developed a map of explored areas, remembered key achievements unlocked, and maintained strategic notes on battle tactics to learn which attacks were most effective against different opponents.
After a context reset, the agent read its own notes and continued training sequences or dungeon exploration for hours. This continuity across summarization steps enabled long-horizon strategies that would be impossible if everything were kept only in the LLM context window.
As part of the Sonnet 4.5 release, we publicly tested the memory tool on the Claude Developer Platform, making it easier to store and query information outside the context window through a file-based system. This lets agents accumulate a knowledge base over time, maintain project state across sessions, and reference prior work without keeping everything in context.
Sub-agent architecture
Sub-agent architecture provides another way to circumvent context limitations. Rather than one agent trying to maintain the entire project state, specialized sub-agents can handle focused tasks with clean context windows. The main agent coordinates with a high-level plan, while sub-agents perform deep technical work or use tools to find relevant information. Each sub-agent may explore extensively, using tens of thousands or more tokens, but returns only a condensed summary of its work (typically 1000-2000 tokens).
This approach achieves a separation of concerns—detailed search context stays within the sub-agent, while the lead agent focuses on synthesizing and analyzing results. This pattern was discussed in "How We Build Multi-Agent Research Systems" and showed significant improvement over single-agent systems on complex research tasks.
The choice among these approaches depends on task characteristics. For example:
- Compression is suitable for tasks that require extensive back-and-forth communication to maintain conversational flow;
- Note-taking is suitable for iterative development with clear milestones;
- Multi-agent architecture handles complex research and analysis where the benefits of parallel exploration are significant.
Even as models continue to improve, the challenge of maintaining coherence across extended interactions will remain central to building more effective agents.
Conclusion
Context engineering represents a fundamental shift in how we build with LLMs. As model capabilities increase, the challenge is not only crafting perfect prompts—it is thoughtfully curating which information enters the model's limited attention budget at each step. Whether you are implementing compression for long-horizon tasks, designing token-efficient tools, or letting agents explore the environment in real time, the guiding principle remains the same: findthe smallest set of high-signal tokensto maximize the likelihood of the desired outcome.
The techniques we outlined will continue to evolve as models improve. We have already seen that smarter models require less prescriptive engineering, allowing agents to operate with greater autonomy. But even as capabilities expand, treating context as a valuable, limited resource will remain central to building reliable and effective agents.
Start your context engineering journey today on the Claude Developer Platform, and get useful tips and best practices through our memory and context management cookbook.
Acknowledgements
Written by the Anthropic Applied AI team: Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, and Jeremy Hadfield, with contributions from team members Rafi Ayub, Hannah Moran, Cal Rueb, and Connor Jennings. Special thanks to Molly Vorwerck, Stuart Ritchie, and Maggie Vo for their support.