Context Engineering: the skill that decides whether AI actually works

02So what is context engineering?

Context engineering is the practice of deliberately assembling everything the model sees at the moment it generates a response — the instructions, the relevant facts, the examples, the history, the tool results — so that the right information is present, the wrong information is absent, and the whole thing fits in the space available.

If prompt engineering is writing a good question, context engineering is preparing the model's entire desk before it starts work: which papers are laid out, which have been cleared away, what's pinned to the top, and which reference books are within reach. Your prompt is one sheet on that desk. Context engineering is the desk.

03What's actually inside the context window

Everything a model considers when generating its next word lives in one place: the context window. (Remember tokens and the context window from the foundations — this is where that idea earns its keep.) It's worth seeing everything that competes for that space, because context engineering is the craft of managing this exact list:

• System instructions — the standing rules: who the model should act as, what it must and must not do, the output format. Set once, applied throughout.
• The user's message — the actual request, right now.
• Conversation history — every previous turn in this chat, piling up as you go.
• Retrieved knowledge (RAG) — documents, records, or search results pulled in to ground the answer in real, specific facts.
• Tool definitions & tool results — for agents: the list of available tools, plus the output that comes back each time one runs.
• Examples (few-shot) — sample input/output pairs that show the model the pattern you want.
• Memory / state — facts carried over from earlier sessions or steps: your name, your preferences, decisions already made.
• The output so far — as the model writes, its own emerging answer becomes part of the context too.

Here is the catch that turns this into an engineering problem: all of that shares one finite window. Every token spent on a stale conversation turn, an irrelevant retrieved document, or a bloated tool result is a token unavailable for what actually matters — and, as you're about to see, extra noise doesn't merely waste space, it actively degrades the answer.

04The one principle: context is a scarce, shared resource

If you remember one thing from this lesson, make it this: the context window behaves like working memory — limited, and easily crowded. Picture a desk, or the RAM in a computer, or a chef's countertop in the middle of service. There is only so much room, and everything you place on it competes with everything else. Two consequences follow, and they drive every technique in this lesson.

More is not better

Beginners assume that dumping in everything — the whole manual, the entire chat, all fifty documents — gives the model its best shot. The opposite is usually true. A model handed the one precisely relevant page answers better than a model buried under fifty pages where the crucial sentence sits on page 37. Adding low-value context doesn't just waste space; it dilutes the signal and pulls the model's attention away from what actually matters.

Position matters

Research on long contexts found a striking — and very human — pattern: models pay the most attention to the beginning and end of their context and can lose track of information stranded in the middle. It's called the "lost in the middle" effect. Bury your single most important instruction halfway down a huge block of text and the model may sail right past it. Place that same instruction at the top, or restate it at the very end, and it gets used.

05How context goes wrong

Naming the failure modes makes them easy to spot in the wild. When an AI system misbehaves, it's usually one of these — and notice that not one of them is "the prompt was worded badly":

