Context Engineering: 4 Techniques for Agents (2026)

The practical guide to feeding AI agents the right tokens, at the right time, for the right cost.

In one internal test, a workflow that consumed 150,000 tokens when every tool was loaded up front dropped to about 2,000 tokens when the agent loaded only what it needed, a 98.7% reduction - Anthropic. That single number captures why the discipline that AI builders spent 2026 obsessing over is not prompt writing. It is context engineering: the deliberate management of what an agent sees on every step of its loop.

Here is the problem that made this a discipline. The industry spent two years racing to bigger context windows, from a few thousand tokens to a full 1,000,000-token window now standard on frontier models - Anthropic. Yet bigger windows did not make agents reliable. They made them expensive and, counterintuitively, often worse. A model with a million-token window still degrades on a task at 50,000 tokens - Chroma Research. The window is not the bottleneck. The bottleneck is attention, and attention is finite.

This guide breaks down the four techniques every serious agent team now uses to work within that limit: Write, Select, Compress, and Isolate context. It starts from first principles (why more context makes agents dumber), then goes deep on each technique with real tools, real pricing, and real benchmarks from late 2025 and 2026. It covers the frameworks that implement these patterns, the token economics that decide whether an agent is profitable, and the honest counter-case: where context engineering is oversold and a better model beats clever plumbing. If you build agents, or you are deciding whether to build or buy them, this is the insider knowledge.

Contents

1. What Context Engineering Actually Is
2. Why More Context Makes Agents Worse
3. The Four Techniques: A Map
4. Technique One: Write Context Outside the Window
5. Technique Two: Select the Right Tokens
6. Technique Three: Compress Without Losing Signal
7. Technique Four: Isolate Context Across Boundaries
8. The Tooling Landscape: Frameworks and Memory Services
9. The Economics of Context: Tokens, Caching, and Cost
10. Where It Fails, and What Comes Next

1. What Context Engineering Actually Is

Context engineering is the practice of curating what goes into a model's context window at each step of an agent's run. Anthropic's own definition is precise: it is "the set of strategies for curating and maintaining the optimal set of tokens during LLM inference" - Anthropic. That sounds mundane until you realize how much lives in an agent's context on any given turn. There is the system prompt, the tool definitions, the message history, retrieved documents, memory, tool results, and the current user request. Every one of those competes for the same finite space, and every token you add changes how the model attends to every other token.

The term itself is young. It crystallized in mid-2025 when Shopify's CEO Tobi Lutke described it as "the art of providing all the context for the task to be plausibly solvable," and Andrej Karpathy endorsed it publicly a week later, calling it "the delicate art and science of filling the context window with just the right information for the next step." Karpathy's framing is the one that stuck, because he tied it to a mental model builders already understood: the LLM behaves like a CPU, and its context window behaves like RAM. The engineer's job is the operating system's job, deciding what to page into working memory for the task in front of you. LangChain adopted that same operating-system analogy in the post that became the field's reference text - LangChain.

The shift from prompt engineering to context engineering is not rebranding. Prompt engineering is a subset. Prompt engineering asks how to phrase a single instruction well. Context engineering asks a bigger question: given a constantly changing universe of possible information, what configuration of the entire context state produces the behavior you want, turn after turn - Anthropic. The reason the question changed is that agents changed. A one-shot chatbot answers once. An agent runs in a loop, and each loop generates more data (tool outputs, observations, intermediate reasoning) that might be relevant to the next step. Managing that growing state is a fundamentally different problem than writing a good prompt, and it is why practitioner Philipp Schmid could write that "most agent failures are not model failures anymore, they are context failures" - Philipp Schmid.

It helps to be concrete about what actually occupies an agent's context, because that inventory is the surface you are engineering. On any given turn the window holds the system instructions, the full set of tool definitions, whatever external data has been retrieved, the accumulated message history, memory, tool results, and the live request. Prompt engineering touches only the first of those. Context engineering touches all of them, and it treats even long-standing techniques as instances of the same practice. Retrieval-augmented generation, once discussed as its own discipline, is better understood as one flavor of context engineering, the part that selects external data to load. Framing it this way is not pedantic. It changes how you debug: when an agent misbehaves, you stop asking "was the prompt wrong" and start asking "what was in the window, and what should not have been." That single reframe is the reason the field renamed itself, and it is worth internalizing before any technique makes sense.

The best way to understand the discipline is to hear it from the people building production agents. In late 2025, Anthropic's Applied AI lead gave a conference session distilling what the team learned shipping long-running agents, including how they handle context-window limits, tool design, and the workflow-versus-agent distinction. It is the most authoritative single overview of the material this guide covers.

Why does this matter, and how do you apply it? It matters because context is the one lever you fully control. You cannot change the model's weights, but you decide every token it reads. Teams that treat that as an engineering surface (with budgets, tests, and instrumentation) ship reliable agents. Teams that treat the context window as an infinite bucket ship demos that fall apart in production. The rest of this guide is the toolkit for treating it as engineering, and it starts with understanding exactly why the bucket approach fails. If you are new to how agents work at all, our primer on making LLMs autonomous is a useful companion to what follows.

2. Why More Context Makes Agents Worse

The intuition almost everyone starts with is that a bigger context window is strictly better, because more information can only help. This intuition is wrong, and understanding exactly why it is wrong is the foundation of the entire discipline. The reason traces to the architecture of the transformer itself. Attention works by computing relationships between every pair of tokens, which means for n tokens the model maintains on the order of n-squared pairwise relationships. Anthropic frames the consequence as an attention budget: the model has a finite capacity to relate tokens to each other, and "every new token introduced depletes this budget by some amount" - Anthropic. Adding context is not free. It dilutes the model's ability to focus on what matters.

