Context Engineering: The Skill That Replaced Prompt Engineering

Your agent works flawlessly for the first ten turns. By turn thirty it starts repeating work it already did, forgets a decision it made twenty tool calls ago, and contradicts itself without blinking. And the strange part is the prompt is polished down to the last word. The problem isn’t what you wrote — it’s everything else that piled up in the window along the way. In 2026, the skill that separates the people who direct agents from the people who suffer them is no longer writing the perfect prompt. It’s governing what the model sees at every moment. That’s context engineering.

What Is Context Engineering (and What It Isn’t)?

Context engineering is the set of strategies for selecting and maintaining the optimal set of tokens a model sees during inference — including all the information that ends up in the window that you didn’t write as a prompt. That’s almost verbatim Anthropic’s definition ^[1]. The key is in the last two words: outside of the prompts. The prompt is part of what goes in; it isn’t everything. And part of what goes in, you didn’t even write yourself: the instructions from an installed skill or the tool definitions from an MCP server are also third-party tokens in your window — a flank I cover in skills and MCP supply-chain security.

Andrej Karpathy summed it up better than anyone: it’s “the delicate art and science of filling the context window with just the right information for the next step” ^[2]. Tobi Lütke, CEO of Shopify, prefers the term over “prompt engineering” because it better describes the core skill: giving all the context necessary to make a task “plausibly solvable by the LLM” ^[2]. And the Cognition team, who build Devin, take it into operational territory: doing this automatically in a dynamic system is “the #1 job of engineers building AI agents” ^[3].

Let’s be clear about what it is NOT. It is not writing a longer prompt. It is not dumping the entire project’s documentation into the system prompt “just in case.” That very reflex is exactly what degrades the agent.

Prompt Engineering vs. Context Engineering: Instance vs. System

The difference is one of time horizon, not difficulty. Anthropic defines prompt engineering as the methods for writing and organizing instructions that produce the best result ^[1]: you optimize one instruction, once, for one outcome. Context engineering governs what the system assembles at every step of the loop: instructions, history, tool results, memory notes, and subagent outputs. You write the prompt. Your system builds the context, turn after turn — and that’s where it degrades.

Dimension	Prompt engineering	Context engineering
What it optimizes	the instruction: wording, examples, format	the total set of tokens the model sees
Horizon	a single instance, one message	a system over time, every step of the loop
Artifact	the prompt	the entire window: instructions, history, tool results, memory, and subagent outputs
Typical failure	a poorly steered response on the first turn	accumulated degradation: context rot, forgotten decisions, runaway cost
Relationship	subset	superset: the prompt is one part of what enters the window

This doesn’t retire prompt engineering. Everything you knew about writing clear instructions still holds, and you’ll find it collected in the essential prompt engineering patterns — it’s just now one piece within a bigger problem. That “system over time” is the agentic loop, where context grows and rots turn by turn. If you want the mental model for the loop, I develop it in loop engineering.

Why Isn’t More Context Better Context?

Because the model doesn’t read the window uniformly, and there’s hard evidence for it. The “Lost in the Middle” paper (Liu et al., 2023) showed that performance is highest when relevant information sits at the beginning or end of the context, and “significantly degrades when models must access relevant information in the middle of long contexts” ^[4]. It’s a U-shaped curve: whatever you put in the middle of a long context, the model looks at worse.

This isn’t a 2023 artifact. Chroma’s Context Rot report evaluated 18 current models, including GPT-4.1, Claude 4, and Gemini 2.5, and concluded that their performance “grows increasingly unreliable as input length grows” ^[5]. One of its findings is especially uncomfortable: on LongMemEval, Claude models performed better with focused prompts than with full prompts containing the same relevant information. Same useful data, more noise around it, worse result.

Anthropic frames it well: models have a finite “attention budget,” much like human working memory, so context is “a finite resource with diminishing marginal returns” ^[1]. When the window grows too large, context rot sets in: the more tokens it accumulates, the worse the model recalls the information it contains ^[1].

Treat the window as working memory, not a hard drive. That’s the position of this whole post: context is a budget you spend with every token, not a warehouse to stockpile just in case. If the context window still feels like a somewhat abstract concept to you, the fundamentals are covered in the context window and best practices, and the AI Agent Design Patterns course lets you practice it interactively alongside the rest of the LLM fundamentals.

