Definition: Context Engineering
Context engineering is the discipline of curating the data, tools, instructions, and memory that an AI system sees at each step of its work, treating the large language model context window as scarce working memory rather than an open canvas.
Core characteristics of context engineering
Context engineering operates across the entire lifetime of an agent run, not at a single prompt boundary, and changes the contents of the context window dynamically as new evidence arrives.
- Dynamic context assembly tuned to the current step rather than a static prompt
- Explicit budget for tokens spent on instructions, tools, retrieved data, and memory
- Memory across turns through summarisation, scratchpads, and external state
- Tool descriptions and outputs treated as context that competes with everything else for space
Context Engineering vs. Prompt Engineering
Prompt engineering crafts a single instruction string that the model sees. Context engineering decides everything that surrounds that instruction: which retrieved documents are attached, which tool definitions are exposed, which past turns are kept, which are summarised, and which are dropped. Andrej Karpathy framed the difference in mid-2025 by describing the LLM as a CPU and its context window as RAM that must be filled deliberately. The shift matters because every industrial-strength agent fails the same way when the context window fills with low-signal content: hallucinations rise, tool use degrades, and latency climbs.
Importance of context engineering in enterprise AI
Context engineering is now the practical bottleneck on production AI agent quality. Anthropic’s September 2025 engineering note, which described context engineering as the natural progression of prompt engineering, reports gains of up to 54% on agent benchmarks when ad hoc prompt stuffing is replaced with deliberate context curation.
Methods and procedures for context engineering
Enterprise context engineering combines four canonical strategies that map directly to common agent failure modes.
Write context
Write context covers everything the agent persists outside the live window: scratchpads it writes to during reasoning, structured memory updates it commits at session end, and audit logs it leaves for review.
- Scratchpad notes that capture intermediate reasoning between tool calls
- Structured memory updates committed to a persistent store at session end
- Audit log of every context change for evaluation and rollback
Select context
Select context decides what to pull into the window for the next step: the right documents from a retrieval-augmented generation store, the right past turns from session memory, the right tool subset for the current intent. Selection quality usually matters more than retrieval recall, because every irrelevant token dilutes the signal that matters.
Compress and isolate context
Compress turns long histories into shorter summaries that preserve the few facts the agent needs, freeing room for fresh evidence. Isolate splits work across sub-agents or sandboxed contexts so that noisy intermediate state does not pollute the final decision. Both are essential once an agent runs more than a handful of turns or operates on long-running tasks.
Important KPIs for context engineering
Context engineering programmes report against operational, strategic, and quality metrics that connect token economics to agent performance.
Operational performance metrics
- Context utilisation: target 60-80% of the window used per step, not 95-100%
- Tokens per task: target 30-60% reduction versus naive prompt stuffing
- Tool relevance: percentage of exposed tools the agent actually uses per task
- Retrieval precision at k: percentage of retrieved chunks the agent cites
Strategic business metrics
The business case for context engineering rests on doing more with the same model spend. Anthropic’s reported 54% benchmark gain through context engineering translates directly into either lower inference cost at the same accuracy or higher accuracy at the same cost, both of which compound across high-volume production deployments.
Quality and reliability metrics
Quality measurement uses AI evaluation on a fixed regression suite: hallucination rate by intent, tool-use accuracy, and grounded-answer rate before and after context changes. The deciding metric is whether a deliberate context change improves the eval score without degrading any other metric.
Risk factors and controls for context engineering
Context engineering carries specific failure modes that require explicit guardrails.
Context overflow and lost-in-the-middle
When the window fills past a model’s effective comprehension band, accuracy drops even though the prompt still fits the technical limit.
- Hard token budgets per context category (instructions, tools, retrieved data, memory)
- Test on long-context inputs, not just short ones, in the regression suite
- Track accuracy as a function of context length, not just average score
Stale and conflicting memory
Memory that survives across sessions can carry outdated facts or conflicting summaries that the agent then trusts. Mitigation includes versioned memory entries, freshness scoring, and explicit conflict-resolution prompts when two memory sources disagree.
Sensitive data leakage through context
Context windows aggregate data from many sources, which can quietly mix customer, employee, and regulated information into a single LLM call. Treat the context window like a database query: minimise the data pulled in, mask before retrieval where possible, and log every retrieval against the knowledge management source so DSGVO and audit obligations remain provable.
Practical example
A mid-sized DACH Maschinenbau service operation rebuilt the prompt-stuffing pipeline behind its dispatch agent into a context-engineered system. Previously every dispatch decision concatenated the full customer history, all open work orders, and the entire spare-parts catalogue into the window, so the agent often missed the relevant SLA clause. The new pipeline retrieves only the customer’s last three relevant tickets, the SLA clause that applies to the current product line, and the parts inventory for the technician’s region, leaving 60% of the window free for the agent’s reasoning and tool calls.
- Per-step retrieval policy for tickets, SLA clauses, and inventory by product family
- Token budget enforced across instructions, tools, and retrieved data
- Persistent memory of dispatch decisions for end-of-shift review
- Evaluation harness scoring context changes against a 200-case regression suite
Current developments and effects
Context engineering moved from blog post to operational standard between Q3 2025 and Q2 2026.
From prompt libraries to context pipelines
Enterprises have stopped building reusable prompt libraries and started building reusable context pipelines that decide what to retrieve, what to compress, and what to drop per step.
- Pipeline templates for common agent shapes (research, dispatch, support)
- Context routers that pick a retrieval strategy by intent
- Token-budget gates that block runs whose context exceeds the budget
Long context windows do not eliminate the problem
Million-token windows from Gemini and Claude make naive prompt stuffing technically possible but operationally expensive and quality-degrading. Context engineering remains the determining factor in agent reliability even at million-token scale, because attention does not scale linearly with window size.
Context as a procurement specification
Enterprise procurement is starting to specify context engineering practices in agent vendor evaluations, treating documented context budgets, retrieval policies, and memory governance as evidence of production readiness rather than research curiosity.
Conclusion
Context engineering is the lifecycle discipline that determines whether a production AI agent is reliable, affordable, and auditable in 2026. The four canonical strategies (write, select, compress, isolate) replace the prompt-stuffing patterns that dominated the early prompt engineering era. Enterprises that treat the context window as scarce working memory ship agents that survive scale and audit; those that treat it as an open canvas ship agents that pass the demo and fail the quarterly review. As long-context windows grow, the discipline becomes more, not less, important: the question shifts from what fits to what should be there.
Frequently Asked Questions
What is context engineering and how does it differ from prompt engineering?
Context engineering is the practice of curating everything the model sees at each step, not just the instruction text. It treats the context window as scarce working memory and fills it dynamically with documents, tools, and memory tuned to the current decision. Prompt engineering writes the instruction; context engineering decides what surrounds it.
Why has context engineering become the dominant skill for AI agents?
Production AI agents fail when the context window fills with low-signal content: hallucinations rise, tool use degrades, and latency climbs. Anthropic’s September 2025 engineering note reports up to 54% benchmark gains when context engineering replaces ad hoc prompt stuffing, and that pattern matches what enterprises see in their own production traffic.
What are the four canonical strategies of context engineering?
Write, select, compress, and isolate. Write covers persisted scratchpads and memory; select covers what is pulled into the window; compress turns long histories into short summaries; isolate splits work across sub-agents so noisy state does not pollute the final decision. Most production agents use all four.
Do million-token context windows make context engineering unnecessary?
No. Million-token windows from Gemini and Claude make naive prompt stuffing technically possible but operationally expensive and quality-degrading. Attention does not scale linearly with window size, and lost-in-the-middle effects appear well before the technical limit. Context engineering remains the determining factor in agent reliability at any window size.
How is context engineering measured?
The standard pattern is a regression suite that scores hallucination rate, tool-use accuracy, and grounded-answer rate before and after every context change. Operational metrics include context utilisation per step (target 60-80%), tokens per task, and retrieval precision at k. The deciding question is whether a context change improves the eval score without regressing any other metric.
Does context engineering replace retrieval-augmented generation?
No. Retrieval-augmented generation is one method that lives inside context engineering. Context engineering decides which retrieved chunks make it into the window, which past turns to keep, which tools to expose, and how much room to leave for the model’s reasoning. RAG provides candidates; context engineering selects and budgets them.