This is not just theory. The clearest empirical evidence is Chroma's Context Rot study, which held task difficulty constant and varied only input length across 18 frontier models. The finding was uncomfortable: every single model degraded as input grew, even on trivial tasks, and a model advertising a 1,000,000-token window still showed measurable degradation at around 50,000 tokens - Chroma Research. Worse, the effect is not gradual and predictable. Introducing even a single semantically similar distractor dropped accuracy below the baseline where only the answer was present. The study's blunt conclusion was that what matters is "how information is presented, not merely whether relevant information exists in context."

The texture of Chroma's results is what makes them persuasive, because the degradation appears even on tasks a child could do. In a probe that simply asked models to replicate repeated words, performance held at 25 to 100 words but degraded across every model past 500 words, and by 5,000 to 10,000 words models began emitting random tokens that were never in the input at all. Two other findings sharpen the warning for anyone building retrieval. First, models often did better on a shuffled haystack than on a logically structured one, which means the neat, coherent document you carefully assembled can hurt more than a jumbled pile. Second, hallucination rates varied by family, with some models staying conservative and others fabricating freely as context grew - Chroma Research. The practical reading is that context rot is not a rare edge case triggered near the limit. It is a smooth, always-on tax on reasoning that you pay from the very first thousand tokens.

Independent research reinforces the point from other angles. The NoLiMa benchmark, which strips out literal word overlap between a question and its answer to force real reasoning, found that of twelve models advertising 128,000-token context or more, eleven dropped below half of their short-context performance at just 32,000 tokens - arXiv. A separate 2025 paper made the failure even starker by showing that accuracy falls as context grows even when retrieval is perfect, with much of the damage happening within the first 7,000 tokens - arXiv. In other words, the problem is not that the model cannot find the right passage. The problem is that reasoning over a long context is harder than reasoning over a short one, full stop. This is why "advertised context length" and "effective context length" are two different numbers, and why our guide to what LLMs cannot do treats long-context reliability as a real constraint rather than a solved problem.

The degradation is not one failure but several, and the cleanest taxonomy comes from Drew Breunig, who named four distinct context failure modes that each require a different fix - Drew Breunig. Naming them precisely is what lets you design against them:

• Context poisoning: a hallucination or error enters the context and gets referenced repeatedly, compounding over time.
• Context distraction: the context grows so long the model over-focuses on its own accumulated history and stops reasoning freshly.
• Context confusion: irrelevant content in the window drags down output quality even when it is harmless.
• Context clash: newly retrieved information contradicts earlier context, and the model cannot tell which is authoritative.

These are not abstract. Context distraction has a measurable onset, with one analysis finding model correctness beginning to decline around 32,000 tokens on a large model and an agent beyond roughly 100,000 tokens starting to favor repeating past actions over planning new ones. Context clash is the most dangerous for anyone building retrieval, because pulling stale data from one source alongside current state from another forces the model to reconcile a conflict it has no way to adjudicate. When researchers deliberately fragmented prompts to mimic this accreted, contradictory context, one top model's score fell from 98.1 to 64.1, an effect that averaged a 39% performance drop across models tested. The practical lesson is direct: more context is a liability you manage, not an asset you accumulate. Every technique in this guide exists to keep the window small, relevant, and coherent. The shape of the fix looks like this.

3. The Four Techniques: A Map

Once you accept that the context window is a scarce resource, the question becomes how to manage it, and the field has converged on a strikingly clean answer. LangChain's Lance Martin organized every context-management pattern into four operations, and this taxonomy has become the shared vocabulary that engineers, labs, and framework authors all use - LangChain. The four are Write (save context outside the window), Select (pull only the right context in), Compress (retain only the tokens you actually need), and Isolate (split context across multiple agents or environments). Almost everything a sophisticated agent does with its context is one of these four, or a combination.

The elegance of the framework is that each operation attacks the finite-window problem from a different direction. Write says: do not hold what you can store elsewhere and retrieve later. Select says: do not load what you do not need this step. Compress says: keep the meaning, drop the bulk. Isolate says: give each unit of work its own clean window so no single context has to hold everything. They are complementary, and real agents layer all four. A coding agent might write its plan to a file, select only the relevant source files, compress its history when the window fills, and isolate a research subtask to a sub-agent, all in the same run.

The person who assembled this framework built it from hard experience shipping LangChain's own deep-research agent across hundreds of tool calls, and his talk walking through the four strategies is the reference explanation that the written guides, including this one, are downstream of. It is worth watching before you go deeper into any single technique, because it shows how the four fit together in a real system rather than as isolated tricks.

A visual map makes the relationships concrete. Everything descends from a single goal (curate the smallest set of high-signal tokens), and the four techniques are the branches beneath it.

Why start with the map before the details? Because the most common mistake teams make is reaching for one technique and ignoring the other three. A team drowning in retrieval complexity often needs compression, not better search. A team fighting runaway costs often needs isolation, not a cheaper model. Knowing the full menu lets you diagnose which of the four failure modes you are actually hitting and apply the matching operation. The next four chapters take each technique in turn, and each follows the same shape: the first principle behind it, the concrete tools that implement it in 2026, the numbers that show it working, and the way it fails when misapplied.

4. Technique One: Write Context Outside the Window