The Economics of Context: What Every Token Costs

Context doesn’t just degrade quality — it costs money, and in counterintuitive ways. With prompt caching, reading from cache costs 0.1× the input price, but writing to it costs 1.25× for a 5-minute TTL and 2× for a 1-hour TTL, according to Anthropic’s official pricing ^[6]. Reusing cached context is dirt cheap, but every time you break the cache, you pay a premium to write it again.

That’s why Manus, after building a production agent, states that “the KV-cache hit rate is the single most important metric for a production-stage AI agent” ^[7]. With Claude Sonnet they put a number on it: a cached input token costs $0.30/MTok versus $3/MTok uncached — a 10× difference. And the detail that makes it truly expensive: at Manus, the average input:output ratio runs around 100:1, and a typical task requires about 50 tool calls ^[7]. Every turn resends the entire prior history. Input dominates the bill.

The design implication is direct: append-only context and a stable prefix. Any byte that changes at the start of the context invalidates the cache for everything that follows. A senior engineer recognizes this instantly — it’s cache locality, the same principle that governs performance in any system with a memory hierarchy.

// El prefijo del contexto debe ser estable: un byte que cambie al
// principio invalida el cache de todo lo que viene detrás.
// Leer del cache cuesta 0,1× el precio de input; escribirlo 1,25×-2×.

// MAL: timestamp mutable al inicio → cada turno reescribe todo el cache
const prefijoRoto = [
  { role: "system", content: `Hora: ${Date.now()}. Eres un agente...` },
  ...historial,
];

// BIEN: prefijo estable; lo volátil se añade al final (append-only)
const prefijoEstable = [
  { role: "system", content: "Eres un agente..." },     // nunca cambia
  ...historial,                                          // solo crece por el final
  { role: "user", content: `Contexto de sesión: ${sesion}` },
];

Tokens being money isn’t unique to agents. The same toll shows up when you choose the language you talk to the model in — something I cover in the language tax.

What Concrete Techniques Exist, and What Trade-off Does Each Make?

Governing context comes down to four techniques. Each one solves a different problem and sacrifices something different.

Technique	What it solves	Trade-off	When to use it
Compaction	history that overflows the window	compressing is easy; deciding what to keep isn’t	long conversations approaching the limit
External memory (files)	state that doesn’t fit or shouldn’t live in the window	the agent must remember to read it; more I/O per turn	plans, findings, and decisions that persist across turns
Subagents (isolation)	a window that accumulates noise from multiple tasks	coordination and token cost (~15× vs. chat)	parallelizable, read-only tasks
Just-in-time retrieval	preloading data you might never use	latency and retrieval failures	large corpus where only a fraction is relevant per turn

Compaction: Summarize to Restart

Compaction takes a conversation nearing the window’s limit, summarizes its content, and restarts a fresh window with that summary ^[1]. It sounds trivial, and it isn’t. Compressing bytes is easy; deciding which information to keep is the hard problem. Cognition, which introduced a model dedicated solely to compressing the history of actions and decisions, admits it bluntly: “This is hard to get right” ^[3].

When done well, the numbers justify it. Context editing, which automatically clears stale tool calls and results as the token limit approaches, improved 29% over baseline on Anthropic’s agentic eval; combined with the memory tool (storing and querying information in files outside the window), 39%; and in a 100-turn web-search evaluation it cut token consumption by 84% ^[8].

External Memory: Files as State

If state doesn’t fit in the window, take it out of the window. Anthropic calls this structured note-taking or agentic memory: the agent regularly writes notes to persistent memory outside the context ^[1]. Manus takes it to the extreme and treats the file system as “the ultimate context: unlimited in size, persistent by nature, and directly operable by the agent itself” ^[7].

This is where the technique that closes the loop with the U-shaped curve comes in. Manus rewrites a todo.md on every turn, pushing the plan to the end of the context to bring it “into the model’s recent attention span, avoiding ‘lost-in-the-middle’ issues” ^[7]. Reciting the objectives at the end keeps them in the zone the model reads best.

// Recitación: reescribe el plan al FINAL del contexto en cada turno.
// Empuja los objetivos a la atención reciente y esquiva la curva
// en U de "Lost in the Middle".
async function turno(estado: Estado) {
  const plan = await leerFichero("todo.md");        // memoria externa
  const contexto = [...estado.historial, { role: "user", content: plan }];  // el plan queda al final
  const accion = await modelo.decidir(contexto);
  await escribirFichero("todo.md", accion.planActualizado);
  return accion;
}

