Context Engineering for AI Agents (2026 Field Guide)

Prompt engineering was about the words you write. Context engineering is about everything the model sees when it runs: the system prompt, the tool definitions, retrieved documents, prior turns, and scratchpad state. Anthropic named the discipline directly in its 2025 piece Effective context engineering for AI agents, and for anyone building agents it has become the higher-leverage skill. This guide gives you a working mental model, a token-budget you can compute, a comparison of the main tactics, and a way to run it consistently across many models on one API.

What context engineering is

Context engineering is the discipline of curating what an LLM sees at inference time. Anthropic put a name to it in its 2025 engineering piece Effective context engineering for AI agents, framing the context window as a scarce resource to be managed deliberately rather than stuffed to the limit.

The core idea: a model does not reason over your intentions. It reasons over the exact tokens present in its context. Every design decision that changes those tokens, from which documents you retrieve to how many past turns you keep, is context engineering. For an agent that runs dozens of steps, those decisions compound, and they decide whether the run stays coherent or drifts.

If you want the underlying constraint spelled out, our explainer on the Claude context window covers how token limits and attention interact. This guide sits one level up: given a window, how do you decide what earns a place in it.

Context engineering vs prompt engineering

Prompt engineering optimizes the static instruction you author. Context engineering manages the entire, largely dynamic, set of tokens the model sees during a run. The distinction matters because in an agent most of the context is not written by you at all, it is produced at runtime by tools and retrieval.

Prompt engineering never went away, it became one tool inside a larger kit. A crisp system prompt still matters, it just is not sufficient once the agent starts appending tool output on every loop.

Anatomy of an agent context

Before you can budget a context, you need to see its parts. A typical agent context breaks into a handful of buckets, some fixed for the whole run and some that grow with every step. The chart below shows an illustrative split for a mid-run coding agent, so you can see where tokens actually go.

The lesson from the shape: the two growth-prone buckets, retrieval and history, are where a run goes wrong. Fixed costs like the system prompt and tool schemas are easy to reason about because they do not move. The variable buckets need active management, which is what the tactics below address. Tool definitions in particular deserve care, since verbose schemas tax every single call. If you are choosing tools to expose at all, our comparison of MCP vs API is a useful companion.

The core tactics compared

There is no single trick. Production agents combine several tactics, each trading something. Here is how the main ones stack up.

A practical decision rule: if your problem is too much irrelevant data, reach for retrieval and tool trimming first; if your problem is a run that goes on too long, reach for compaction, offloading, and sub-agents. Most real agents need one from each column. For agent architecture more broadly, our roundup of the best LLM for AI agents in 2026 pairs model choice with these tactics, and if you drive tool-use through Claude Code, the patterns in Claude Code skills and AGENTS.md show how to keep instructions themselves lean.

A token budget you can compute

Context engineering becomes concrete the moment you write the budget as arithmetic. Take a model with a 128k window and a task that needs about 8k tokens of output. Your usable input budget is 128k minus an output reserve, minus fixed costs, and what remains is what you can spend on the variable buckets.

Worked example. Reserve 8k for output. Fixed costs: 3k system prompt plus 5k tool definitions equals 8k. That leaves 128k minus 8k minus 8k, which is 112k for variable context. If you cap history at 16k and scratchpad at 4k, you have 92k for retrieval. That is generous, but the lesson runs the other way on a small model: on a 32k window with the same 8k output reserve and 8k fixed costs, only 16k remains for everything variable, so history and retrieval are now in direct competition and something has to give.

The decision rule that falls out: fixed costs plus output reserve plus history should leave headroom for retrieval, or you are on the wrong model for the task. When they do not, either move to a larger window, offload history to external memory, or split the work across sub-agents. Computing this per model, rather than guessing, is the single highest-leverage habit in context engineering.

Running it across many models

The tactics above are model-agnostic, but the numbers are not. Window sizes range from tens of thousands to hundreds of thousands of tokens, and per-token pricing swings the cost of a fat context by an order of magnitude. That means the same context strategy needs re-checking against each model you consider.

This is where a gateway earns its place. Rather than integrate each provider separately, you point one OpenAI-compatible endpoint at Claude Opus 4.8 for a long-context planning step, Qwen3 Coder Next for tool-heavy execution, and DeepSeek V4 Flash or GLM 5.2 for cheap high-volume sub-agent calls, all with one key. If the gateway pattern is new to you, start with what is an LLM gateway. The payoff for context engineering specifically: you can run the same budgeted request across models and measure which one holds your context best, without rewriting a line of integration code.

FAQ