The Write technique rests on the simplest idea in the entire discipline: if you do not need something in the window right now, do not keep it there, store it somewhere the agent can reach it later. This directly attacks context distraction and cost, because anything you offload is a token that no longer dilutes the attention budget or gets re-read on every turn. The cheapest form is a plain file. Manus, one of the most-studied production agents, treats "the file system as the ultimate context: unlimited in size, persistent by nature, and directly operable by the agent" - Manus. Instead of holding a fetched web page in context, the agent keeps the URL and re-reads it if needed, a pattern of restorable compression where the pointer stays and the payload leaves.

A subtler variant of Write is recitation, and it is clever enough to deserve explanation. On a long task averaging around 50 tool calls, Manus rewrites a todo.md file every step, which continually pushes the current objectives to the very end of the context. Because attention is strongest on the most recent tokens, this fights the "lost in the middle" problem by keeping the global plan where the model actually looks. It manipulates attention with nothing but natural language and a file, no architecture change required. Anthropic formalizes the same instinct as structured note-taking, where "the agent regularly writes notes persisted to memory outside of the context window," using something as simple as a NOTES.md file that survives even when the rest of the context is reset - Anthropic.

Anthropic productized this pattern into a formal memory tool that is worth understanding because it shows how deliberately the write operation is engineered. The tool exposes a small, file-like command set (view, create, string-replace, insert, delete, and rename) operating on a /memories directory, and critically the backend is client-side, meaning the application controls the actual store and can audit every write - Anthropic. It pairs with a complementary feature called context editing, which automatically clears old tool results from the window once input crosses a configurable threshold that Anthropic suggests setting around 30,000 to 40,000 tokens. The two work as a matched pair: durable facts get written to disk while stale tool transcripts get evicted from the window, so the agent keeps what matters and sheds what does not. In 2026 this graduated to Memory for Managed Agents, which stores cross-session learnings as files with per-write audit logs and lets one agent share findings with another in the same workspace, directly answering the provenance problem that makes ungoverned memory dangerous.

