How is context engineering different from prompt engineering?

Prompt engineering is about wording a single instruction well; context engineering is about managing the entire set of tokens the model sees across a whole task or agent run. Prompt engineering is one static message you write; context engineering is a dynamic system that assembles, retrieves, compresses and prunes information on every turn. A perfect prompt still fails if the surrounding context is bloated, contradictory, or missing the one fact that matters — which is why the field shifted its attention from the prompt to the context around it.

What are the four strategies of context engineering?

LangChain groups the techniques into four buckets. Write: store information outside the window (scratchpads, memory files, plans) so it survives and can be recalled later. Select: pull in only the right information at the right moment via retrieval, file reads or tool calls. Compress: shrink what's already in the window through summarization and trimming so only the tokens that still matter remain. Isolate: split work across separate context windows — sub-agents each with a fresh window — so sub-tasks don't contaminate each other. Most production agents combine all four.

Do I still need to learn prompt engineering in 2026?

Yes. Prompt engineering didn't disappear — it became a component of context engineering. Clear instructions, good few-shot examples and well-structured requests still matter; they're just one slice of the window now. The system prompt is still a prompt, and writing it 'at the right altitude' (specific enough to guide, general enough not to be brittle) is a prompt-engineering skill. The shift is one of scope: master the prompt, then master everything else that shares the window with it.

Context rot is the measurable degradation of a language model's performance as the input grows longer. Chroma's 2025 study tested 18 leading models and found accuracy dropped with length even when the task itself stayed trivial — the model simply had more to attend to and diluted its focus. It's related to the older 'lost in the middle' finding, where facts placed in the center of a long prompt are recalled worse than facts at the start or end. The practical lesson: a full context window is not a healthy one.

How do I start doing context engineering?

Start by auditing what's actually in your window on a typical turn: count the tokens spent on the system prompt, tool definitions, history, retrieved chunks and the reserved reply. Then apply the four strategies in order of payoff — compress a bloated system prompt and old history first, switch from pasting documents to retrieving them (select), write long-lived facts to a memory store instead of re-sending them, and isolate heavy sub-tasks into their own agent. Measure token usage in production so you catch context creep before it hurts quality.

What Is Context Engineering? The Complete 2026 Guide

Q: What is context engineering?

Context engineering is the practice of deciding exactly what information fills a language model's context window at each step — the system prompt, tools, retrieved documents, memory, and conversation history — so the model has precisely what it needs and nothing that distracts it. Where prompt engineering asks 'how do I phrase this request?', context engineering asks 'what should be on the model's desk right now?' It became the dominant skill in 2025–2026 because AI agents run for many steps and their own accumulated history, not the wording of a single prompt, is what makes them succeed or fail.

Q: Why does adding more context make an AI worse?

Because a context window is an attention budget, not free storage. Chroma's 2025 'context rot' study found all 18 frontier models tested performed worse as input grew, even on simple tasks. Four failure modes explain it: context poisoning (an earlier error gets repeatedly re-read as if true), context distraction (the model over-focuses on a long history instead of reasoning), context confusion (irrelevant tokens drag the answer off course), and context clash (two correct-but-contradictory facts collide). More tokens raise the odds of all four, so relevance beats volume.

Q: Is context engineering just RAG?

No — RAG is one tool inside context engineering, not the whole thing. Retrieval-augmented generation covers the 'select' strategy: fetching relevant chunks from a vector database at query time. Context engineering is broader: it also decides how to order the system prompt, when to summarize old turns, what to write to long-term memory, how many tools to expose, and when to hand a sub-task to an isolated agent. RAG answers 'what external knowledge do I pull in?'; context engineering answers 'what does the whole window look like at every step, and why?'

Last year the hottest job skill in AI was writing the perfect prompt. This year, the people building the best AI systems barely talk about prompts at all. They talk about context — what the model sees, in what order, and how much of it. Anthropic, LangChain, and the teams behind tools like Cursor and Claude Code all converged on the same idea within a few months of each other, and it now has a name: context engineering.

