What Is Context Engineering? (The 2026 Shift)

Introduction

Container 1 has taught you to talk to a model — tokens and sampling, prompting, advanced techniques, structured outputs. Every one of those lessons was really about the same thing: what you put in front of the model. This final section names that skill and makes it the main event.

Through ~2024 the craft was prompt engineering: wording a clever instruction, mostly by hand, mostly static. But modern AI systems aren't one-shot prompts — they're multi-turn, tool-using, memory-carrying, retrieval-backed systems that run for many steps. There, the hand-written instruction is just a slice of what the model sees. The real question becomes: of everything I could put in the context window — instructions, history, retrieved docs, tool results, memory, state — what's the right set to include right now?

That question is context engineering, and in 2026 it's the defining skill of an AI engineer. This lesson frames it; the rest of this section — and the RAG, Agents, and Production containers — are, in a real sense, all context engineering.

In this lesson you'll learn:

How context engineering differs from prompt engineering — and why the shift happened
The components assembled into the context window on every call
Why context is a finite resource — and what context rot is
The one principle behind it all: the smallest high-signal set
A map of the strategies that the next lessons and containers make concrete

From Prompt Engineering to Context Engineering

Prompt engineering is writing an effective instruction — especially the system prompt — for a discrete task. It's still essential (you just spent four sections on it). But it assumes a mostly static input you craft once.

Context engineering is broader and dynamic. Anthropic defines it as "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference." The shift, in their framing, is from "writing effective prompts" to deciding "what configuration of context is most likely to generate the model's desired behavior" — turn after turn, as a system loops, retrieves, and remembers.

The difference in one line: prompt engineering optimizes the words; context engineering optimizes the entire set of tokens the model sees — reassembled on every call, from many moving sources. Prompting is a subset of context engineering.

What's Actually in the Context?

On any given call, the "prompt" the model receives is assembled from several sources — not typed by hand:

System instructions — role, rules, output format.
Tools + their descriptions — what the model can do (those schemas cost tokens too).
Examples — few-shot demonstrations.
Message history — the conversation so far.
Retrieved data — documents pulled in via RAG (Container 2).
Memory / notes — durable facts carried across turns (next lesson).
Current state — task progress, scratchpad, intermediate results.

Context engineering is the discipline of deciding what goes into the window, from each of these, every time.

An infographic titled 'Context Engineering: Assembling What the Model Sees'. On the left, a panel of seven labelled source chips: system instructions, tools and descriptions, few-shot examples, message history, retrieved data (RAG), memory and notes, and current state. An arrow leads from this panel into a central bounded box labelled 'CONTEXT WINDOW (finite)' shown partly filled, which then feeds an arrow into the Model. Two contrasting tags read: dumping everything causes context rot, where recall drops as tokens grow; versus the smallest high-signal set gives the best output. A bottom banner says prompt engineering writes the instruction, while context engineering curates the whole set of tokens, dynamically, every turn.

The model never sees "sources" — it sees one flat stream of tokens you concatenated. Here's that assembly made literal (run it — no API needed):

# The "prompt" a model receives is ASSEMBLED from many sources — every call.
def assemble_context(system, memory, retrieved, history, user_msg):
    parts = {
        "SYSTEM INSTRUCTIONS": system,
        "MEMORY / NOTES":      memory,
        "RETRIEVED DATA":      retrieved,
        "CONVERSATION HISTORY": history,
        "USER MESSAGE":        user_msg,
    }
    # include only parts that actually have content — curation starts right here
    return "\n\n".join(f"## {name}\n{text}" for name, text in parts.items() if text)

context = assemble_context(
    system="You are a concise support agent.",
    memory="Customer: Jane, Pro plan since 2024.",
    retrieved="Refund policy: refunds post within 5-7 business days.",
    history="Jane: Where is my refund?",
    user_msg="It's been 3 weeks!",
)
print(context)
print(f"\n-> assembled from 5 sources into ONE context window ({len(context.split())} words)")

Once you see context as something you assemble, the engineering question is unavoidable: every token competes for limited space and attention. Which is exactly why you can't just include everything.

Context Is a Finite Resource: Context Rot