The trade-off: state outside the window only works if the agent remembers to read it, and every read and write is one more operation per turn.

Subagents: Isolate to Avoid Contamination

A specialized subagent solves a specific task with its own clean window, instead of one single agent dragging the entire project’s state around ^[1]. Framed that way, it’s pure context isolation. But deciding when it’s worth it is a debate with data on both sides, and it deserves its own section.

Just-in-Time Retrieval: Load Only What You Need

Instead of preloading all the documentation, the agent keeps lightweight identifiers (paths, IDs, queries) and uses tools to load data at runtime, right when it needs it ^[1]. The window stays clean; the price is latency and the risk that retrieval fails. The infrastructure that makes this possible is the usual one: the enterprise RAG pipeline and, underneath it, embeddings and semantic search.

Subagents: The Case Where Both Sides Have Data

This is the most interesting trade-off for a senior engineer, because the same technique has two measured verdicts. In favor: Anthropic reported that its multi-agent system (Claude Opus 4 as lead with Claude Sonnet 4 subagents) outperformed a single agent by 90.2% on its internal research eval ^[9]. The explanation is economic: token usage alone explains 80% of the performance variance in their BrowseComp eval, and subagents compress work by operating in parallel, each with its own window, returning only the synthesis ^[9]. The cost: agents spend about 4× more tokens than a chat, and multi-agent systems about 15× ^[9].

Against it, Cognition. Their principles are almost the opposite: “Share context, and share full agent traces, not just individual messages” and “Actions carry implicit decisions, and conflicting decisions carry bad results” ^[3]. Their example is damning: two parallel subagents took actions “based on conflicting assumptions not prescribed upfront” ^[3]. Each one decided well on its own, and the combined result was incoherent.

Nobody’s lying. The variable is whether the subagents’ decisions need to be consistent with each other. Anthropic’s +90.2% comes from research: parallelizable, read-only tasks where each subagent searches without stepping on the others. Cognition’s warning applies to writing and code, where every action carries implicit decisions the next step has to respect. If your subagents only read, isolate them without fear. If they write, either share full context or don’t parallelize them. After more than a few loops that got away from me, the rule I’ve settled on is treating parallelism as guilty until proven innocent: I let it in by default when the task is read-only, and if there’s even one coupled write in the mix I prefer a sequential agent, even if it’s slower, because debugging conflicting decisions costs far more than the turns you save. I break down when parallelism pays off in agent parallelization: sectioning and voting.

Why Does This Skill Matter Specifically in 2026?

Because today everyone uses agents and almost nobody leaves them unsupervised, and the difference between the two groups is what the model sees. The adoption data is compelling: the 2026 Pragmatic Engineer survey reports that 95% of respondents use AI tools at least weekly, that 56% already do 70% or more of their engineering work with AI, and that Claude Code went from zero to the number-one tool in just eight months ^[10].

But the ceiling is clear. Anthropic’s 2026 Agentic Coding Trends report found that, although developers use AI in roughly 60% of their work, they can only fully delegate between 0% and 20% of tasks ^[11]. That gap between “using” and “delegating” has its own name, the delegation gap, and it’s exactly what context engineering attacks. The report itself predicts organizations will adopt multi-agent workflows with “parallel reasoning across separate context windows” ^[11]. Separate windows: context isolation, again.

When context is governed well, previously unthinkable tasks unlock. The report cites Rakuten implementing an activation-vector extraction method in vLLM, a 12.5-million-line open source library: Claude Code completed the entire job in seven hours of autonomous work in a single run, with 99.9% numerical accuracy against the reference method ^[11]. Seven hours without the window rotting along the way comes down to one discipline sustained turn after turn: governing context as a budget you spend deliberately, instead of letting it pile up like a warehouse.

Common Mistakes

Treating the Window as a Warehouse

Dumping all the documentation, the full history, and “everything just in case” doesn’t make the agent more informed — it makes it noisier. It’s the direct recipe for context rot and diminishing returns ^{[1] [5]}. If you’re unsure whether a token belongs, the default answer is no.

Breaking the Cache Prefix