Beyond files, 2026 brought a mature market of purpose-built memory systems, and the distinctions between them matter when you build. The foundational split is between short-term memory (state scoped to a single thread or session) and long-term memory (facts that survive across every future session), and the canonical memory types are semantic (facts about the user), episodic (summaries of past interactions), and procedural (the agent's own evolving instructions) - LangChain. These three are not interchangeable, and confusing them is a common design error. Semantic memory is what lets an agent recall that you prefer metric units. Episodic memory is what lets it recall how a similar task went last week and reuse the approach. Procedural memory is what lets it refine its own operating instructions over time. A support agent leans heavily on semantic and procedural memory, while a research agent leans on episodic recall of prior investigations, and a system that stores everything into one undifferentiated bucket retrieves noise. The leading systems each take a different architectural bet:

• Letta (formerly MemGPT) gives agents self-editing memory blocks that the model rewrites during its own reasoning loop, backed by Postgres and pgvector - Letta.
• Mem0 extracts and stores salient memories, then retrieves only what a query needs, reporting roughly 7,000 tokens per query instead of 25,000-plus for full context - Mem0.
• Zep builds a bi-temporal knowledge graph where every fact carries a valid-from and valid-to timestamp, so it can reason about what was true when - Zep.

Those architectural differences produce real performance differences, and this is where the hype filter matters. Mem0 self-reports strong benchmarks (roughly 92.5% on the LoCoMo memory benchmark and a 26% relative accuracy gain over one baseline while cutting token use around 90%) but these are vendor-published numbers - Mem0. An independent comparison tells a more nuanced story, ranking Zep's temporal graph at 63.8% against Mem0's 49.0% on the harder LongMemEval benchmark, a fifteen-point gap that reflects Zep's strength on time-aware reasoning - Stork. The honest takeaway is that there is no single winner: Mem0 tends to win on fast, cheap personalization, Zep on temporal reasoning, and Letta on owning a long-running agent's full runtime. Our deeper survey of AI agent memory architectures compares these systems in more detail.

Writing memory introduces its own failure modes, and ignoring them is how teams turn a helpful memory into a liability. The two big risks are stale memory and memory poisoning. Stale memory is the mundane one: a store keeps an outdated fact (a user's old preference, a superseded decision) and the agent treats it as authoritative because fresh context and old memory carry equal weight unless the system tracks validity time. This is precisely the problem Zep's temporal graph exists to solve. Memory poisoning is the dangerous one. A memory injection attack, sometimes called MINJA, writes malicious content into an agent's persistent memory so that it is later retrieved as trusted context, and researchers have demonstrated attack success rates above 90% in controlled settings - Future AGI. Because anything persisted gets re-injected as authority on every recall, a single bad write can survive its original session and steer every future run. This is why 2026 memory offerings emphasize audit logs and provenance, and why memory security belongs in the same conversation as our guide to prompt injection defense. Write context aggressively, but govern what you write.

5. Technique Two: Select the Right Tokens

If Write is about getting information out of the window, Select is about pulling exactly the right information back in at exactly the right moment, and no more. The first principle is the same finite-attention constraint seen from the other side: because every irrelevant token degrades reasoning, the goal of retrieval is not to find everything relevant but to bring in the smallest set that answers the current step. This reframes a lot of familiar machinery. Retrieval-augmented generation, the workhorse pattern of loading documents into context based on a query, is really just the Select operation applied to a knowledge base, and if you want the fundamentals our RAG primer covers them from scratch.

What changed in 2026 is that naive single-shot retrieval matured into a precise pipeline, because the quality of what you select turns out to depend heavily on how you search. Pure vector search, which matches on semantic similarity, misses exact identifiers and keywords. Keyword search using BM25 misses paraphrases and meaning. Hybrid retrieval fuses both, typically with reciprocal rank fusion, and the gain is not marginal: in one 2026 evaluation, pure vector search reached 78% recall, BM25 alone reached 65%, and hybrid fusion reached 91% - Denser. Layering a cross-encoder reranker on top, which re-scores the top candidates for relevance, pushed recall higher still and can improve production precision by 40% to 60% for under 200 milliseconds of added latency. The modern retrieval stack is therefore two-stage: hybrid retrieve a broad candidate set, then rerank down to the handful of chunks worth spending tokens on.

The reranking layer earns its place, but only in the right conditions, and knowing them saves you latency and money. Two-stage retrieval (hybrid retrieve, then rerank) reached a recall of 0.816 against 0.695 for hybrid fusion alone in the same evaluation, a meaningful lift - Denser. The nuance is that cross-encoder rerankers over-weight semantic similarity and can underperform on identifier-heavy queries like error codes or SKUs, which is exactly the gap that keyword search fills, so the two belong together rather than as substitutes. And when your base retriever already returns strong results (recall above roughly 0.9 in the top few hits) a reranker adds little beyond cost. The discipline is to measure your retrieval quality first and add the reranker where it moves the number, not reflexively. This is the Select technique's version of the guide's core lesson: every stage you add is a token and latency cost that must justify itself.

A newer pattern goes further and lets the agent control retrieval itself. Agentic RAG replaces the fixed, single-shot "retrieve once then generate" flow with a loop where the agent reasons about what it needs, picks a retrieval strategy, evaluates the results, and decides whether to search again with a refined query - Mem0. It is the retrieval-side expression of just-in-time context, and it closes the gap between static RAG and evolving memory. The same selection discipline even applies to the examples you put in a prompt. Rather than a giant static block of edge cases, retrieving a small set of examples semantically similar to the current query outperforms static prompting, with one study adding a further 7.3% F1 improvement from dynamic selection - Nature. Anthropic's guidance echoes this: use a small set of diverse, canonical examples, because "examples are the pictures worth a thousand words," and piling in every edge case is just another form of context bloat.

The deeper shift, though, is philosophical, and it is called just-in-time context. Instead of pre-loading everything an agent might need, you give it lightweight identifiers (file paths, stored queries, links) and let it pull the underlying content into context only at runtime, via tools. Anthropic frames this as mirroring human cognition: people do not memorize entire corpora, they use external indexing systems and fetch what they need. Their flagship example is Claude Code, which writes targeted queries, stores results, and uses commands like head and tail to analyze large datasets "without ever loading the full data objects into context" - Anthropic. The agent navigates a filesystem the way a human would, discovering structure through file names, sizes, and timestamps, rather than being handed a pre-embedded dump of everything. This is the retrieval-side expression of the same lean-window discipline, and it is why our overview of enterprise AI search treats retrieval as an active agent behavior rather than a static preprocessing step. It rests on the vector databases covered in our vector database starter guide and increasingly on the embedding models in our Gemini Embedding guide.

Selection applies to tools as much as to documents, and this is the part most teams underestimate. Every tool definition you attach to an agent occupies context and forces the model to consider it, so a bloated tool set is a selection problem in disguise. The evidence is direct: on the Berkeley Function-Calling Leaderboard, every model performs worse as more tools are added, and in one test a model that failed with all 46 tools present succeeded when limited to 19 - Drew Breunig. Anthropic's guidance is a useful heuristic: if a human engineer cannot definitively say which tool applies in a situation, an agent will not do better, so the fix is a minimal viable tool set plus dynamic retrieval of the right subset when the toolset is large. The most striking demonstration is Anthropic's code execution with MCP pattern, where presenting tools as code that the agent imports on demand, rather than loading every definition up front, cut one workflow from about 150,000 tokens to about 2,000, a 98.7% reduction - Anthropic. Applying retrieval directly to tool descriptions produces similar gains, with the RAG-MCP research more than tripling tool-selection accuracy from 13.62% to 43.13% while roughly halving prompt tokens - arXiv. The pattern is not a cherry-picked demo: an independent open-source stack of seventeen MCP servers measured a 75.5% reduction in context tokens on a public evaluation using the same load-on-demand approach - Greg Shevchenko, which is reassuring because reproducibility across teams is what separates a durable technique from a vendor slide.

The practical implication for anyone connecting an agent to many tools is that the Model Context Protocol and dynamic tool discovery are not conveniences, they are context-management necessities, a point our guides on the MCP 2026 spec and LLM tool gateways develop further. The unifying rule across documents, memories, and tools is the same: selection is an active, per-step decision, not a one-time setup. The danger to design against is context clash, where you retrieve contradictory or outdated content and force the model to reconcile it. That means deduplicating sources, preferring the authoritative one, and bounding how much you pull well below the window's nominal capacity. Select narrowly, select late, and select from a source you trust.

6. Technique Three: Compress Without Losing Signal

Even with disciplined writing and selecting, a long-running agent's context grows, and eventually it approaches the window limit. Compress is the technique for shrinking that footprint while keeping the signal, and its flagship form is compaction. Anthropic defines it cleanly as "taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary" - Anthropic. The art is in what the summary keeps. In Claude Code, compaction preserves architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs, then continues with that compressed summary plus the five most recently accessed files, which restores concrete working state the summary alone would blur.

This is now productized with real, current thresholds, which is useful to know if you are tuning an agent. Anthropic's Compaction API triggers by default once cumulative input crosses 150,000 tokens, configurable down to a 50,000-token minimum - Anthropic. Claude Code auto-compacts at roughly 95% of its 200,000-token window, producing a structured multi-section summary and re-injecting recent files under a 50,000-token cap. There is a hidden cost worth understanding: compaction is billed as an extra sampling step, because the model must read the entire prior context in order to summarize it, so a single compaction can consume around 180,000 input tokens on its own. You pay once to read everything, in order to shrink it. The safety bias Anthropic recommends is deliberate and worth copying: maximize recall first, then precision, because a compaction that silently drops a critical fact is unrecoverable, while leaving in some redundancy is cheap.

Compaction is not the only compression lever, and the lighter-touch options are often the right first move. Tool result clearing simply removes raw tool outputs deep in the history, since an agent rarely needs a raw payload again, reclaiming tokens with almost no summarization risk. LangGraph exposes compression as reusable pre-model hooks, including trim_messages to keep the last N tokens and a SummarizationNode that runs before every model call, with the common pattern layering a dense summary plus the last few turns kept in full - LangChain. For genuinely long tasks, Cognition built a dedicated fine-tuned model whose only job is to "compress a history of actions and conversation into key details, events, and decisions," and they are candid that this is "hard to get right" because deciding what counts as key in a long engineering trajectory is a specialized skill - Cognition. Our guide to long-running coding agents goes deeper on how these systems survive multi-hour tasks.

It helps to see compression as applied at three distinct seams rather than as one action, because each seam has its own least-destructive option. At the whole-trajectory seam, you summarize the full run, which is compaction. At the tool-output seam, you post-process a token-heavy result before it ever enters context, keeping the five relevant rows out of a ten-thousand-row response. At the inter-agent seam, you reduce what one agent hands to another. The tooling now spans a spectrum from crude to precise: simple trimming that drops the oldest messages is the cheap, lossy floor, while trained models like Provence, built specifically to prune context for question-answering, are the high-fidelity ceiling. In practice, coding agents layer these into tiers: a lightweight pass offloads bulky tool results to disk and keeps only a path reference, an automatic pass fires near the window limit with a structured multi-section summary (capturing intent, technical concepts, files touched, errors and fixes, and pending tasks), and a manual pass lets the operator compact at a clean task boundary. The design instinct across all of it echoes Manus's memorable rule, borrowed from concurrent programming: share memory by communicating, do not communicate by sharing memory.

The reason compression is not optional comes down to money, and specifically to the KV cache. Agents send a long, growing context each turn but emit short actions, an input-to-output ratio Manus pegs at roughly 100 to 1, which means almost all cost and latency lives in re-reading the prefix - Manus. Prompt caching makes re-reading cheap, but only if the prefix stays stable. Anthropic's caching prices a cache read at just 0.1x the base input rate, a 90% discount, while a cache write costs 1.25x for the five-minute tier and 2x for the one-hour tier - Anthropic. On a Sonnet-class model that is the difference between $0.30 and $3.00 per million input tokens, a tenfold gap.

This economics fact has a sharp design consequence that ties compression back to writing. Because attention is autoregressive, editing any earlier token invalidates the cache for everything after it, so aggressive mid-context summarization can forfeit the entire 90% discount on the tail. That is why the best practitioners favor append-only, restorable compression: keep a pointer (a URL, a file path, a tool-call id) rather than rewriting history in place, so you can re-fetch what you dropped without breaking the cache. It is also why Manus argues, counterintuitively, for keeping some failures visible in context rather than compressing them away, since the evidence of a mistake is what stops the model from repeating it.

The trade-off to hold in mind is that compression is lossy by definition, and its errors compound. Anthropic's own warning is that "overly aggressive compaction can result in the loss of subtle but critical context whose importance only becomes apparent later." The mitigation is layered: prefer restorable pointers over summaries, clear raw tool results before you summarize reasoning, and provide an escape valve (Anthropic's compaction API offers a pause hook that re-inserts specific recent messages verbatim) so a lossy summary can never silently erase immediate task state. Compression buys you room and cost savings, but you spend it carefully, recall first.

7. Technique Four: Isolate Context Across Boundaries

The fourth technique gives up on fitting everything into one window and instead splits context across boundaries so that each unit of work sees only what it needs. The first principle is that a single shared window couples every failure mode together, whereas a boundary the model cannot see across can quarantine bulk, cost, and even conflicting decisions. There are three concrete forms of isolation, and understanding when each helps is the difference between a system that scales and one that thrashes.

The most visible form is multi-agent isolation, where a lead orchestrator decomposes a task and spawns sub-agents that each work in their own clean context window and return only a condensed summary. Anthropic's research system is the canonical example: each sub-agent might burn tens of thousands of tokens exploring one thread, but returns just 1,000 to 2,000 tokens to the orchestrator, and the architecture outperformed a single agent by 90.2% on an internal research evaluation - Anthropic. The catch is cost. That same system used roughly 15x more tokens than a normal chat, and token usage alone explained about 80% of the performance variance, which means multi-agent isolation is really a way of spending far more tokens in parallel. It pays off for high-value, breadth-first work and is uneconomical for everything else. Our guide to Claude Code subagents and our broader multi-agent orchestration coverage go deeper on wiring these fleets.

The second form is sandboxed execution, which isolates bulky data in a runtime instead of in a second agent. When an agent writes code that runs in a sandbox, the large intermediate results (a 10,000-row spreadsheet, a raw API response) live as variables in that runtime and never enter the model's context, so only the filtered result returns. HuggingFace's smolagents builds its CodeAgent on exactly this idea, and reports that expressing actions as code takes roughly 30% fewer steps than emitting JSON tool calls, which translates directly into fewer tokens - HuggingFace. The third form is the state object, the least flashy but most broadly useful. Frameworks like LangGraph let you design a state schema where some fields hold context that the LLM is never shown unless explicitly surfaced, so a sub-graph can keep private working notes and return only its final message to the parent. OpenAI's Agents SDK implements a related idea through handoffs, where what context crosses to the next agent is filterable rather than dumped wholesale - OpenAI. The elegance of the sandbox variant is worth dwelling on: because the agent writes code, it can store the output of one action as a variable and reuse it later without that object ever passing through the model, so a generated image or a large array lives in the runtime's state rather than the context window. Google's Agent Development Kit pushes the same idea structurally, modeling a system as a tree of typed agents where context is isolated per node and composed up the tree - Google.

The cost of isolation is always tokens, and the numbers make the trade-off legible. Anthropic reports that even a single agent uses roughly 4x more tokens than a plain chat, and a multi-agent system about 15x more, which is why it reserves the pattern for high-value work where information genuinely exceeds one context window - Anthropic. A subtle but important detail is that in these systems the sub-agents do not know the others exist. Each gets a self-contained task, an output format, and a fresh window, and returns a distilled result. That deliberate blindness is exactly what makes parallelism cheap to coordinate, and it is also exactly what makes it dangerous when the pieces have to fit together, which is the crux of the debate below.

Isolation is genuinely contested, and this is the most important debate in agent architecture right now, so it is worth presenting fairly rather than picking a side. Cognition's widely read argument, titled bluntly Don't Build Multi-Agents, holds that parallel sub-agents fail because "actions carry implicit decisions, and conflicting decisions carry bad results" - Cognition. Their memorable example is two sub-agents building one app where one produces a Mario-style background and the other a mismatched bird, because neither could see the other's implicit choices. The summary that crossed the boundary dropped exactly the context needed to stay consistent. A year later, Cognition softened the position, noting they had "found some setups that actually work," but only under a strict rule: keep the writes single-threaded and let extra agents add intelligence, not conflicting actions - Cognition.

That evolution points to the clean design rule the field converged on, and it is the one practical thing to remember from this chapter: isolate the reads, single-thread the writes. Isolation is safe and powerful when the isolated work is independent and non-mutating, which is why it shines for breadth-first research where sub-agents pursue separate directions whose intermediate state no one else needs to agree on. Isolation is dangerous when multiple agents must converge on one evolving artifact, which is why Anthropic itself flags that most coding tasks, with their tight interdependencies, are a poor fit for naive multi-agent splitting. The technique does not make the window bigger. It ensures each boundary transmits only what the receiver needs to decide its next step, and the skill is knowing which work can safely live behind a wall.

8. The Tooling Landscape: Frameworks and Memory Services

Understanding the four techniques is one thing, implementing them is another, and by 2026 a substantial tooling layer exists to do the plumbing. At the orchestration level, the frameworks differ mainly in how they model state, which is the context object your agent carries. LangGraph reached its 1.0 general-availability release in October 2025 with a directed-graph runtime built around typed state and checkpointing, where state is the durable context and checkpoints enable resume and time-travel - LangChain. LlamaIndex favors explicit, event-driven workflows with a separate Context store and Memory class, and tends to win when documents are the hard part. OpenAI's Agents SDK manages context through Sessions (automatic history), Handoffs (delegation), and a Context dependency-injection object - OpenAI. Others in serious use include Microsoft's AutoGen, CrewAI, Google's Agent Development Kit, Pydantic AI, and HuggingFace smolagents.

Raw popularity can mislead here, so it helps to separate legacy reach from live usage. By accumulated GitHub stars, AutoGen leads at around 60,000, followed by CrewAI at about 57,000 and LangGraph at roughly 40,000 - Spheron. But stars reflect years of accumulated attention, and AutoGen is now in maintenance mode. A better proxy for what teams actually run in production is package downloads, where LangGraph dominates at about 38.8 million monthly installs. The lesson for anyone choosing a framework is to weight current momentum and fit over historical star counts, a theme our LangGraph vs CrewAI vs AutoGen comparison develops in depth.

Beyond the headline numbers, each framework encodes a different philosophy of context, and matching that philosophy to your problem matters more than the star count. CrewAI, which reports handling roughly two billion agent executions in a trailing year across 150-plus enterprise customers, models work as role-playing crews and is popular for quick multi-agent prototypes - Spheron. Pydantic AI treats type-validated structured output as its context-integrity mechanism, reaching a 2.0 release in 2026 with strong download momentum, and is favored where correctness of the agent's outputs is the hard part. LlamaIndex defaults to stateless, event-driven workflows where state is explicit through a Context store, which tends to win when documents and retrieval are the center of gravity. The takeaway is not that one framework is best but that the right question is architectural: does your problem need durable typed state (LangGraph), document-heavy retrieval (LlamaIndex), output correctness (Pydantic AI), or fast role-based fan-out (CrewAI). Our LangChain alternatives coverage maps this territory in more detail.

For the Write technique specifically, a market of memory-as-a-service products now handles persistence, retrieval, and governance so you do not have to build it. Their pricing reveals what actually costs money in a memory system, which is worth studying before you buy. The table below reflects late-2026 published pricing.

Those pricing shapes are informative. Mem0 bills on write and read operations because memory cost is dominated by extraction and vector search, not seats. Zep meters on messages ingested and data volume because building the graph is the expensive step. Letta prices per stateful agent because its model is long-lived agents that each own their memory. Underneath all of them sits a vector database for the Select technique, and the 2026 market runs from Pinecone (Builder at $20 per month, Standard from $50) through Weaviate (from $25) to Chroma and Turbopuffer, with the object-storage-backed options targeting low cost at scale - Groovy Web.

There is a strategic choice hiding in all this tooling, and it is the build-versus-buy decision that defines most agent projects. Assembling LangGraph plus a memory service plus a vector database plus a compaction strategy gives you full control, but it is real engineering, and much of it is undifferentiated plumbing. The alternative is a managed platform that handles the context engineering for you. Platforms like O-mega, which builds and operates an autonomous company through a single conversation, absorb the memory, retrieval, compaction, and sub-agent isolation so an operator can describe an outcome rather than wire up a state graph, in the same way a managed database frees you from running your own storage engine. It is one option among many, and the right choice depends on how much of the context stack you want to own versus how fast you want to ship. Whichever path you take, the same four techniques are running underneath, whether you built them or rented them.

9. The Economics of Context: Tokens, Caching, and Cost

Context engineering is ultimately an economic discipline, because the thing you are managing (tokens) is the thing you are billed for. Getting the economics right starts with knowing the current prices, which move constantly, so these figures are verified as of September 2026. The frontier lineup and its per-million-token pricing looks like this, and the spread across tiers is the first lever you pull.

Anthropic's pricing is the primary source for the Claude figures - Anthropic, Google's for Gemini - Google, and the GPT-5.6 figures are indicative from pricing aggregators rather than a primary page. The single most important structural change in 2026 was that the full 1,000,000-token context window went generally available at standard pricing, with no long-context premium on current Claude models, so a 900,000-token request now bills at the same per-token rate as a 9,000-token one - Anthropic. You might expect that to kill context engineering by making big windows cheap. It did the opposite, because context rot means a full window still degrades accuracy even when it is affordable, so teams curate the window for quality even when cost no longer forces them to. For a broader price comparison, our cheapest LLM APIs price table and best LLM for agents ranking track the moving numbers.

Two pricing subtleties trip up cost models and deserve a flag. First, some providers still meter long context in tiers even where others have flattened it, with Gemini's Pro line charging more per token above a 200,000-token threshold than below it - Google, so a naive per-token estimate understates the cost of a genuinely large window on those models. Second, tokenizers changed, and newer Claude models produce meaningfully more tokens per unit of text than their predecessors, which means a raw price cut does not always translate into a proportional bill cut. The reason this level of adoption detail matters is that context engineering stopped being an academic exercise the moment agents reached production at scale. LangChain's late-2025 survey of 1,340 practitioners found 57% of teams now run agents in production, up from 51% the prior year and rising to 67% among organizations above ten thousand employees, with customer service, research, and internal workflow automation leading the use cases - LangChain. Real deployments hit the context-rot and cost walls that demos never do, which is precisely why the tooling matured so fast.

The second lever, and the one that separates profitable agents from unprofitable ones, is caching, which the Compress chapter introduced and which deserves its own economic framing. Because an agent re-sends a growing prefix every turn at a 100-to-1 input-to-output ratio, the cache-read discount of 0.1x base input is not a minor optimization, it is the difference between a viable product and a money pit. This is why Manus calls the KV-cache hit rate "the single most important metric for a production-stage AI agent." The practical rules follow directly from the pricing: keep your system prompt and tool definitions stable so they stay cache-hot, append rather than edit so you do not invalidate the tail, and batch non-urgent work through the Batch API for a further 50% discount. The third lever is model routing, sending cheap steps to a small model and hard steps to a flagship, which our guide to cutting agent costs with model routing covers as a direct application of the same token economics.

Watching these levers work together is easier with a concrete comparison, because the whole point of external memory is to avoid replaying a full history on every turn. When a memory layer retrieves only the relevant slice of a conversation instead of the entire transcript, the token savings are large and repeatable.

A worked example makes the stakes concrete. Picture a support agent that runs 30 turns, carrying a growing context that averages 40,000 input tokens per turn on a Sonnet-class model. With no caching and no compaction, that is 30 turns times 40,000 tokens at the full $2 to $3 per million input rate, and the bill climbs turn over turn because the whole history is re-read every step. Turn on prompt caching for the stable prefix and most of those input tokens re-read at the 0.1x rate, collapsing the dominant cost by roughly ninety percent on the cached portion. Add compaction at the window's midpoint and the per-turn token count stops growing without bound, capping both cost and the context rot that would otherwise erode accuracy near the end of the conversation. Add a memory layer and each turn retrieves a few thousand relevant tokens instead of replaying the full transcript. None of these is exotic. Each is one of the four techniques applied deliberately, and stacked, they are the difference between an agent that costs pennies per conversation and one that quietly loses money on every session. That is why the economics are not a footnote to context engineering. They are the reason it exists as a discipline.

Before you take vendor token-savings numbers at face value, it helps to hear the economics debated by the people who live it, which is what makes the LangChain and Manus discussion below valuable. It pairs a framework author with a production agent builder on exactly these trade-offs: when to compress, when to isolate, and how cache economics shape both.

Why does this level of economic detail matter for a non-specialist deciding whether to invest in agents? Because the difference between an agent that costs cents per task and one that costs dollars is almost entirely context engineering, not model choice. Two teams running the same flagship model on the same task can see a tenfold cost gap depending on cache discipline, compaction thresholds, and how narrowly they select context. The model is a fixed input price. The context is the variable you optimize, and it is where the margins live. Understanding that is what turns an agent from an impressive demo into a business that survives contact with a monthly bill, a reality our analysis of why most agent pilots never scale returns to repeatedly.

10. Where It Fails, and What Comes Next

An honest guide has to make the case against its own subject, and there is a real case against context engineering. The first critique is that it can simply relocate complexity rather than remove it. Building reliable retrieval, memory, and compaction re-introduces the exact ranking, freshness, and conflict-resolution problems that a big context window was supposed to abstract away. A practitioner guide put the tension crisply: an agent may perform worse with a 100,000-token codebase summary than with a 5,000-token targeted retrieval, yet building that targeted retrieval reliably is its own hard system - Sourcegraph. You do not escape complexity, you move it, and sometimes the move is not worth it.

There is a deeper version of this critique that should humble anyone selling retrieval as the fix. Research in 2025 decoupled two things people assume move together: whether the right information was retrieved, and whether the model reasoned over it correctly. On some tasks, retrieval scores stayed flat or even rose as context grew while answer accuracy kept falling - arXiv. In plain terms, "we found the right passage" and "the model used it correctly" are separate problems, and better search only solves the first. This is why the multi-agent debate matured rather than resolved: both camps are right about different regimes, and the field settled on a nuanced rule (isolate independent reads, keep shared writes single-threaded) rather than a universal verdict. Anyone who tells you there is one correct architecture has not built enough of them.

The second critique is more pointed: model progress erodes hand-built context plumbing. Anthropic reported removing over 80% of Claude Code's system prompt for its newest models "with no measurable loss" on coding evaluations, because newer models infer from surrounding context what older models needed spelled out - Anthropic. Every elaborate prompt scaffold and retrieval workaround carries a risk that the next model release makes it unnecessary. This is the strongest version of the "just use a better model" argument, and it is often right for the parts of your plumbing that exist to compensate for model weakness rather than physical token limits. The durable techniques are the ones rooted in the finite-window constraint (isolation for tasks that exceed one window, caching for cost) rather than the ones patching a temporary capability gap.

The third and most sobering critique is that the binding constraint on agent value is usually not context quality at all, but organizational integration. MIT's 2025 study found that 95% of enterprise generative-AI pilots delivered no measurable profit-and-loss impact, attributing the failures primarily to a learning gap and workflow misalignment rather than model or context quality - MIT via Legal.io. Gartner separately predicts that over 40% of agentic AI projects will be canceled by the end of 2027 on cost, unclear value, or weak risk controls - Gartner. The implication is not that context engineering is useless, but that it is necessary and not sufficient. Perfect token curation on a workflow nobody adopts still returns nothing. This is the honest frame our coverage of agent ROI insists on, against a market full of inflated claims.

So where does this leave the field, reasoned from first principles rather than hype? The underlying constraint is not going away. Attention is quadratic, context rot is a property of how transformers work, and no amount of window enlargement changes the fact that reasoning over more tokens is harder than reasoning over fewer. That means the four techniques are durable even as their implementations churn. What is changing is who does the work. In 2025, context engineering was manual: humans wrote compaction prompts, tuned retrieval, and designed state schemas. The clear 2026 trajectory is toward agents that manage their own context, deciding when to compact, what to remember, which tools to load, and when to spawn a sub-agent, with the human setting policy rather than pulling every lever. Anthropic's context-editing and memory tools, LangGraph's built-in hooks, and the self-editing memory of systems like Letta are all early steps toward context management becoming an autonomous behavior rather than a hand-tuned pipeline.

If you are deciding what to do with all of this, here is a decision framework built from the whole guide. If you are experimenting or building a single-purpose agent, start with the cheapest techniques (structured note-taking, tool-result clearing, a minimal tool set) and add complexity only when you hit a measured wall, not preemptively. If you are running a long-horizon or multi-step agent, invest early in compaction and caching discipline, because that is where cost and reliability are won or lost. If your task is genuinely breadth-first and high-value, adopt isolation through sub-agents, and accept the token multiple as the price of parallelism. And if the context stack is undifferentiated plumbing for your business, seriously weigh a managed platform against building it yourself, because the four techniques run the same whether you own them or rent them. The teams that win in 2026 are not the ones with the biggest windows. They are the ones who treat every token as a decision.

This guide was written by the team at O-mega, whose founder Yuma Heymans (@yumahey) has spent years building agents meant to run over long horizons rather than answer a single prompt. Before O-mega, he co-founded HeroHunt.ai, one of the earliest fully autonomous recruiting agents, where the recurring lesson was that the hard problem was rarely the model and almost always what you fed it, turn after turn, which is the entire premise of context engineering. For the broader picture of how these agents get built and shipped, our insider guide to building AI agents and our Claude Agent SDK deep dive pick up where this one leaves off.

This guide reflects the AI agent and context-engineering landscape as of September 2026. Model names, pricing, benchmarks, and tooling in this space change rapidly, so verify current details against the primary sources linked throughout before making build decisions.