If you’ve ever watched an AI agent start strong and then slowly go off the rails over a long session — repeating mistakes, forgetting the goal, picking the wrong tool — you’ve seen the problem context engineering solves. This guide explains what it is, why it quietly replaced prompt engineering, the four ways context breaks, and the four-part framework the whole industry now uses to fix it. Everything here is grounded in the primary sources — Anthropic’s engineering team, LangChain, and the researchers who named the failure modes — linked at the end.

What context engineering actually is

Context engineering is the practice of deciding what information occupies a model’s context window at each step — so it has exactly what it needs and nothing that gets in the way.

That window holds far more than your latest message. On any given turn, a modern AI system packs in the system prompt, the definitions of every tool the model can call, retrieved documents, long-term memory, and the entire conversation so far. Context engineering is the discipline of curating that whole pile.

Anthropic frames it as a single question: “What configuration of context is most likely to generate our model’s desired behavior?” Notice what that question is not about. It’s not about finding a magic phrase. It’s about the arrangement, quality, and quantity of everything the model reads before it answers.

A useful mental model: if the context window is a desk, prompt engineering is writing a clear note and placing it on the desk. Context engineering is deciding everything else that shares the desk — which reference books are open, which are closed, what’s been cleared away, and what’s been filed in a drawer for later. A brilliant note buried under three hundred pages of clutter is still a note the reader will miss.

Why context engineering replaced prompt engineering

Prompt engineering was born in the chatbot era, and it fit that era perfectly. You asked one question, the model gave one answer, and the wording of your question was the main lever you could pull. Optimize the sentence, get a better reply.

Then AI systems stopped being chatbots and became agents. An agent doesn’t answer once — it runs a loop: read the situation, decide on an action, call a tool, read the result, decide again, for dozens or hundreds of steps. And here’s the thing the field learned the hard way:

Most agent failures in 2026 aren’t model failures. They’re context failures.

The model is usually smart enough. What breaks is the state it’s dragging around — an error from step 3 that keeps getting re-read at step 30, a history so long the model loses the plot, a set of forty tools where only two are relevant. None of that is fixable by rewording the initial prompt, because the initial prompt was fine. The problem lives in everything that accumulated after it.

That’s the shift in one line: prompt engineering optimizes a single message; context engineering optimizes the entire, ever-changing window across a whole task.

  PROMPT ENGINEERING              CONTEXT ENGINEERING
  ──────────────────              ───────────────────
  one static message              a dynamic system
  you write it once               it's rebuilt every turn
  "how do I phrase this?"         "what's on the desk right now?"
  great for single Q&A            required for multi-step agents
  a skill                         a system that includes that skill

Prompt engineering didn’t die. It got absorbed. Writing a sharp system prompt is still prompt engineering — it’s just one slice of a much bigger window you now have to manage. If you’re new to the phrasing side, our prompt engineering guide for beginners is the right starting point; this article is about everything that surrounds the prompt.

The context window is an attention budget, not storage

The single most important idea in context engineering is counterintuitive: more context usually makes the model worse.

That sounds wrong. Windows keep getting bigger — a million tokens is now normal on flagship models. Surely more room is better? But a window isn’t a hard drive you fill up; it’s an attention budget the model has to spread across every token. Spread it too thin and quality drops.

This isn’t a hunch. In 2025, Chroma ran a study they called context rot: they tested 18 frontier models and found that every single one performed worse as the input grew longer, even on tasks that stayed trivially easy. The model didn’t get dumber — it just had more to look at, and its focus diluted.

It builds on an older, well-replicated finding known as “lost in the middle”: when you place a key fact in the center of a long prompt, models recall it far less reliably than the same fact placed at the very start or the very end. Bury the important sentence in the middle of 100,000 tokens and the model reads right past it.