A timestamp, a counter, or any mutable state at the beginning of the system prompt invalidates the cache for the entire history on every turn. You pay the write premium (1.25×-2×) on thousands of tokens that didn’t change ^[6]. Volatile stuff goes at the end, always.

Burying Critical Information in the Middle

Key instructions or decisions placed midway through a long context fall right into the trough of the U-shaped curve ^[4]. The antidote is recitation: rewrite what matters at the end on every turn ^[7].

Compacting Without a Retention Rule

Summarizing the history while losing decisions already made causes the agent to contradict them three turns later. Compressing well “is hard to get right” ^[3]: define what must be kept no matter what (decisions, commitments, state) before summarizing the rest.

Parallelizing Subagents That Write

Launching subagents in parallel on a write task without shared context produces conflicting implicit decisions ^[3]. Remember that Anthropic’s +90.2% comes from read-only research, not code ^[9].

Sources

1. Effective context engineering for AI agents. Anthropic Engineering. Definitions of context engineering and prompt engineering, attention budget, finite resource with diminishing returns, context rot, compaction, external memory, subagents, and just-in-time retrieval.
2. Context engineering. Simon Willison. Verbatim quotes from Andrej Karpathy and Tobi Lütke on the term.
3. Don’t Build Multi-Agents. Cognition (Walden Yan). “The #1 job of engineers building AI agents,” sharing context and full traces, conflicting decisions, and the difficulty of compression.
4. Lost in the Middle: How Language Models Use Long Contexts. Liu et al., TACL 2023. The U-shaped curve of context usage.
5. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma Research. 18 models evaluated; performance becomes less reliable as input grows; the LongMemEval finding.
6. Prompt caching. Anthropic Docs. Cache reads at 0.1×, writes at 1.25× (5 min) and 2× (1 h), default TTL of 5 minutes.
7. Context Engineering for AI Agents: Lessons from Building Manus. Manus. KV-cache hit rate as metric #1, $0.30 vs $3/MTok, ~100:1 input:output ratio, files as the ultimate context, and todo.md recitation.
8. Managing context on the Claude Developer Platform. Anthropic. +29% (context editing), +39% (with the memory tool), 84% fewer tokens in a 100-turn eval, and definitions of context editing and the memory tool.
9. How we built our multi-agent research system. Anthropic Engineering. +90.2% multi-agent vs. single agent, tokens explain 80% of the variance in BrowseComp, ~4× and ~15× cost, subagents as parallel compression.
10. AI Tooling for Software Engineers in 2026. Pragmatic Engineer. Adoption data: 95% weekly use, 56% do 70%+ of their work with AI, Claude Code #1 in eight months.
11. 2026 Agentic Coding Trends Report. Anthropic. AI in ~60% of work but only 0-20% delegable, prediction of multi-agent workflows with separate windows, and the Rakuten case (12.5M lines, 7 hours, 99.9%).

Frequently Asked Questions

Does Context Engineering Replace Prompt Engineering, or Include It?

It includes it: the prompt is only a subset of everything that enters the window, so writing good instructions is still necessary — it just stops being sufficient.

What Is Context Rot, and Why Does It Force You to Do Context Engineering?

It’s the degradation of the model as the window grows: according to Anthropic, the more tokens it holds, the worse it accurately recalls the information it contains. Chroma confirmed this across 18 current models, and “Lost in the Middle” had already shown that whatever sits in the middle of a long context is read worse than what’s at the beginning or end. That’s why adding more information isn’t enough — you have to curate what goes in.

When Does It Pay Off to Use Subagents to Isolate Context?

When the task is parallelizable and read-only, like researching several sources at once — there, Anthropic measured a 90.2% improvement over a single agent, because each subagent works with its own clean window. They don’t pay off when they write or generate code with coupled decisions, because they make conflicting assumptions that nobody fixed in advance. And keep the cost in mind: a multi-agent system can spend about 15× more tokens than a chat.

Why Is My Agent More Expensive Than I Expected?

Because input dominates the bill. At Manus, a real production agent, the input:output ratio runs around 100:1, and a typical task chains together about 50 tool calls; since every turn resends the entire accumulated history, those input tokens get paid for again and again. The main lever is the cache: reading costs 0.1× but writing costs 1.25×-2×, so a stable prefix that doesn’t break the cache cuts the bill far more than any prompt tweak.