• Context distraction — too much irrelevant material is present, so the model loses the thread and latches onto a side detail instead of the point. The cure is pruning, not adding.
• Context confusion — overlapping or superfluous information leaves the model unsure which facts to use, so it hedges or blends them together.
• Context clash — two parts of the context contradict each other. A system rule says "be concise"; a retrieved document says "explain in full detail." Caught between them, the model produces something incoherent.
• Context poisoning — a wrong fact (often the model's own earlier hallucination) has entered the context, and because it's now "in the record," the model keeps treating it as true and building on it. One bad fact quietly contaminates everything downstream.
• Lost in the middle — critical information sits in the low-attention middle of a long context and is effectively ignored.
• Context rot — the slow decay that sets in as a window fills over a long session or agent run: stale, half-relevant material accumulates until quality drifts down. This is why a long conversation often seems to "get dumber" the longer it runs.

Every technique in the next section is a defense against one or more of these.

06The six moves of context engineering

In practice, context engineering comes down to a handful of repeatable moves. You are always doing some combination of these:

• 1 · Select — include only what's relevant. This is what retrieval (RAG) is for: instead of pasting a whole knowledge base, you fetch the few chunks that actually bear on the question and include just those. Selection is the highest-leverage move — most context problems are really selection problems in disguise.
• 2 · Compress — when you genuinely must include a lot, shrink it. Summarize a long document to the points that matter. Replace twenty conversation turns with a three-line summary of what's been decided. Distill a verbose tool result down to its one key field. Compression buys room without losing signal.
• 3 · Structure — how you lay context out changes how well it's used. Group related information. Label sections clearly — headings, or tags like <policy>…</policy> and <question>…</question> — so the model can tell instructions from data from examples. A structured context is far easier to navigate than a wall of undifferentiated text.
• 4 · Order — exploit the attention pattern. Put the most important instructions and the most critical facts near the beginning, and — crucially — restate the key ask at the very end, right before the model responds. Never strand a must-follow rule in the middle.
• 5 · Isolate — give a hard sub-task its own clean context instead of one giant shared one. This is the logic behind sub-agents: a specialist tackles a sub-problem in a fresh window with only what that piece needs, then hands back just its result, keeping the main context uncluttered. Splitting a job across isolated contexts often beats cramming it all into one.
• 6 · Persist — decide deliberately what carries forward. Long tasks need memory: a scratchpad for intermediate results, a store of key facts and decisions, a running summary. But persistence is a choice, never a default — you carry forward what still matters and let the rest fall away, precisely to avoid context rot.

07Why agents make this critical, not optional

For a single question, context engineering is mostly "include the right reference material." For an agent — an AI that works across many steps, calling tools — it becomes the central challenge, because now the context is dynamic and grows on its own.

Every step an agent takes adds to its context. It calls a tool, the tool returns a chunk of output, and that output stays in the window for every step that follows. Ten tool calls later, the context is thick with old results — most no longer relevant — steadily crowding out the model's view of the actual goal. This is context rot in fast-forward, and it's the number-one reason agents "forget" what they were doing or wander off the rails on long tasks.

So serious agent systems are, underneath, context-engineering systems. They constantly select (retrieve only what this step needs), compress (summarize old tool results instead of keeping them verbatim), isolate (spin up sub-agents with clean windows), and persist deliberately (write key findings to memory, then clear the clutter). You'll build exactly these mechanisms in the Automation & Agents subject — and they'll make far more sense now that you know which problem they exist to solve.

08A practical framework you can run every time

Before any serious AI task, run the context through three questions:

• Right information? Is everything the model needs to succeed actually present — the relevant facts, the constraints, the examples? Missing context is the single most common cause of a bad answer.
• No wrong information? Is anything present that shouldn't be — stale turns, irrelevant documents, contradictions, an unverified fact from earlier? Remove it; noise degrades output.
• Right form and place? Is it structured clearly and ordered so the critical parts sit where the model will attend — near the start and the end, not lost in the middle?

09Worked example: same task, three levels of context

Here's the difference from the practice prompts elsewhere in this course: these three tiers aren't better wordings of a request — they're better context. The instruction barely changes. What changes is everything else on the desk.

What's your refund policy? A customer wants to return something after 40 days.

Here is our returns policy:
[paste the full 6-page policy document]

A customer wants to return something after 40 days. What do I tell them?

You are a support agent. Answer ONLY from the policy below.
If the answer isn't in it, say "Let me check with the team."
Never invent terms. Quote the exact clause you rely on.

<policy>
Returns accepted within 30 days of purchase with receipt.
After 30 days: store credit only, at manager discretion.
Sale items: final, no returns.
</policy>

Customer question: a return requested 40 days after purchase.
Answer in 2 sentences, then quote the clause you used.

10Bringing it together

Prompt engineering got you a well-worded request. Context engineering is the bigger discipline around it: controlling the entire information environment the model reasons over. Once you start seeing every AI interaction as "what's on the desk right now," the failures stop being mysterious. A confident wrong answer usually means missing or poisoned context. A model ignoring your rule usually means that rule is lost in the middle. A long chat going downhill usually means context rot. And the fix is almost never a cleverer sentence — it's better curation of what the model sees.