Recall accuracy by position in a long prompt (the "lost in the middle" curve)

 high │ █                                             █
      │ █ █                                         █ █
      │   █ █                                     █ █
      │       █ █                             █ █
      │           █ █ █ █ █ █ █ █ █ █ █ █ █ █
  low │
      └──────────────────────────────────────────────────
        start          middle of the window          end

The practical takeaway rewires how you think about the window: a full context window is not a healthy one. The goal is never to use all of it. The goal is to put the right few thousand tokens in and keep everything else out.

The four ways context breaks

Before you can engineer context well, you need to recognize how it goes wrong. Researcher Drew Breunig published the taxonomy the field now uses — four distinct failure modes. They’re worth memorizing, because each one has a different fix.

Failure mode	What happens	Typical trigger	The fix
Context poisoning	A hallucination or error enters the context and gets re-read as if it were true, again and again	Long agent runs where the model’s own output feeds back in	Validate tool/model output before it’s stored; quarantine or drop bad state
Context distraction	The context grows so long the model over-focuses on its history and stops reasoning fresh	High token counts; long sessions	Compress or summarize old turns; start a fresh window
Context confusion	Irrelevant information in the window drags the answer off course	Too many tools, stray documents, kitchen-sink prompts	Select only relevant context; expose fewer tools
Context clash	Two pieces of information that are each correct contradict each other	Accumulating tools, retrieved docs, and instructions over time	Reconcile or remove conflicting context; prune stale info

The distinction between the last two matters. Confusion is caused by noise — stuff that’s simply irrelevant. Clash is caused by contradiction — two facts that are both individually right but can’t both apply, like an old instruction and a new one that override each other. Noise you filter out; contradiction you resolve.

Notice a pattern in the triggers column: nearly all of them get worse the longer an agent runs. Poisoning compounds, distraction grows with history, confusion and clash accumulate as more tools and documents pile in. That’s exactly why context engineering became urgent the moment AI moved from single answers to long-running agents.

The four strategies: write, select, compress, isolate

Here’s the good news. LangChain distilled every context-engineering technique into four buckets, and once you know them, you can classify any tool or trick you meet. They call the practice “the art and science of filling the context window with just the right information at each step.”

                    ┌─────────────────────────────┐
                    │      CONTEXT ENGINEERING     │
                    └─────────────────────────────┘
                                  │
        ┌──────────────┬──────────┴───────┬──────────────┐
        ▼              ▼                  ▼              ▼
     WRITE          SELECT            COMPRESS        ISOLATE
   store it        pull it in         shrink it       split it
   outside         at the right       to what         across
   the window      moment             still matters   windows

1. Write — store context outside the window

The window is small and resets every call. So write important information somewhere durable — outside the window — where it survives and can be recalled on demand.

The classic pattern is a scratchpad: the agent jots intermediate reasoning, discoveries, or a plan to a file or a state object, instead of keeping it all live in the window. Long-term memory is the same idea across sessions — facts the agent learned yesterday, written down so they don’t have to be re-derived today.

# A minimal scratchpad: keep the plan OUT of the window,
# read back only the current step when you need it.
plan = [
    "1. Find the failing test",
    "2. Reproduce it locally",
    "3. Patch the root cause",
    "4. Re-run the suite",
]
scratchpad_write("plan.md", "\n".join(plan))   # written, not held in-context

# Later turns pull back only what this step needs:
current_step = scratchpad_read("plan.md", line=2)   # "2. Reproduce it locally"

This is why Claude Code and Cursor lean on files and to-do lists: the plan lives on disk, and only the relevant line re-enters the window when it’s needed.

2. Select — pull in only what matters, when it matters

Select is about retrieval: at each step, fetch only the context relevant to this step. This is where Retrieval-Augmented Generation lives — instead of pasting an entire knowledge base into the prompt, you store it in a vector database and pull back the handful of chunks that match the current question.

