What Is Context Engineering? A Practical Guide for Building AI Agents

Context engineering has emerged as the successor to prompt engineering - a shift from finding the right words for your prompts to curating the entire information landscape your AI agent operates within. As Anthropic's Applied AI team puts it, context refers to the set of tokens included when sampling from an LLM, and the engineering problem is optimizing the utility of those tokens against the inherent constraints of transformer architectures.

Why Context Engineering Matters

Every token in an LLM's context window introduces n² pairwise attention relationships. As context grows, the model's ability to recall information degrades - a phenomenon known as context rot (Chroma Research). This means context must be treated as a finite resource with diminishing marginal returns, much like human working memory.

Anthropic's research shows that models lose focus as token counts increase, even before hitting hard limits. For a 200K-token context window, a research agent reading eight ~40K-token documents will hit the wall mid-task. On a 1M-token window, the agent completes but context rot degrades recall quality - early document reads become buried under hundreds of thousands of subsequent tokens.

The Three Levers of Context Management

Anthropic's developer platform and Claude Cookbook identify three complementary primitives for managing context in long-running agents:

1. Compaction

Compaction takes a conversation nearing the context limit, summarizes its contents, and reinitiates with that summary. In Claude Code, this is implemented by passing message history to the model to compress critical details - preserving architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs. The key is tuning your compaction prompt: maximize recall first (capture every relevant detail), then iterate on precision (eliminate superfluous content). Compaction is a whole-transcript operation - user messages, assistant reasoning, tool calls, and even prior compaction blocks are flattened into a summary.

2. Tool-Result Clearing

Tool-result clearing is a surgical sub-transcript operation. It walks the message list and replaces old tool_result content blocks with short placeholders, while leaving the tool_use record intact so the model knows it made the call. Once a tool has been called deep in message history, the agent rarely needs to see the raw result again - if it does, it simply calls the tool again. This is one of the safest, lightest-touch forms of context management, recovering space from re-fetchable data like file reads and API responses.

In practice, an agent reading eight ~40K-token documents produces roughly 320K tokens of tool-result volume. Tool-result clearing can drop the oldest results (configurable via keep, defaulting to the last 3 tool uses), freeing hundreds of thousands of tokens while preserving the record that the calls happened.

3. Memory (Structured Note-Taking)

Memory is a technique where the agent regularly writes notes persisted outside the context window, then pulls them back in at later times. This provides persistent memory across sessions - after a context reset, the agent reads its own notes and continues. Claude Code's implementation allows the agent to maintain to-do lists, track progress across complex tasks, and reference previous work without keeping everything in active context.

Anthropic's Claude Playing Pokémon demonstrated this powerfully: the agent developed maps of explored regions, tracked which achievements it unlocked, and maintained combat strategies across thousands of game steps - entirely driven by its own notes, without any prompting about memory structure.

Context Engineering for Claude 5: The Paradigm Shift

In July 2026, Claude Code's lead engineer Thariq published what may be the most important context engineering guidance of the year: Anthropic removed over 80% of Claude Code's system prompt for Opus 5 and Fable 5 with no measurable loss on coding evals.

The core insight: older models needed hard constraints to prevent worst cases. Claude 5's improved judgement means those same constraints now create conflicting instructions and wasted tokens. A single request can contain "leave documentation as appropriate" from one layer and "DO NOT add comments" from another. The model usually resolves user intent, but only after spending attention on the conflict.

Six Myths That Died

1. Give Claude rules → Let Claude use judgement. Replace "Never write comments" with "Write code that matches the surrounding code's comment density." The second is local, adaptive, and falsifiable.

2. Give examples → Design interfaces. Few-shot examples shrink the exploration space on capable models. Prefer expressive parameters, enums, and validation errors over multi-page worked examples.

3. Put it all upfront → Progressive disclosure. Move review playbooks and verification procedures out of the always-on system prompt and into skills Claude can selectively load. Use deferred loading for tools that aren't needed every turn.

4. Repeat yourself → Simple tool descriptions. Claude 5 does not need the same instruction at both the start and end of context. Keep the tool description authoritative and delete the duplicates.

5. Memory in CLAUDE.md → Auto-memory. The # hotkey habit of writing everything into CLAUDE.md is deprecated. Claude now auto-saves memories relevant to the work. CLAUDE.md should be a short purpose statement with gotchas - not a diary.

6. Simple specs → Rich references. Claude 5 handles high-fidelity artifacts: HTML mockups, test suites as specs, functions to port from another codebase, and rubrics that score output against criteria.

A Practical Rightsizing Checklist

Thariq recommends running this on any repo that accumulated "helpful" Claude config over 2025:

Conflict pass - list every absolute rule; delete duplicates and opposites.
Obvious pass - delete anything Claude learns from reading the tree.
Skill extraction - move multi-step procedures out of CLAUDE.md.
Example pass - replace few-shots with schema/interface improvements.
Doctor pass - run /doctor in Claude Code and accept simplifications you agree with.
Eval pass - re-run your coding harness after cuts.

The Architecture of Effective Context

Anthropic's research distills context engineering into a single guiding principle: find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome. Applied across the components of context:

System prompts should be clear, direct, and at the right altitude - specific enough to guide behavior, flexible enough to provide heuristics. Start minimal, test, then add instructions based on failure modes.
Tools should be self-contained, robust to error, and have minimal overlap. If a human can't decide which tool to use, an AI won't do better. Curate a minimal viable set and prune over time.
Just-in-time retrieval beats pre-loading everything upfront. Agents maintain lightweight identifiers (file paths, queries, links) and dynamically load data at runtime. This mirrors human cognition - we don't memorize entire corpuses, we index and retrieve on demand.

Looking Ahead

As models become more capable, context engineering shifts from prescriptive rules to interface design. The challenge is not crafting the perfect prompt - it's designing the information architecture that lets agents exercise good judgement. Anthropic recommends "do the simplest thing that works" as the guiding principle for teams building agents, because the field is moving too fast for complex, brittle orchestration layers.

Whether you're implementing compaction for long-horizon tasks, clearing tool results to keep working sets small, or designing memory systems for cross-session persistence, the principle stays the same: treat context as a precious, finite resource and optimize every token for signal.

What Is Context Engineering? A Practical Guide for AI Agents