Context engineering: how to control what an AI agent sees (and why it decides everything)

Context engineering is the deliberate design of the entire set of information a model sees on a given inference call, the instructions, the retrieved data, the tool outputs, the memory, and the conversation history, not just the wording of the prompt. It is the discipline that prompt engineering now sits inside, and it matters because agents behave differently from chatbots: they run for many steps, call tools, and accumulate context, so the window fills with material that crowds out the signal and degrades the model's decisions. The counterintuitive part, and the reason a bigger context window does not solve it, is that quality drops well before the window is technically full, and most long-running agent failures come from context drift and mismanagement, not from running out of raw space. So the job is to manage context as a budget, deciding what the model sees at each step, and this explains how.

‍

We build long-running agents where context discipline is the difference between one that works and one that quietly degrades, so this is a practitioner's view of context engineering and the moves that actually hold up in production.

‍

Why context is the problem, not prompt wording

Prompt engineering optimizes a single instruction you type. Context engineering manages the whole information environment an agent sees over a multi-step task, and for agents that is the bigger lever by far. The reason is accumulation: as an agent plans, calls tools, and reads results, its context grows every step, and a single verbose tool response or file dump can dwarf the entire useful dialogue. Left unmanaged, the window fills with noise, and the model's decisions get worse even though nothing errored. The 2026 signal is blunt: a large majority of IT and data leaders now report that prompt engineering alone no longer scales agent work.

‍

The critical, non-obvious fact is that filling a large window degrades quality rather than helping. Research has found threshold effects where, past a certain fraction of the maximum window, accuracy can fall sharply, a phenomenon widely called context rot, and it inflates cost and latency at the same time, since every token in the window is re-read and re-billed on each call. Coding agents are especially exposed, because they run long and pull in many distractor tokens. So a 1M-token window is not a fix; it is more room to accumulate noise. The teams getting reliable long-horizon agents are not the ones with the biggest window, they are the ones treating context as a managed budget with an explicit eviction policy, the same discipline you apply to a cache.

‍

The failure isn't running out of space, it's drift

The framing shift that matters most: context exhaustion is rarely what kills a long-running agent. Context drift is. Analysis of enterprise AI failures found that roughly two-thirds traced to context drift or memory loss during multi-step reasoning, not to hitting the raw window limit. The context was right when captured, the situation moved, and the agent kept acting on a stale or eroded picture. Bigger windows do not fix drift; smarter management does.

‍

There is a subtler failure too, context collapse, which appears when an agent repeatedly rewrites its own context. Each rewrite tends toward brevity and quietly drops domain detail, so over many iterations the context erodes and the agent loses the specific knowledge that made it useful. Recent research (the Agentic Context Engineering work presented at ICLR 2026) names this directly and proposes treating context as a collection of structured, itemized notes updated incrementally, rather than one block rewritten each time. The lesson under both drift and collapse is the same: context is not a passive buffer you fill, it is state you actively curate, and curating it badly degrades the agent even when the window never overflows.

‍

The four moves of context engineering

Production context engineering comes down to four techniques, and most real work is a combination of them:

• Write. Persist important state outside the context window, in memory, files, or a scratchpad, so the agent can recover it later without keeping it in the window the whole time. This is what stops the window from having to hold everything at once.
• Select. Retrieve only what is relevant to the current step and inject just that, rather than front-loading everything up front. This is retrieval done as context discipline, and its quality depends on retrieval quality, the failure modes we cover in why RAG fails in production.
• Compress. When history grows long, compact it into a high-fidelity summary so the agent continues with minimal loss. The art is compressing without dropping the one detail that matters three steps later, which is why good compaction preserves concrete identifiers, file paths, and decisions verbatim rather than paraphrasing them away.
• Isolate. Give each subtask its own clean context window by scoping work to separate agent processes. A supervisor decomposes a job and hands focused subtasks to workers, each with a narrow context, so the workers never see each other's noise and the supervisor sees only their results. This is the context rationale behind single-agent vs multi-agent design.

‍