Selection applies to more than documents. You can select tools the same way. If your agent has 40 tools, showing all 40 every turn invites context confusion — so retrieve the 3–5 tools likely relevant to the current step instead.

 40 tools defined ──► embed each tool's description ──► vector store
                                                            │
 current task ──► embed ──► similarity search ──────────────┘
                                    │
                                    ▼
                        expose only the top 3 tools
                        (fewer choices → less confusion)

The guiding rule from Anthropic is blunt and useful: if a human engineer can’t definitively say which tool to use in a situation, an agent can’t be expected to do better. Selection is how you keep that choice small and clear.

3. Compress — shrink what’s already in the window

Even with good selection, the window fills up over a long task. Compress reclaims space by reducing what’s already there to the tokens that still matter.

The two workhorses are summarization (replace ten old turns with a three-sentence recap) and trimming (drop the oldest turns outright). This is exactly what coding agents do when they “auto-compact” or “condense” a session — GitHub Copilot compacts around 80% of the window; Cursor auto-summarizes older turns to make room for the reply.

# Summary-buffer compression: keep recent turns verbatim,
# fold everything older into a running summary.
def compress(history, keep_recent=6):
    if len(history) <= keep_recent:
        return history
    old, recent = history[:-keep_recent], history[-keep_recent:]
    summary = llm(f"Summarize these turns in 3 sentences:\n{old}")
    return [{"role": "system", "content": f"Earlier: {summary}"}] + recent

If you’ve ever fought a “context window exceeded” error, this is the durable fix — and our guide to fixing context-window errors walks through chunking, summarization and token counting in depth.

4. Isolate — split work across separate windows

The most powerful strategy is also the least obvious: don’t put everything in one window at all. Isolate heavy sub-tasks into separate context windows — usually sub-agents, each with its own fresh window — so their work doesn’t contaminate the main thread.

The payoff is twofold. A sub-agent can burn 50,000 tokens exploring a messy problem and return a two-line conclusion; the main agent’s window only ever sees those two lines, staying clean. And because each sub-agent starts fresh, an error in one can’t poison the others.

 MAIN AGENT (clean window)
     │
     ├──► sub-agent: "search the codebase"   ─► [50k tokens of work]
     │         └── returns: "bug is in auth.py line 88"  ◄── 1 line back
     │
     ├──► sub-agent: "read the API docs"      ─► [30k tokens of work]
     │         └── returns: "endpoint needs a v2 header"  ◄── 1 line back
     │
     ▼
 main window stays small — it only sees the conclusions, not the work

This is exactly what Cursor’s “Explore” sub-agent and Claude Code’s task agents do. It’s also the deep reason multi-agent systems work: isolation isn’t about having many models, it’s about giving each unit of work a clean desk.

What goes in the window, and in what order

Strategies tell you how to manage context. Anthropic’s engineering team also gave concrete guidance on what a well-formed window looks like and the order to assemble it:

┌──────────────── A WELL-ENGINEERED CONTEXT WINDOW ────────────────┐
│ 1. System instructions   — clear, direct, "the right altitude"   │
│ 2. Relevant memory        — durable facts pulled from storage    │
│ 3. Tool definitions       — only the tools this step may need    │
│ 4. Retrieved context      — the few chunks that match the task   │
│ 5. Conversation history   — compressed if long                   │
│ 6. The new request         — what to do right now                │
│ ── reserved space for the reply ──                               │
└──────────────────────────────────────────────────────────────────┘

Two pieces of Anthropic’s advice are worth pinning up:

Write the system prompt at “the right altitude.” Too specific and it’s brittle — a wall of hardcoded if-then rules that breaks on the first case you didn’t anticipate. Too vague and it gives no real guidance. Aim for clear, direct language that conveys intent and lets the model handle the specifics.
Curate examples; don’t dump them. Few-shot prompting still works, but a handful of diverse, canonical examples beats a giant pile of edge cases. The examples share the window with everything else — spend that budget wisely.

The unifying principle across all of it: the arrangement and quality of context determines agent performance more than almost anything else you can control.

Context engineering vs. RAG vs. fine-tuning: how they fit

