Home › Guides › Context engineering
Tech Explained · 2026What Is Context Engineering in 2026? How It Works, Why Agents Fail and 6 Techniques That Cut Token Costs
Context engineering is the practice of deciding exactly what enters a model's context window at each step of an agent's run: system prompt, tool definitions, retrieved documents and prior turns. Most agent failures are context failures, not model failures, and published benchmarks show optimised context using roughly 2.7x fewer tokens than stuffing everything in.
- It is an engineering job, not a writing job. Context engineering decides what the model sees on every turn. Prompt engineering decides how one instruction is worded.
- Bigger context windows did not fix it. Chroma's Context Rot research tested 18 models and found accuracy falls as input grows, with the worst results when the answer sits in the middle of a long input.
- Tokens track quality. Anthropic's write-up of its multi-agent research system reports that token usage alone explained about 80% of performance variance on its BrowseComp evaluation.
- The user's question is a rounding error. In a typical agent turn, history, tool schemas and retrieved text eat well over 90% of the window.
- Caching is the cheapest win available. On Anthropic's API, cache reads bill at 0.1x the base input rate, so a stable prefix pays for itself after roughly two reuses.
- It is the hiring signal right now. Job posts that once said "prompt engineering" now ask for retrieval design, tool schemas, evals and token budgets.
Your agent passed every test you wrote. Then a customer asked it a question on turn fourteen of a long conversation, and it confidently ignored the one policy rule you had pasted into the system prompt at the very beginning. You did not change the model. You did not change the prompt. The context just got long, and the instruction that mattered slid into the part of the window where models stop paying attention.
That failure has a name now, and a discipline built around fixing it.
What is context engineering for AI agents?
Context engineering is the design of everything a model sees on a given turn. Not the wording of one instruction, but the whole assembly: which system prompt, which subset of your tools, which retrieved passages, how much of the conversation so far, and what the agent wrote down for itself three steps ago.
Anthropic's engineering team frames it as the natural progression of prompt engineering. Once an agent moves from one-shot answers to multi-turn, long-horizon work, the question stops being "how do I word this well" and becomes "what configuration of context is most likely to produce the behaviour I want at this step." Those are different jobs. The second one involves retrieval systems, schema design, summarisation policies and a budget.
The mental model that helps most: treat the context window as a finite attention budget rather than a bucket. Every token you add competes with every other token for the model's attention. Adding more is not free even when it fits.
What gets assembled into the context window on every agent turn
Context engineering is the selection logic between the left column and the middle box.
Assembly model as described in Anthropic's engineering guidance on context engineering for agents, checked 16 September 2026.
If you have already built a retrieval pipeline, you have done part of this without the label. Our walkthrough of how RAG actually works, step by step covers the retrieval half; context engineering is the wider question of what to do with the retrieved text once you have it, alongside everything else competing for the same window.
Context engineering vs prompt engineering: the difference that matters
People use the two terms interchangeably and then wonder why their prompt tweaks stopped helping. They are not the same job, and they fail in different ways.
| Criterion | Prompt engineering | Context engineering |
|---|---|---|
| Unit of work | One instruction or template | The whole window, every turn |
| What you optimise | Wording, examples, output format | Selection, ordering, compression, budget |
| When it runs | Written once, shipped | Computed at runtime, per request |
| Main failure mode | Model misreads the instruction | The right information was never in the window, or was buried |
| Typical artefact | A prompt file | A retriever, a tool registry, a compaction policy, an eval set |
| Skills needed | Clear writing, a few-shot instinct | Python, embeddings, schema design, cost modelling |
| How you test it | Eyeball a handful of outputs | Scored eval runs with token counts attached |
| Cost impact | Marginal | Directly sets your API bill |
| Where it breaks first | Edge-case phrasing | Turn 10 onwards, long documents, many tools |
The practical test: if your fix is something you type into a text file, it is prompt engineering. If your fix is code that runs before the API call, it is context engineering. Designing tool schemas so a model picks the right one on the first try sits squarely in the second camp, which is why it shows up as an exam objective in 360DT's CCDV-F developer prep course rather than in any writing module.
Why bigger context windows did not solve context engineering
The obvious objection is that windows got huge. Claude 4.6 and later models carry a 1M token window, and as of the September 2026 pricing page that full window is billed at the standard per-token rate rather than a long-context premium. Claude Sonnet 5 lists at $2 per million input tokens and $10 per million output. So why not paste everything in?
What context rot means for your agent
Because accuracy does not hold up across that window. Chroma's Context Rot research evaluated 18 models, including GPT-4.1, Claude 4 Opus and Sonnet, Gemini 2.5 Pro and Flash, and Qwen3 variants, holding task difficulty constant while varying only input length. Performance degraded as input grew across the board. Models did best when the relevant information sat near the beginning or the end of the input, and noticeably worse when it sat in the middle of a long document.
There is a safety-shaped version of the same problem: evaluation work in this area reports that models miss dangerous actions substantially more often when those actions appear after hundreds of thousands of tokens of ordinary activity. Long context does not just cost more. It lowers your hit rate on exactly the rare events you built the agent to catch.
Four numbers that set the economics
Each of these was checked against a published source rather than estimated.
Sources: Anthropic platform pricing documentation, Chroma's Context Rot research, and published agent-optimisation benchmarks. Checked 16 September 2026.
What is actually eating your context window
Before you optimise anything, count. Most teams have never looked at the breakdown, and the shape surprises them.
A typical agent turn, by share of input tokens
The thing the user actually asked for is the smallest slice on the page.
Illustrative shape for a mid-conversation turn in a tool-using agent, not a measurement of any specific system. Run the count on your own traces before acting on it. Checked 16 September 2026.
Tool schemas are the slice people forget. A published optimisation walkthrough puts a realistic tool block at 46 tools times roughly 150 tokens each, or about 6,900 tokens, and shows that cutting to 15 relevant tools drops it to about 2,250, a 67% reduction on that component alone. You pay that on every single turn, whether or not the agent calls a tool. If your agent is wired to a pile of servers through the Model Context Protocol, this is where your bill is hiding.
6 context engineering techniques that cut token costs
Six techniques, in the order worth trying them
The first two are an afternoon's work. The last four are architecture decisions.
Cut the tool list per step
Load only the tools reachable from the current state. A refund agent does not need the onboarding tools in its window. Gate the registry on task type before you build the request.
Biggest quick winRetrieve just in time
Stop pasting the whole handbook at session start. Give the agent a search tool and let it pull the three passages it needs on the turn it needs them. Replacing a 30,000-token static block with a 500-token dynamic one is routine.
Retrieval designCompact the history
When the window fills, summarise the run so far and continue from the summary. Anthropic describes Claude Code doing this by preserving architectural decisions, unresolved bugs and implementation details, then carrying on with that summary plus the five most recently accessed files.
Long-horizon tasksPush detail into sub-agents
Give each sub-agent its own window, let it do the noisy searching, and have it return a short summary to the lead agent. Anthropic reports its multi-agent research system beating single-agent Opus 4 by 90.2% on research evaluations using exactly this split.
ArchitectureCache the stable prefix
Put everything that never changes at the very top and mark it cacheable. Anthropic bills cache writes at 1.25x base input for the 5 minute TTL and 2x for the 1 hour TTL, while reads bill at 0.1x, so a prefix earns its write back after about two reuses.
Pure cost savingWrite notes outside the window
Have the agent keep a scratch file of decisions and open questions, and read back only the lines it needs. State that lives on disk costs nothing per turn. State that lives in the transcript costs you again on every request.
MemoryMechanisms and pricing per Anthropic's engineering guidance and platform pricing docs, plus published agent-optimisation benchmarks. Checked 16 September 2026.
Techniques 3 and 4 are the ones people implement badly. Compaction and sub-agent decomposition are architecture decisions with failure modes, which is why they turn up in agent-architecture syllabi such as the CCAR-F architect foundations track rather than in introductory prompting material.
Build agents where the context is engineered, not pasted
The AI Engineer course runs 100+ hours live over 16 weeks on building generative AI, RAG and agent systems, certified on both Microsoft Copilot Studio and Claude Code. You build retrieval, tool design and agent loops in class rather than watching them.
Explore the course
A worked example: a claims agent at a mid-size Indian insurer
Here is an illustrative scenario, not a real client. A two-person data team at a mid-size Indian insurer builds an internal agent that answers claims questions for the call centre. Version one works: they paste the 60-page policy handbook into the system prompt, wire up all 28 internal tools, and keep the full conversation. It is fine for the first few turns. By turn twelve the agent starts contradicting itself on sub-limits, and the finance lead asks why the API bill tripled.
They count the tokens, then apply four of the six techniques above.
| Context component | Naive build | After context engineering | Change |
|---|---|---|---|
| System prompt | 1,200 tokens | 900 tokens | Trimmed to standing rules only |
| Tool definitions | 28 tools, 4,200 tokens | 9 tools, 1,350 tokens | Gated by task type |
| Policy documents | Whole handbook, 30,000 tokens | 4 retrieved passages, 2,000 tokens | Just-in-time retrieval |
| Conversation history (turn 12) | 14,000 tokens | 3,500 tokens | Compacted at turn 8 |
| Input tokens per turn | 49,400 | 7,750 | 84% smaller |
| Cost per 1,000 turns, Sonnet 5 input at $2/M | about $99 | about $16 | about $83 saved |
| Cacheable prefix | None, handbook shifted position | 2,250 tokens at 0.1x on reads | Further saving on repeat turns |
The cost line is the part that gets the meeting, but the sub-limit contradictions are the part that mattered. Once the handbook stopped being a 30,000-token wall and became four retrieved passages sitting close to the question, the agent stopped losing the rule in the middle of its own input. That is the whole thesis: the token saving and the accuracy gain come from the same change.
The same two-person team hits a different wall next, and it is worth naming. Their retrieval was only as good as their chunking, and their chunking was only as good as the pipeline feeding it. Teams doing this on Microsoft's stack usually end up in Fabric data engineering territory, because a retrieval layer is a data product with an SLA, not a folder of PDFs.
Where context engineering is oversold
Being honest about this: context engineering will not rescue a bad agent. If your retrieval corpus is stale, contradictory or missing the answer, tightening the window just delivers the wrong information more cheaply. If the task genuinely needs stronger reasoning, no amount of token surgery substitutes for a better model. Several of the vendor write-ups around this topic imply otherwise, and they are selling something.
There is also a volume threshold. At 500 agent turns a month, the difference between the naive and optimised builds in the table above is roughly $42. An engineer spending two weeks on compaction policies to save that has lost the company money. Do the arithmetic before you start: token optimisation is worth real effort somewhere north of tens of thousands of turns a month, and below that you should be shipping features.
And a scale caveat that cuts the other way. Anthropic notes its multi-agent architecture consumes roughly fifteen times the tokens of a standard chat interaction. Sub-agents buy you accuracy and isolation, not a smaller bill.
- The timestamp that kills your cache. Someone puts the current date and time at the top of the system prompt so the agent knows "today". Caching works on a stable prefix, so that one line invalidates the cache on every single request. Move it to the end of the user message.
- Compaction that eats the constraint. A summariser keeps the plot and drops the sentence about a regulatory limit, because at summarisation time it did not look important. Pin hard constraints outside the compactable region.
- Tool descriptions written for humans. Three tools with overlapping descriptions means the model guesses. Make the boundaries explicit in the schema instead of adding another paragraph of instructions.
- Optimising without an eval set. If you cannot score the agent before and after, you are not engineering. You are reshuffling text and hoping.
How to learn context engineering in 2026
You do not need a new degree. You need four things that mostly already exist in adjacent job descriptions, and a build to hang them on.
Start with Python and the API mechanics: streaming, tool calling, token counting. Then retrieval, properly, including chunking strategy and hybrid search, which is covered in our guide to building production RAG. Then evals, because everything above is unfalsifiable without them. Evaluation and monitoring are the AI-300 territory that an MLOps engineer track drills, and they are what turn opinions about context into measurements. Finally, cost modelling, which is nothing more exotic than a spreadsheet of tokens times price.
On the credential question, since it comes up constantly: no exam is titled "context engineering" yet. The skill shows up as objectives spread across others. Agent design and tool use appear in the Claude developer and architect exams, Azure's AI-103 covers the same ground on Microsoft's stack through a generative AI developer program, and the deployment-side reality of doing this inside a customer's estate is the daily work of a forward deployed engineer. If you want to see how the exams line up against each other, the full certifications overview lays out every track we run.
360DT's AI Engineer course teaches this stack live over 16 weeks, and the retrieval, tool-design and agent-loop modules are where context engineering is practised rather than described. Classes run Saturday and Sunday, 8 to 11 PM IST, which is the format most working engineers in India can actually sustain.
Related guides
- What Is Claude Opus 5? 1M-Token Context, Agentic Benchmarks and How to Start Using It in 2026 the model-side view of the same window this article teaches you to budget.
- A2A Protocol Explained in 2026: How Agent2Agent Works, MCP vs A2A, and Your First Multi-Agent Build read this before you split work across sub-agents with separate windows.
- Enterprise AI Agents in 2026: Why Only 23% of Pilots Scale, and 6 Skills That Close the Gap the organisational reasons agents stall, once the technical ones are fixed.
- AI Engineer vs Machine Learning Engineer in 2026: Salary, Skills and Which Role to Pick in India which of the two roles actually owns the context pipeline.
- Agentic AI Jobs in India 2026: How a 300% Hiring Surge Is Creating 6 New Tech Careers where these skills are being hired, and under what job titles.
- 8 Generative AI Project Ideas for 2026: Stack, Data and What Interviewers Ask builds worth doing if you need something to practise context budgeting on.
Frequently asked questions
What is context engineering in simple terms?
Context engineering is choosing what information goes into an AI model's context window on each turn, and in what order. Instead of writing one clever prompt, you write code that assembles the system prompt, the relevant tools, the retrieved passages and a compressed version of the conversation so far, aiming for the smallest set of high-signal tokens that will do the job.
Is context engineering the same as prompt engineering?
No. Prompt engineering optimises the wording of an instruction and is usually a file you edit. Context engineering optimises the whole window at runtime and is usually code: a retriever, a tool registry, a summarisation policy and a token budget. Prompt engineering is a subset of it.
Does a 1M token context window make context engineering unnecessary?
It makes it more necessary, not less. Chroma's Context Rot research found that accuracy falls as input length rises across all 18 models tested, and that information buried in the middle of a long input is retrieved least reliably. A large window is permission to fit more in, not a promise the model will use it well.
What is context rot?
Context rot is the measurable drop in model performance as input length grows, even when the task itself stays equally difficult. The Chroma study isolated input length as the only variable and found degradation across leading models, with the sharpest losses when the needed information sat in the middle of a long, coherent document.
How much money does context engineering actually save?
It depends entirely on volume. Published benchmarks show optimised agents using roughly 2.68 times fewer tokens than full-context ones on the same 50-task set, and Anthropic's cache reads bill at 0.1x base input. In the worked example in this article, that is about $83 per 1,000 turns. At a few hundred turns a month the engineering time costs more than the tokens, so check your run rate first.
Do I need to know Python to do context engineering?
For the engineering half, yes. You will be writing retrieval code, counting tokens, shaping tool schemas and running evals, and Python is where the client libraries and evaluation tooling live. Deciding what belongs in the window is reasoning rather than syntax, but you cannot ship that design without the code.
Which certification covers context engineering?
None is named for it as of September 2026. The skills are distributed across agent-focused exams: tool use and agent design in the Claude developer and architect certifications, generative AI application development in Microsoft's AI-103, and evaluation and monitoring in AI-300. Treat it as a competence you demonstrate with a build, and use the certifications to structure the learning around it.
Is context engineering a real job title in India?
Rarely as a title, commonly as a requirement. Indian postings tend to advertise AI Engineer, GenAI Engineer or Agentic AI Engineer roles and then list retrieval design, agent orchestration, evals and token cost management in the responsibilities. Industry reports suggest demand for these skills is growing much faster than the supply of people who have shipped an agent to production.
If I were starting this week with a working agent and a rising bill, I would not touch compaction or sub-agents first. I would spend one afternoon counting tokens by component, then cut the tool list and move the stable prefix to the top for caching. Those two changes are hours of work, they carry almost no risk of breaking behaviour, and in most builds they recover the majority of the waste. Compaction policies and multi-agent splits are worth doing after that, once you have an eval set that can tell you whether they helped. If you would rather build that muscle with a live cohort and other people's mistakes to learn from, the AI Engineer course is the direct next step.
About this guide. 360 Digital Transformation is an Anthropic Partner and a Microsoft Authorized Training Partner. Other certification bodies, vendors and employers named here are not affiliated with us. Product features and pricing change often; figures cited were checked on 16 September 2026.
Python
Claude API
FAISS
ChromaDB
LangChain
LangGraph
CrewAI
AutoGen (AG2)