The unifying idea is a context assembler: a budget-aware packer that decides, for each call, what the model actually needs to see, and drops or offloads the rest. Filter and truncate tool responses at ingestion, before they ever enter context, which is cheaper and higher-fidelity than compacting a window already bloated with noise. Keep the window small and high-signal, on purpose, every step.

‍

Context engineering is also cost engineering

The reason context discipline pays twice is that context is the bill. Every token in the window is re-read and re-billed on every call, so an agent that hoards context is an agent that hemorrhages money, the quadratic cost problem behind our $303,030 AI bill, where re-sending a growing context on each step was a major driver of the number. Smaller, well-curated context means fewer input tokens per call, which directly cuts spend and latency, and techniques like retrieval instead of front-loading, history compaction, and prompt caching can reduce token usage several-fold on long-running agents while improving accuracy, because the model is not distracted by irrelevant material.

‍

So context engineering and cost control are the same discipline seen twice: the move that keeps the window high-signal (less noise, better decisions) is the move that keeps the bill low (fewer tokens, less re-reading). This is why we treat context as a managed budget, it is simultaneously the reliability lever and the cost lever, and the levers point the same way. An agent with disciplined context is more accurate and cheaper at once; an agent that dumps everything into the window is less accurate and more expensive at once.

‍

Where context engineering sits

Context engineering is one layer in a progression teams now use to describe building on LLMs: prompt engineering (how you word the instruction), context engineering (what information the model sees), harness engineering (the environment the agent runs in), and loop engineering (the repeatable system that runs it), which we cover in harness engineering vs loop engineering. Context engineering is the layer that decides what enters the model on each call, and the harness is what implements that decision, the context selection, the memory, the tool-result filtering. They are tightly linked: a good harness is largely a good context assembler.

‍

This placement is why context engineering is a durable skill, not a workaround for a temporary window limit. Even as windows grow, effective performance degrades before the technical limit as a function of attention architecture, so the discipline persists. For anyone building agents, managing context well, the write, select, compress, isolate moves, is becoming the core competency that separates an agent that holds up over a long task from one that drifts, rots, and gets expensive.

‍

The takeaway

Context engineering is the deliberate design of everything a model sees on each call, and for agents it is the bigger lever than prompt wording, because agents accumulate context and quality degrades well before the window is full. The failures that matter are context rot (a too-full window) and context drift (a stale or eroded picture), not running out of space, so a bigger window does not fix it. The discipline is four moves, write, select, compress, isolate, unified by a budget-aware context assembler that keeps the window small and high-signal. And it is cost engineering too: disciplined context is more accurate and cheaper at once, because the tokens you do not send are tokens you do not pay to re-read. Manage context as a budget, or watch the agent drift and the bill climb.

‍

If you want long-running agents built with real context discipline, curated, budgeted, and cost-aware, that is where our AI Dev Team work starts.

‍

FAQ

What is context engineering? The deliberate design of everything a model sees on a given call, instructions, retrieved data, tool results, memory, and history, not just the prompt wording. It is the broader discipline that prompt engineering sits inside, and it is the main lever for agents that run many steps and accumulate context.

‍

How is context engineering different from prompt engineering? Prompt engineering optimizes a single instruction you type. Context engineering manages the entire information environment an agent sees across a multi-step task: retrieval, memory, tool results, history, and caching. Prompt wording is one component of context engineering, and for long-running agents it is the smaller lever.

‍

Why doesn't a bigger context window fix agent problems? Because quality degrades well before the window is technically full, a phenomenon called context rot, and filling a large window inflates cost and latency since every token is re-read on each call. Most long-running agent failures trace to context drift, not running out of space, and drift is fixed by management, not size.

‍

What are the core techniques of context engineering? Four moves: write (persist state outside the window), select (retrieve only what's relevant now), compress (compact history without losing key details like identifiers and decisions), and isolate (give subtasks their own clean context via scoped sub-agents). Most production work combines them under a budget-aware context assembler.

‍

How does context engineering affect AI cost? Directly. Every token in the window is re-read and re-billed on each call, so a bloated context drives cost up. Curating context, retrieval instead of front-loading, compaction, and caching, can cut token usage several-fold on long-running agents while improving accuracy, which makes context engineering and cost control the same discipline.