Context engineering is an emerging discipline in applied AI that moves beyond traditional prompt engineering. Instead of focusing on the wording of instructions, it answers the question “what configuration of context is most likely to generate our model’s desired behavior?” Context refers to the set of tokens included when sampling from a large-language model (LLM); the engineering problem is optimizing the utility of those tokens against inherent LLM constraints to consistently achieve a desired outcome. At Anthropic, context engineering is viewed as the natural progression of prompt engineering. While prompt engineering covers methods for writing and organizing instructions, context engineering covers strategies for curating and maintaining the optimal set of tokens during inference, including all information that may appear beyond the prompts—system instructions, tools, the Model Context Protocol (MCP), external data, and message history. As agents operate over multiple turns and longer time horizons, managing the entire context state becomes necessary; an agent running in a loop generates increasingly more relevant data, requiring cyclical refinement. The core principle is to find the smallest possible set of high-signal tokens to maximize the likelihood of a desired outcome, treating context as a finite resource with diminishing marginal returns.
Context engineering is an iterative process of designing and optimizing the instructions and relevant context provided to LLMs and advanced AI systems, including multimodal models, to enable effective task performance. Originally predicted to be superseded by model improvements, it has instead grown in importance and been rebranded from "prompt engineering." It encompasses managing dynamic prompt elements, retrieval-augmented generation (RAG), tool definitions, few-shot demonstrations, memory structures, and systematic evaluation to refine what is fed into the context window. The approach applies to both simple prompts and complex multi-agent workflows, where careful context curation can reduce latency, cost, and error rates.
Context engineering is also the discipline of designing and building dynamic systems that provide an LLM with the right information, tools, and formatting, at the right time, to accomplish a given task. The quality of context is now the primary determinant of agent success or failure.
Key Points
Context engineering shifts focus from writing discrete prompts to continually curating what goes into the limited context window from an evolving universe of possible information.
LLMs have an “attention budget” that is depleted by each new token, stemming from the transformer architecture’s n² pairwise attention and training data bias toward shorter sequences.
The “context rot” phenomenon causes decreasing recall accuracy as the number of tokens increases, creating a performance gradient rather than a hard cliff.
Good context engineering requires clear, organized system prompts (using simple language, distinct sections like XML tags or Markdown headers) and a minimal viable set of tools with minimal overlap.
For examples (few-shot prompting), curate diverse, canonical examples that portray expected behavior rather than a laundry list of edge cases.
A shift from pre-inference embedding retrieval to “just in time” context strategies lets agents dynamically load data using tools (e.g., Claude Code uses file paths, grep, and commands like head/tail).
For long-horizon tasks, three techniques address context constraints: compaction (summarizing conversation history), structured note-taking (agentic memory persisted outside context), and sub-agent architectures (specialized agents with clean context windows).
The hybrid strategy—loading some data upfront and allowing autonomous exploration at runtime—works well for less dynamic content like legal or finance; smarter models require less prescriptive engineering.
Context engineering involves an iterative cycle of designing, testing, and measuring the effect of context changes on model outputs.
Core components include system instructions, structured inputs/outputs, dynamic context (e.g., current date), tool definitions, RAG, and short/long-term memory.
A concrete example is a multi-agent deep research system in n8n, where the Search Planner agent’s system prompt is carefully engineered with input delimiters, JSON schema examples, date-time tools, and cached subqueries.
Agent failures are often context failures: Most failures in agent systems are not due to model limitations but due to missing, irrelevant, or poorly formatted context.
Magic comes from context, not code: The difference between a cheap demo and a magical agent is the richness and relevance of the context provided, not the complexity of the underlying code.
Advanced topics include context compression, safety, dilution detection, and automated optimization, though tooling is still nascent.
Evaluation pipelines are essential to verify that context changes improve performance; without measurement, engineering efforts are blind.
Concepts
Context rot: The decrease in a model’s ability to accurately recall information as the number of tokens in the context window increases. This degradation occurs across all models, though some degrade more gently. It arises from the transformer architecture where every token attends to every other token, creating n² pairwise relationships that become stretched thin in long sequences, and from training data distributions where shorter sequences are more common.
Attention budget: A metaphor for the LLM’s limited capacity to process tokens, analogous to human working memory. Each new token depletes this budget.
Compaction: A technique for long-horizon tasks: taking a conversation nearing the context limit, summarizing it, and starting a new window with the summary. In Claude Code, the model compresses critical details (architectural decisions, unresolved bugs, implementation details) while discarding redundant tool outputs or messages.
Structured note-taking (agentic memory): The agent regularly writes notes persisted outside the context window, pulled back later after context resets. Examples include Claude Code creating a to-do list, a custom agent maintaining a NOTES.md file, or an agent playing Pokémon that keeps tallies and maps across thousands of steps.
Sub-agent architectures: A main agent coordinates a high-level plan while specialized sub-agents handle focused tasks with clean context windows. Each sub-agent uses tens of thousands of tokens but returns a condensed summary of 1,000–2,000 tokens, achieving separation of concerns for complex research and analysis.
Just-in-time context retrieval: Instead of pre-processing all relevant data up front, agents maintain lightweight identifiers (file paths, stored queries, web links) and dynamically load data into context at runtime using tools. This mirrors human cognition relying on external organization and indexing systems.
Hybrid context strategy: Retrieving some data upfront for speed (e.g., CLAUDE.md files naively dropped in) while giving agents tools (glob, grep) for just-in-time file retrieval, bypassing stale indexing and complex syntax trees.
Context window: The limited information buffer of an LLM; context engineering aims to pack the most relevant data into this space.
Dynamic context: Context that changes per request, such as user input, current time, or vector store retrieval results.
Structured inputs/outputs: Using delimiters, JSON schema, and examples to enforce formatting and type constraints on model responses.
Few-shot demonstrations: Providing a small number of example input-output pairs in the prompt to guide behavior.
Memory: Short-term (conversation history, state) and long-term (vector store retrieval across sessions) to maintain coherent context.
Evaluation pipelines: Formal processes to measure the impact of context changes on key metrics (accuracy, latency, cost).
Context dilution: Degradation of context quality over time due to stale or irrelevant information; requires special detection mechanisms.
Context components: The building blocks that an LLM sees before generating a response: instructions/system prompt, user prompt, state/history (short-term memory), long-term memory, retrieved information (RAG), available tools, and structured output specifications.
Context engineering vs. prompt engineering: Prompt engineering focuses on the text inside the user or system prompt; context engineering designs the entire system that populates all context components dynamically before the LLM call.
Details
Context engineering treats the entire context window as a consumable resource. The transformer architecture underpins this scarcity: every token attends to every other token, creating quadratic pairwise relationships. As context length increases, the model’s ability to capture these relationships is stretched thin. Additionally, models develop attention patterns from training data where shorter sequences are more common, giving them less experience with long-range dependencies. Techniques like position encoding interpolation allow handling longer sequences but with some degradation in token-position understanding. These factors create a performance gradient—the “context rot” phenomenon—rather than a hard cliff.
Anatomy of effective context. System prompts should be extremely clear, using simple direct language at the “Goldilocks zone” between hardcoding complex brittle logic and providing vague high-level guidance that fails to give concrete signals. Prompts should be organized into distinct sections (e.g., <background_information>, <instructions>, ## Tool guidance, ## Output description) using XML tagging or Markdown headers, though exact formatting becomes less important as models improve. The goal is the minimal set of information that fully outlines expected behavior; minimal does not necessarily mean short—sufficient upfront instruction is still needed. Start by testing a minimal prompt with the best model, then add clear instructions and examples based on failure modes.
Tool design. Tools allow agents to interact with their environment and pull in new context. They should be well understood by LLMs, have minimal overlap in functionality, be self-contained, robust to error, and extremely clear in intended use. Input parameters should be descriptive, unambiguous, and play to model strengths. A common failure is bloated tool sets that cause ambiguous decision points—if a human engineer cannot definitively choose which tool to use, an AI agent cannot be expected to do better. Curating a minimal viable set of tools leads to more reliable maintenance and pruning over long interactions.
Examples and few-shot prompting. Avoid a laundry list of edge cases; instead curate a set of diverse, canonical examples that effectively portray expected behavior. Across all components (system prompts, tools, examples, message history), be thoughtful and keep context informative yet tight.
Metadata and autonomous navigation. Metadata from file references (names, folder hierarchies, naming conventions, timestamps) provides signals that help agents understand purpose and usage of information. Autonomous navigation enables progressive disclosure: agents incrementally discover relevant context through exploration. File sizes suggest complexity, naming conventions hint at purpose, timestamps proxy for relevance. Agents assemble understanding layer by layer, keeping only necessary context in working memory and using note-taking for persistence. A trade-off exists: runtime exploration is slower than pre-computed data. It requires thoughtful engineering to give the LLM the right tools and heuristics; without proper guidance, agents waste context on misused tools, dead-ends, or missed key information.
Hybrid context strategy. A hybrid strategy retrieves some data upfront for speed and lets agents explore autonomously at discretion. The right level of autonomy depends on the task. Claude Code uses this hybrid model: CLAUDE.md files are naively dropped into context upfront, while glob and grep allow just-in-time file retrieval, bypassing stale indexing and complex syntax trees. The hybrid strategy may be better suited for less dynamic content (legal, finance work). As model capabilities improve, agentic design trends toward letting intelligent models act with less human curation. “Do the simplest thing that works” remains the best advice.
Long-horizon tasks. Tasks that span tens of minutes to hours of continuous work (e.g., large codebase migrations or comprehensive research) require agents to maintain coherence beyond the context window. Waiting for larger context windows is not sufficient—context pollution and relevance concerns persist for all sizes. Three techniques address these constraints:
Compaction. In Claude Code, the message history is passed to the model to compress critical details—preserving architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs or messages. The agent continues with the compressed context plus the five most recently accessed files. The art of compaction is selecting what to keep versus discard; overly aggressive compaction can lose subtle but critical context. Tune prompts on complex agent traces: maximize recall to capture every relevant piece, then iterate to improve precision. A safe light-touch form is tool result clearing (clearing tool calls and results deep in the history), launched as a feature on the Claude Developer Platform.
Structured note-taking (agentic memory). The agent regularly writes notes persisted outside the context window, pulled back later. Examples: Claude Code creating a to-do list, a custom agent maintaining a NOTES.md file. Claude playing Pokémon demonstrates this in a non-coding domain: the agent maintains precise tallies across thousands of game steps (e.g., “for the last 1,234 steps I’ve been training in Route 1, Pikachu has gained 8 levels toward the target of 10”). It develops maps of explored regions, remembers key achievements, and maintains combat strategy notes. After context resets, it reads its own notes and continues multi-hour sequences. As part of the Sonnet 4.5 launch, a memory tool was released in public beta on the Claude Developer Platform for file-based storage outside the context window.
Sub-agent architectures. Specialized sub-agents 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 information. Each sub-agent might use tens of thousands of tokens but returns a condensed summary of 1,000–2,000 tokens. This achieves separation of concerns: detailed search context stays in sub-agents, the lead agent synthesizes results. This pattern (discussed in “How we built our multi-agent research system”) showed substantial improvement over single-agent systems on complex research tasks.
Why context quality determines success. When an agent fails, it is rarely because the LLM cannot reason; it is usually because the LLM lacked critical information. For example:
A “cheap demo” agent receives only the user’s request (“Schedule a meeting tomorrow”). With no calendar, history, or contacts, it responds with a generic, robotic message.
A “magical” agent is fed a rich context: the user’s calendar (showing full schedule), past email tone with the recipient (informal), the recipient’s role (key partner), and a tool to send a calendar invite. It then produces a helpful, personalized response (“Thursday morning works, sent you an invite!”).
The difference is not in the model or the algorithm; it is entirely in the context.
The context engineering pipeline. Before each LLM call, a context engineer (human or automated system) assembles the enriched context through these steps:
Identifies the task – Understands what the user is trying to accomplish.
Gathers relevant information – Pulls from conversation history, long-term memory, RAG systems, calendars, emails, etc.
Selects appropriate tools – Adds only the tool definitions needed for the task (e.g., send_invite for scheduling).
Chooses the right format – Structures the information concisely (summaries over raw dumps) and specifies the output format (e.g., JSON).
Assembles the enriched context – Combines all components into a single input for the LLM.
This pipeline makes context dynamic and task‑specific, avoiding information overload and ensuring the model has exactly what it needs.
The following diagram illustrates the context engineering architecture:
Rendering diagram…
Concrete implementation example: Search Planner agent in n8n. A representative multi-agent deep research system demonstrates context engineering in practice. The Search Planner agent’s system prompt is assembled from several deliberately chosen components:
Instructions: High-level directives stating the agent’s overall objective.
User Input: Delimiters (e.g., <<query>> markers) clearly separate the user’s query from the expected output.
Structured Inputs and Outputs: A detailed list of required output fields with hints and examples. For instance, the agent is told to assign priority on a scale of 1–5 (rather than the LLM’s default 1–10). A JSON example is appended to the prompt, which an n8n tool output parser uses to auto-generate a schema, ensuring consistent structured outputs for downstream components.
Tools and Dynamic Context: A dedicated n8n function provides the current date and time. This tool is only invoked when needed, but without it the LLM guesses date ranges for time-sensitive queries, yielding poor web search results. The date is added to context so the agent can infer proper ranges.
RAG and Memory: The initial version lacks short-term memory, but a later iteration caches subqueries in a vector store. When a similar query arrives, the stored plan is retrieved instead of generating new subqueries, reducing latency and cost. Maintaining this store and deciding which existing subtasks to pull into context is a creative, customized effort—and a key differentiator.
States and Historical Context: For the report revision phase, the agent needs access to past subtask states, revision decisions, and outputs from other agents. The exact context passed depends on what is being optimized, requiring significant judgment and many iterations.
Evaluation and iteration. Evaluation pipelines are essential to verify that context changes improve performance; without measurement, engineering efforts are blind. Advanced (work-in-progress) aspects of context engineering include context compression, automated context management, context safety (preventing injection or leakage), and evaluation of context effectiveness over time. Context can become diluted with stale or irrelevant information as usage patterns change; specialized evaluation workflows are needed to detect such degradation. Although some automation tools exist, they remain limited, and the field is expected to require increasing developer attention.
Choice between approaches depends on task characteristics: compaction maintains conversational flow for tasks requiring extensive back-and-forth; note-taking excels for iterative development with clear milestones; multi-agent architectures handle complex research and analysis where parallel exploration pays dividends.
Conclusion. Context engineering is about curating what information enters the model’s limited attention budget. Whether implementing compaction, designing token-efficient tools, or enabling just-in-time exploration, the principle is finding the smallest set of high-signal tokens that maximize the desired outcome. Smarter models require less prescriptive engineering. Treating context as a precious, finite resource remains central to building reliable, effective agents.
Acknowledgements. Written by Anthropic’s Applied AI team: Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, and Jeremy Hadfield, with contributions from Rafi Ayub, Hannah Moran, Cal Rueb, and Connor Jennings. Special thanks to Molly Vorwerck, Stuart Ritchie, and Maggie Vo.