Context Engineering: The 2026 Playbook for AI Agents

Context engineering is the discipline of deciding exactly which tokens — system instructions, tool definitions, retrieved documents, conversation history — earn a place in an AI agent's limited context window at each step of its work. It has replaced prompt engineering as the core production-agent skill, because research through 2025 and 2026 shows every frontier model gets measurably worse as context grows, well before the window actually fills up. The fix is not a bigger window; it is a disciplined budget.

What context engineering actually means in 2026

In September 2025, Anthropic's applied AI team published Effective Context Engineering for AI Agents, framing it as the natural next step after prompt engineering. Instead of asking "what words get the best single response," the question becomes "what configuration of context — system prompt, tool definitions, examples, message history and runtime data — is most likely to produce the behaviour I want at this step of the agent's loop." That reframing matters because every one of those components competes for the same finite resource: the model's attention inside the window, not just the window's raw size. An agent that plans, calls tools and reflects touches this budget at every single turn, which is why the discipline matters far more for agents than for one-shot chat.

Context rot: why bigger windows did not solve the problem

Model vendors spent 2024 and 2025 racing toward 1-million-token context windows, and it was tempting to assume the context problem was solved by brute force. Chroma Research's Context Rot study, published July 2025, tested 18 frontier models — including GPT-4.1, Claude 4 and Gemini 2.5 — on simple retrieval and replication tasks and found that every single one degraded as input length grew. The decline was not gradual: models hit accuracy cliffs well before the window's rated limit. A 200K-token window could show serious accuracy loss by 50K tokens of input, and placing the relevant fact in positions 5–15 of a 20-document context cost some models 30-plus accuracy points compared with putting it first or last.

For coding and research agents specifically, this is the primary failure mode in production: an agent accumulates search results, tool outputs and abandoned reasoning paths as it works, and that accumulated noise degrades every subsequent step — not just the final answer. A 1-million-token window does not mean an agent reasons reliably across 1 million tokens; it means the cliff arrives later, not that it disappears.

Why this is surfacing now, not last year

Two signals from July 2026 show this moving from research talk to production concern. ICML 2026 opened in Seoul with an unusually heavy agentic-AI emphasis in its workshop programme — "agentic AI" appeared in at least 60 of 247 accepted workshop proposals, up sharply from prior years. And Amazon CloudWatch shipped Coding Agent Insights, a monitoring product built specifically to show engineering leaders how AI coding agents are performing across an organisation, pulling telemetry from Claude Code, Codex and GitHub Copilot. Vendors do not build monitoring products for problems that are not yet costing teams real money — context rot moved from an academic curiosity to a line item engineering leaders now track.

The four levers: write, select, compress, isolate

LangChain's engineering team distilled the discipline into four strategies that now show up, named or not, in most production agent frameworks:

• Write: store context outside the active window — scratchpads, memory files, running plans — so the model does not have to re-derive facts it already established two steps ago.
• Select: pull the right information into the window at the right moment. This is where RAG, tool calls and file reads earn their keep — and where over-eager retrieval becomes the problem rather than the fix.
• Compress: reduce what is already in the window down to the tokens that still matter — summarise resolved turns, trim raw tool output, drop finished sub-tasks.
• Isolate: split work across separate context windows — sub-agents or sandboxed steps — so one task's noise never contaminates another's context.

LangGraph, the framework most teams reach for on stateful, auditable agent workflows, builds its checkpointing and state graphs around exactly these four operations, which is a large part of why it has become a 2026 default for regulated or high-stakes agent work.

Agents that curate their own context

The most interesting 2026 research goes one step further: instead of an engineer manually deciding the context budget, the agent manages it. A Stanford, SambaNova and UC Berkeley paper on Agentic Context Engineering (ACE) splits the job across three roles — a Generator that produces reasoning trajectories, a Reflector that distils concrete lessons from what worked and what failed, and a Curator that folds those lessons back into a structured, evolving context "playbook" rather than a single static system prompt. Tested on agent and financial-analysis benchmarks, ACE-managed contexts beat strong baselines by 10.6% on agent tasks and 8.6% on finance tasks — without a single gradient update. The model did not get smarter; its context did.

This connects directly to the agent memory problem: memory decides what an agent can recall across sessions, while context engineering decides what gets pulled from that memory — and everything else — into the live window right now. Get the second one wrong and a perfect memory system still produces a rotting agent.

A concrete token budget for a production agent

Take a realistic Dutch customer-service agent handling a support ticket. A rough, honest token accounting looks like this:

• System prompt and tool definitions: roughly 3,000–6,000 tokens, and this line item grows every time another tool gets bolted on — most teams never revisit it once it is written.
• Retrieved knowledge: 2,000–4,000 tokens if the retrieval pipeline reranks and filters properly; easily ten times that if raw chunks get dumped in unfiltered.
• Conversation history: 500–2,000 tokens per turn, compounding across a multi-turn ticket, and rarely trimmed even after a sub-question is fully resolved.
• Tool call results: order lookups, CRM records and similar calls often cost 500–3,000 tokens each — usually the least-examined and most bloated source, because raw API JSON gets pasted straight into context instead of being parsed down to the three fields that matter.

Add a modest version of each — 5,000 for tools, 3,000 for retrieval, 4,000 for an eight-turn history, three tool calls averaging 1,500 tokens — and a single ticket is already consuming roughly 16,500 tokens of working context. Chroma's data shows accuracy loss beginning around 50,000 tokens of genuinely relevant information, even inside windows rated for 200,000 to 1,000,000 tokens. The practical rule: budget an agent's working context to a fraction of the window's rated size, not its ceiling, and re-measure the total whenever a tool or a retrieval source gets added, because each one usually costs more than the line item you expected.

The budget matters commercially too, not just for accuracy: every token in that 16,500-token ticket is billed on every model call for that turn, and a poorly compressed history compounds the same way it degrades accuracy — a ticket that reaches turn ten with an untrimmed transcript is not just more likely to hallucinate, it is also the most expensive call of the conversation to run.

What this means for Dutch SMEs building agents

Apply write/select/compress/isolate to a 20–50 FTE company automating quote or werkbon workflows with n8n or Make against a Dutch back office. The most common mistake is pasting an entire Exact Online or AFAS export into a system prompt "to be safe" — that is the single fastest way to trigger context rot on exactly the field that matters, a customer number buried three screens down. A better pattern:

• Select narrowly through an MCP connection or a scoped RAG lookup tied to the specific record, rather than the whole export.
• Isolate intake, lookup, drafting and approval into small, auditable sub-agents rather than one agent carrying the entire ticket in one context.
• Compress history once a ticket resolves, so a repeat contact three weeks later does not drag five previous tickets' worth of noise into the next answer.

This is exactly why we scope AI agent projects around narrow, checkpointed context windows with a human gate at the step where money or records change, rather than one open-ended agent holding an entire process in its head. It is also why we build for production, not demos: a demo tolerates a bloated context because nobody stress-tests it with the 40th ticket of the day; a production agent does not get that luxury.

Frequently asked questions