These terms get muddled constantly, so here’s the clean version. They aren’t competitors — they operate at different layers.

Approach	What it changes	When to reach for it
Prompt engineering	The wording of a single instruction	Always — it’s the baseline, and now a sub-part of context engineering
RAG	Which external knowledge enters the window	The model needs facts it wasn’t trained on, or data that changes
Fine-tuning	The model’s own weights and default behavior	You need a consistent style or skill that prompting can’t reach — and you have the data
Context engineering	The entire window, every step, dynamically	Any multi-step agent or long-running task — it’s the umbrella over the others

The mental hierarchy: context engineering is the umbrella. RAG is the “select” strategy inside it. Prompt engineering is how you write the pieces that go in. Fine-tuning is the one lever that changes the model rather than the context — reach for it last, when the behavior you need can’t be achieved by managing what the model sees. (For the full fine-tuning-vs-RAG trade-off, the short version is: RAG adds knowledge, fine-tuning changes behavior, and neither expands the window.)

Putting it together: an agent loop with all four strategies

Here’s a stripped-down agent loop that uses every strategy at once. It’s not production code, but it shows how the pieces interlock — this is the shape of what’s running inside modern coding and research agents.

def run_agent(goal):
    memory = load_memory()                      # WRITE (read back durable facts)
    history = []

    while not done(goal):
        # SELECT: retrieve only what this step needs
        docs  = vector_store.search(embed(goal), k=4)
        tools = select_tools(goal, k=3)         # not all 40 tools — just 3

        # COMPRESS: fold old turns into a summary if history is long
        history = compress(history, keep_recent=6)

        # Assemble the window in a deliberate order
        window = [
            system_prompt,                      # right altitude, kept lean
            *memory,                            # durable facts
            *tools,                             # the 3 relevant tools
            *docs,                              # the 4 relevant chunks
            *history,                           # compressed history
            {"role": "user", "content": goal},
        ]

        action = llm(window)

        if action.type == "spawn_subagent":
            # ISOLATE: heavy sub-task gets its own fresh window
            result = run_agent(action.subgoal)  # returns a conclusion, not the work
            history.append({"role": "tool", "content": result})
        else:
            result = run_tool(action)
            if is_valid(result):                # guard against POISONING
                history.append({"role": "tool", "content": result})

        write_memory(memory, extract_facts(result))   # WRITE new durable facts

Read it top to bottom and you can name every move: select the docs and tools, compress the history, order the window carefully, isolate the sub-task, validate before storing to avoid poisoning, and write durable facts back to memory. That’s context engineering in one function.

Common mistakes

Treating a big window as free space. A 1M-token window is a ceiling, not a target. Filling it triggers context rot and “lost in the middle.” Aim for the smallest window that contains what the step needs.
Exposing every tool on every turn. Forty tool definitions is forty invitations to context confusion. Select the few that matter.
Never summarizing history. Left unchecked, conversation history grows without bound until the agent is distracted by its own transcript. Compress past a threshold.
Letting bad output feed back in. If a hallucinated fact or a failed tool result gets stored and re-read, you’ve got context poisoning. Validate before you append.
Piling up contradictory instructions. Old system rules plus new overrides plus stale retrieved docs create context clash. Reconcile or prune.
Confusing RAG with the whole discipline. Retrieval is one strategy (select). If that’s all you do, you’ve skipped write, compress, and isolate.
Optimizing the prompt while ignoring the window. A perfect prompt drowning in 200,000 tokens of clutter still fails. Fix the context first.

Best practices: a checklist

Audit your window. Count the tokens spent on system prompt, tools, memory, history, and retrieval on a typical turn. You can’t engineer what you don’t measure.
Budget for relevance, not volume. The right 2,000 tokens beat the wrong 200,000. Every token should earn its place.
Write the system prompt at the right altitude — clear intent, not a brittle rulebook.
Select tools and documents; don’t dump them. Fewer, more relevant options reduce confusion and clash.
Compress history automatically once it crosses ~70–80% of the window; leave room for the reply.
Write durable facts to memory instead of re-sending them every turn.
Isolate heavy sub-tasks into sub-agents that return conclusions, not their full working.
Validate outputs before storing them to prevent poisoning.
Log token usage in production so you catch context creep before users feel it.