It's tempting to read "1M-token window" as "dump it all in." Don't. Recall from the long-context lesson that models get lost in the middle; the deeper reason has a name — context rot: as the number of tokens in the context grows, the model's ability to accurately recall any one of them drops.

Why? The transformer's attention compares every token to every other — n² pairwise relationships for n tokens — so attention spreads thinner as context grows. And models saw relatively few very-long sequences in training, so they're simply less practiced at long-range dependencies. The upshot: context is a finite resource with diminishing — eventually negative — marginal returns. Past a point, more tokens make answers worse, slower, and costlier at once (the Iron Triangle, again).

So the goal of context engineering is not to fill the window. It's the opposite.

The Core Principle: The Smallest High-Signal Set

Anthropic states the guiding rule as finding "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome." Curate, don't hoard. Every token you add should earn its place by raising the odds of a good answer; tokens that don't are noise — they dilute attention and feed context rot.

This reframes much of what you'll build. Good retrieval isn't "fetch the most documents," it's "fetch the few right passages." A good agent doesn't drag its entire history along, it carries a summary plus what's relevant now. The mindset is editorial: ruthless about what makes the cut.

The Strategies (a Map)

How do you keep context small and high-signal? A toolkit you'll meet across the rest of the course:

Select & compress the window — pick what's relevant; summarize the rest. (Next lesson.)
Memory & note-taking — write durable facts outside the window and pull them back on demand. (Lesson after next.)
Just-in-time retrieval — don't pre-load everything; keep lightweight references (file paths, queries, links) and fetch when needed. (RAG, Container 2.)
Compaction — for long-running agents, summarize the context as it nears the limit — keep decisions and open threads, drop the rest. (Agents, Container 3.)

Each is a way to spend a finite token budget well. This lesson is the why; those are the how.

Pitfalls & Mental-Model Corrections

"Bigger window = just add everything." No — context rot makes recall drop as you fill it. A large window is a budget, not a target.
"Context engineering is just RAG." Retrieval is one source of context. So are memory, tools, history, and state — context engineering coordinates all of them.
"It's prompt engineering with a new name." Prompting crafts one (mostly static) instruction; context engineering dynamically curates the entire token set across many turns. Prompting is a part of it.
"More context is safer." More context is more cost, more latency, and more room for the model to fixate on the wrong thing. Less, but higher-signal, usually wins.
"The model sees my nice sections and headings." It sees one flat token stream you assembled — order, formatting, and what you left out all change the output.

🧪 Try It Yourself

Open a prompt you've built (or the extraction prompt from last lesson) and audit its context like a budget. List every distinct thing you're sending — system instructions, examples, history, retrieved text, the user's message — and label each high-signal or low-signal for the task at hand. Cut or compress two low-signal items, re-run, and check whether the answer holds (it usually does).

Then the real question: if you had only half the tokens, what would you keep? That ranking — what earns its place — is context engineering.

Context Budget Lab — the context window starts stuffed with everything (system instructions, the user question, two relevant passages, few-shot examples, the full 40-message history, eight extra retrieved documents, and the entire tool catalog). Toggle items in and out and watch two meters: the token fill against a comfortable budget, and a predicted answer quality computed as high-signal coverage minus a context-rot penalty that grows with total tokens. Dumping in the low-signal bulk tanks the quality (context rot: recall drops, cost and latency climb); cutting it back to just the high-signal items makes quality rise; dropping the user question makes the answer impossible. Lands the core principle: a window is a budget not a target, and the goal is the smallest high-signal set of tokens.

Key Takeaways

Context engineering = curating and maintaining the optimal set of tokens the model sees during inference — the 2026 evolution of prompt engineering for multi-turn, tool-using, memory-carrying systems.
The context window is assembled every call from many sources: instructions, tools, examples, history, retrieved data, memory, and state.
Context is a finite resource: context rot means recall drops as tokens grow (n² attention + training skew), so more context can mean worse output.
The guiding rule is the smallest set of high-signal tokens that gets the outcome you want — curate, don't hoard.
The strategies — selection/compression, memory, just-in-time retrieval, compaction — are coming next; this lesson is the why behind them.

Next: Managing the Context Window — the concrete techniques for selecting and compressing what goes into that finite budget.