The map: 18 concepts in seven groups

A metro map: first you see the lines as a whole, then you ride station by station.

The course runs through seven groups. First — the window: what the model knows at all. Then — the shift from wording a prompt to assembling context. Next — what the window is built from, and the three forces that degrade it: irrelevance, budget, and rot over time. Finally — practice: building the window on purpose and measuring the result.

How to read each concept

A passport: the same fields for everyone, so they're easy to compare.

Every concept below gets the same treatment: its English name (remember it — that's what docs and articles call it), a picture from everyday life, a diagram, and a card with fields like problem, idea, example, cost and related. The main idea of the course: LLM quality is decided by what you put in the window, not by clever wording.

Stateless Model — it remembers nothing between calls

A brilliant consultant with total amnesia — every meeting, you must re-hand them every document, because they remember nothing from last time.

A language model is stateless — that's the Stateless Model concept: it keeps nothing between requests. The illusion of a chatbot remembering your conversation is just the whole history being re-sent every time. The model itself starts fresh on each call, knowing only what's in front of it right now.

So "what does the model know?" is never about the model — it's entirely about what you chose to include this time.

Context Window — its only working memory

A worker who can only act on the notes pinned to the board in front of them — clear the board and it's as if nothing ever happened.

The context window is the block of text the model sees on a call — your instructions, the conversation, any data, the tools. It is the model's entire working memory, and it has a finite size. If a fact, a rule, or a past message isn't in the window, the model simply doesn't know it.

Everything the model can reason about, it reasons about from the window — which makes the window the thing you actually engineer.

So quality is decided by what you put in

A genius answering only from the single folder you hand them — give them the right folder and the answer is brilliant; give them the wrong one and it's confidently useless.

Because the model works only from the window, the quality of its output is mostly decided before the model runs — by what you assembled. The same model gives a great answer or a hopeless one depending entirely on whether the right context was in front of it. This reframes the whole job: you're not coaxing intelligence out of the model, you're curating what it gets to see. That curation is context engineering.

Prompt Engineering vs Context Engineering — wording versus assembly

A lawyer wins not by clever phrasing but by handing the judge exactly the right documents, in the right order, with nothing irrelevant — the case is in the papers, not the speech.

Prompt engineering is about how you phrase the instruction. Context engineering is the bigger job: assembling all the information the model needs — the relevant facts, the history, the examples, the tools — into the window for each call.

As applications grow, wording matters less and assembly matters more. Most "the AI gave a bad answer" moments are not bad phrasing; they're the model missing context it was never given.

Missing Context — most quality problems are context problems

An assistant who gives a wrong answer because you forgot to mention the one constraint that changed everything — not stupid, just uninformed.

When an LLM feature underperforms, the instinct is to tweak the prompt wording or blame the model. Far more often the real cause is missing or wrong context (missing context): the relevant document wasn't retrieved, a key rule wasn't included, stale history confused it.

Before you reword anything, ask what the model actually had in front of it. Fixing the context fixes more bugs than fixing the phrasing ever will.

The model is only as good as its inputs

The finest chef can only cook with the ingredients on the counter — hand them the wrong ones and skill can't save the dish.

A capable model with poor context loses to a weaker model with excellent context. This is why context engineering, not model choice, is usually the highest-leverage place to spend effort: the same model's output swings wildly with what you feed it. You don't get a better answer by demanding harder — you get it by putting better, sharper, more relevant material in the window. The inputs are the lever.

System Prompt — standing behaviour versus the one-off request

A restaurant's standing policy — "we're vegetarian, we close at ten" — versus tonight's specific order. One frames everything; the other is the ask.

The system prompt holds durable instructions that apply across the whole interaction: the model's role, the rules it must follow, the tone, the output format. The user message is the specific request.

Putting your persona, guardrails, and standing rules in the system prompt keeps them stable while the user's questions vary. It's the difference between who the model is on every call and what it's being asked this time.

Few-shot Prompting — show, don't just tell

Teaching someone a format by showing three finished examples is faster and clearer than describing it in words and hoping they picture it right.

Often the most reliable way to get the shape of output you want is to include a few examples of input and ideal output right in the context. That's the few-shot prompting pattern. The model pattern-matches examples far better than it follows an abstract description.

Two or three sharp examples can beat a paragraph of instructions, and they're often the fastest fix when the model almost does what you want but not quite.

Context Assembly — build the window from parts

Packing a briefcase for a meeting: the agenda, the two relevant reports, a note of the constraints — chosen on purpose, not your whole filing cabinet tipped in.

A real context window is assembled from pieces every call: the system prompt, the relevant history, retrieved facts (RAG), examples, the available tools, and finally the user's request. That's context assembly: deciding — deliberately, each time — which pieces go in and which stay out.

Thinking of the window as something you build from parts, rather than just a prompt you type, is the mental shift that makes everything else click.

Relevance over Completeness — more context is not better context

A briefing that's one sharp page beats a 200-page dump — the reader finds the signal instead of drowning in it, and decides faster and better.

It's tempting to stuff everything possibly relevant into the window "just in case." But more isn't better — it's usually worse. The principle is relevance over completeness: every token competes for the model's attention, and irrelevant material dilutes the signal.

The skill is selecting the few things that matter, not including everything that might.

Context Dilution — noise raises the chance of a wrong answer

Hide the one relevant fact inside a mountain of mostly-irrelevant paper and even a careful reader starts citing the wrong page — the noise itself causes the error.

Long, padded context doesn't just waste space; it actively degrades quality. That's context dilution: buried in irrelevant material, the model's attention spreads thin, and in long contexts this measurably raises the rate of hallucination and mistakes — it confidently uses something that was never meant to be the answer.

Adding "just in case" context can be the very thing that causes the failure. Less, sharper context is more reliable context.

Curation — curate ruthlessly for this call

A good editor doesn't add — they cut, handing you only the lines that earn their place on this page.

The discipline is ruthless curation: for this specific call, include the few things the model genuinely needs and leave everything else out. That means retrieving only the most relevant chunks, trimming history to what matters, dropping context that's done its job.

Context Budget — the window is finite and every token costs

A suitcase with a weight limit and a fee per kilo — you pack what you'll actually need, not your whole wardrobe, because there's a hard cap and a price.

The context window has a maximum size, and every token in it costs latency and money — bigger contexts are slower and more expensive on every single call. So context isn't free space to fill; it's a context budget you spend.

A feature that stuffs the window on every request is slow and costly at scale, even before quality suffers. The window is a resource to allocate, not a void to fill.

Trim & Summarize — spend the window on what earns its place

A tight travel budget forces real choices — you spend on what matters for the trip and skip the rest, and the trip is better for the discipline.

Treating the window as a budget changes how you build: you trim the conversation history, summarize old turns instead of carrying them verbatim, and retrieve only what's relevant now rather than everything you have. Each token should earn its slot.

This is the same discipline as performance or caching — spend the scarce resource deliberately, on the things that actually move the outcome.

Long Context Windows — a bigger window doesn't end the discipline

Renting a bigger truck doesn't mean you should fill it with junk — more capacity is room for more useful things, not licence to stop packing carefully.

Models keep shipping larger context windows (long context windows) — a million tokens, more — and it's tempting to think the budget problem goes away. It doesn't. A bigger window still costs more and runs slower per token, and crucially, a fuller window still dilutes attention and invites mistakes.

More capacity is not permission to dump; it's just more room you still have to spend wisely. The discipline of curating the window survives any size increase.

Context Rot — long contexts accumulate stale, contradictory state

A game of telephone down a long line — by the end the message has quietly mutated, and everyone is confidently repeating something slightly wrong.

Across a long conversation or a multi-step agent task, the window fills with history: earlier turns, tool outputs, half-finished reasoning. Over time this pile grows messy — stale facts sit next to fresh ones, contradictions accumulate, the original goal slides out of focus.

The industry calls the resulting quality decay context rot: the same model gets less reliable as its own accumulated context gets noisier.

Compaction — compress as you go

A good note-taker doesn't keep every word of a long meeting — they distil it to the decisions and open questions, carrying forward the conclusion, not the transcript.

The fix is to actively compress the context as it grows. That's compaction: summarise finished steps into a short running state instead of dragging the full transcript forward, drop tool outputs once you've extracted what mattered, keep a tight working summary rather than the raw history.

The model carries the conclusion, not every word that produced it. This is how long-running agents stay coherent — they manage their own context instead of letting it pile up.

Goal Re-anchoring — re-anchor the goal

On a long, winding hike you re-check the map and the destination regularly — otherwise you drift, one reasonable-looking turn at a time, away from where you meant to go.

Over many steps, the original objective erodes under the weight of everything that's happened since. So you re-anchor it (re-anchoring): restate the goal and the key constraints in the window at each step, so the model stays pointed at the real target instead of drifting with the conversation.

A bigger window makes this worse, not better — it gives drift more room to accumulate. Active management, not raw capacity, is what keeps a long task on track.

Deliberate Assembly — build the window on purpose, not by accident

A chef plates a dish on purpose — each element placed for a reason — instead of scraping whatever's on the counter onto the plate.

The core habit is deliberate assembly: treating the window as something you construct on purpose. Decide what the system prompt holds, what history to keep or summarise, what to retrieve, which examples to show, which tools to expose.

Many LLM apps assemble context by accident — whatever happened to be lying around gets sent. Building it on purpose, with each part justified, is most of what separates a reliable feature from a flaky one.

Context Evals — measure context the way you measure code

You don't guess whether a change helped — you test it. The same goes for what you put in the window: an answer got better or worse, and you should know which.

Context changes are real changes, so verify them: when you adjust what goes in the window — more examples, different retrieval, trimmed history — check the effect with evals, don't just eyeball one output.

Context engineering without measurement is tuning by vibes, and it's how a "harmless" addition quietly degrades quality. Treat the window's contents as a thing you test, the same discipline as the evals course.

How it all connects

The whole metro map: now you can see where the lines cross.

The model is stateless → so the window decides everything → so the window is what you engineer. The window is assembled from parts (system prompt, examples, facts). Three forces degrade it: irrelevance, budget, and rot over time. Each has its own practice: curation, trim and summarize, compaction with re-anchoring. And evals check that every change actually helped.