Where context engineering is heading

Two trends are worth watching. First, hierarchical memory: agents with layered short-term, working, and long-term memory that lets them operate coherently over days or weeks, not just one session. The write and compress strategies are converging into full memory architectures.

Second, self-editing context: agents that proactively rewrite their own context — pruning stale facts, re-summarizing, reorganizing what’s on the desk — rather than waiting for a human-designed rule to fire. The context stops being something you configure once and becomes something the agent actively maintains.

Both point the same direction. As models plug into more tools and data through standards like the Model Context Protocol, the bottleneck isn’t the model’s intelligence — it’s the discipline of deciding what that intelligence gets to see. That discipline is context engineering, and it’s only becoming more central.

FAQ

What is context engineering? It’s the practice of deciding exactly what fills a model’s context window at each step — system prompt, tools, retrieved data, memory, and history — so it has what it needs and nothing that distracts it. Where prompt engineering asks “how do I phrase this?”, context engineering asks “what’s on the model’s desk right now?”

How is it different from prompt engineering? Prompt engineering optimizes a single message; context engineering optimizes the entire, ever-changing window across a whole task. A perfect prompt still fails if the surrounding context is bloated or contradictory — so the field shifted its focus from the prompt to everything around it.

Why does adding more context make an AI worse? Because the window is an attention budget, not storage. Chroma’s 2025 “context rot” study found all 18 models tested got worse as input grew. More tokens raise the odds of poisoning, distraction, confusion, and clash. Relevance beats volume.

What are the four strategies? Write (store context outside the window), Select (retrieve only what’s relevant now), Compress (summarize and trim what’s already there), and Isolate (split work across separate windows via sub-agents). Most production agents use all four.

Is context engineering just RAG? No. RAG is the “select” strategy — one tool inside context engineering. The broader discipline also covers ordering the system prompt, compressing history, writing to memory, limiting tools, and isolating sub-tasks.

Do I still need prompt engineering in 2026? Yes — it became a component of context engineering. Clear instructions and good examples still matter; they’re just one slice of the window now.

What is context rot? The measurable drop in a model’s performance as input grows longer. Chroma’s 2025 study confirmed it across 18 frontier models. It’s related to “lost in the middle,” where facts in the center of a long prompt are recalled worse than those at the edges.

How do I start? Audit what’s in your window on a typical turn, then apply the four strategies by payoff: compress a bloated system prompt and old history, retrieve instead of pasting, write durable facts to memory, and isolate heavy sub-tasks.

Keep learning: official sources and talks

Primary sources (all current as of July 2026):

Anthropic — Effective context engineering for AI agents · Building effective agents
LangChain — Context engineering for agents · Context engineering docs
Drew Breunig — How long contexts fail · How to fix your context
Simon Willison — How to fix your context
Chroma — Context Rot: how increasing input tokens impacts LLM performance

Useful searches (try on YouTube — Anthropic, LangChain, and freeCodeCamp channels):

“context engineering for AI agents explained”
“write select compress isolate context”
“context rot lost in the middle LLM”
“multi-agent sub-agent isolation context window”

Go deeper on this site: How large language models actually work · RAG explained · Fixing context window errors · What is MCP? · The rise of AI agents

Prompt engineering taught us that how you ask matters. Context engineering is the harder, more durable lesson: that what the model is looking at when you ask matters even more. The teams shipping the most capable agents in 2026 aren’t the ones with the cleverest prompts — they’re the ones who treat the context window like the scarce, precious resource it is, and defend it ruthlessly. Learn to ask “what belongs on the desk right now?” at every step, and you’ve learned the skill the whole field just spent a year discovering.