# The model only knows what's in the window Express course on context engineering — the discipline of assembling exactly the right text into a model's context window. 18 concepts — Stateless Model, Context Window, Context Engineering, System Prompt, Few-shot, Context Dilution, Context Budget, Context Rot, Compaction, Context Evals and more — each with its English name, a diagram, a card and an example. A one-page cheat sheet of every concept at the end. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 minute read - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/learn/context-engineering-express --- ## 1. The window is all it knows Everything in this course follows from one fact about how a language model works: it has no memory, and its entire awareness on any call is the text you send it. Get this and the rest is obvious. ### 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. _Diagram: Seven groups of concepts — chapters 1–7 follow them._ ### 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. _Diagram: Stateless: on every call the app re-sends the whole history. A chatbot's “memory” lives in your code, not in the model._ #### Stateless Model (no memory between calls) - **What it is:** The model keeps nothing between requests: every call starts blank. - **How it works:** A chat “remembers” the conversation only because the app re-sends the whole history on every call. - **Example:** The third question in a chat goes to the model together with the first two questions and both replies. - **Gotcha:** Expecting the model to “remember” a rule from a past session — if it isn't in this call, it isn't there. - **Related:** This is why **Context Window** decides everything; growing history leads to **Context Budget** and **Context Rot**. ### 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. _Diagram: The window is everything the model sees. What lies outside it (an old chat, the company wiki, a forgotten rule) doesn't exist for it._ #### Context Window (the model's working memory) - **What it is:** All the text the model sees on one call: instructions, history, data, tools. - **How it works:** The model reasons only from the window. The window has a maximum size in tokens. - **Example:** A support bot doesn't know the refund policy unless its text was put into this call's window. - **Gotcha:** “The model should know this” — no: if it's not in the window, it doesn't exist for the model. - **Related:** The window is built through **Context Assembly**; its size is the **Context Budget**. ### 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. _Diagram: The same model: with the right context — a great answer; without it — a confidently useless one. The lever is the input, not the model._ > **The framing question:** "Is everything the model needs to answer this well actually in the window right now — or am I expecting it to know something I never put in front of it?" > The model is stateless and knows only its context window. Output quality is decided by what you assemble into that window — so the window, not the model, is what you engineer. ## 2. Prompt versus context People talk about "prompt engineering," but as apps get serious the real craft moves elsewhere — from wording a request to assembling the right information around it. That shift is the heart of this course. ### 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. _Diagram: Prompt engineering is one part of the window (the wording). Context engineering is all the inputs, assembled on every call._ #### Context Engineering (vs prompt engineering) - **Problem:** Quality gets “tuned” through prompt wording while the model is missing the actual facts. - **Idea:** Engineer the whole window: system rules, facts, history, examples, tools — on every call. - **Example:** Instead of “answer in detail and accurately!” — put the right document and the key rule in the window. - **Cost:** You need code that assembles the window, and discipline about what goes in. - **When to use:** As soon as an LLM feature outgrows a single demo prompt. - **Related:** Prompt engineering is one part of it; in practice it's **Context Assembly** and **Deliberate Assembly**. ### 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. _Diagram: A bad answer? The instinct is to rewrite the prompt. The right first step is to look at what was in the window: a document not retrieved, a rule not included, stale history._ #### Missing Context (absent or wrong context) - **Problem:** The model answers badly, and the team rewrites the prompt again and again — to no effect. - **Idea:** First look at what was in the window on the bad call; only then touch the wording. - **Example:** The bot quotes an old price plan: stale history was in the window, the new price list wasn't. - **Typical causes:** The document wasn't retrieved, the rule wasn't included, stale history confused it. - **Related:** Fixed with **Context Assembly** and **Curation**; verified with **Context Evals**. ### 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. > **The craft question:** "Am I trying to fix this by rewording the prompt — when the real problem is what information did or didn't make it into the context?" > Prompt engineering is the wording; context engineering is assembling the right information. The second is where quality lives — and most bad answers are missing context, not bad phrasing. ## 3. System prompt and examples Some of what goes in the window is durable and some is per-request, and a few specific ingredients do most of the work. Knowing what they are makes assembling context concrete. ### 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. _Diagram: The system prompt is the same on every call (role, rules, tone, format). The user message changes every time._ #### System Prompt (vs user message) - **What it is:** Durable instructions for the whole interaction: role, rules, tone, output format. - **Versus:** The **user message** — this time's specific request. - **Example:** System: “You are a store's support bot, answer briefly, never promise discounts.” User: “Where's my order?” - **Gotcha:** Mix standing rules into the request and they'll “float” from question to question. - **Related:** The first piece of **Context Assembly**; output format is often better shown with **Few-shot**. ### 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. _Diagram: Left — describe the format in words and get “almost right”. Right — show “input → ideal output” pairs, and a new input gets the same shape._ #### Few-shot Prompting (examples in the context) - **Problem:** The model almost does it, but the output shape drifts. - **Idea:** Put 2–3 “input → ideal output” pairs in the window — the model repeats the pattern. - **Example:** Three examples of “review → JSON with sentiment and topic”, then a new review — and the answer comes back in the same JSON. - **Cost:** Examples take tokens on every call — they're part of the **Context Budget**. - **When to use:** When shape matters and a paragraph of instructions doesn't help. - **Related:** One of the pieces of **Context Assembly**; complements the **System Prompt**. ### 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. _Diagram: On every call your code picks the pieces — system prompt, history, facts, examples, tools, request — and assembles the window from them._ #### Context Assembly (building the window from parts) - **Problem:** The window is “just a prompt”, and whatever happens to be around ends up in it. - **Idea:** Assemble the window in code from parts: system prompt, history, RAG facts, examples, tools, request. - **Example:** An order question: the bot's rules + the last 3 messages + this order's data + the question. Not the whole catalogue. - **Cost:** Every part has to be chosen and justified — that's work, not magic. - **Related:** Parts — **System Prompt**, **Few-shot**; filter — **Curation**; habit — **Deliberate Assembly**. > **The assembly question:** "What are the parts of this window — system rules, history, retrieved facts, examples, tools — and is each one pulling its weight, or just along for the ride?" > The system prompt sets durable behaviour; the user message is the request; few-shot examples show the shape you want. A window is assembled from these parts, deliberately, every call. ## 4. Relevance beats completeness The biggest beginner mistake in context engineering is thinking more is better. The opposite is true: every irrelevant token you add actively makes the answer worse. ### 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. _Diagram: Left — everything “just in case”: the signal drowns in noise. Right — only what this call needs: a sharp answer._ #### Relevance over Completeness (exactly enough, not everything) - **Problem:** Everything goes into the window “just in case”. - **Idea:** The goal isn't to give the model everything — it's to give it exactly enough. - **Example:** Instead of the whole knowledge base — the three paragraphs that actually answer this question. - **Cost:** You need to be able to select: good retrieval, trimming, decisions about what to drop. - **Related:** Why — **Context Dilution**; how — **Curation**; it also saves **Context Budget**. ### 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. _Diagram: The model's attention is spread across the noise — and it latches onto something nearby but wrong, not the right fact._ #### Context Dilution (signal drowned in noise) - **What it is:** Irrelevant tokens dilute the model's attention to the signal that matters. - **What it risks:** In long contexts the rate of hallucination and mistakes goes up: the model grabs the wrong piece. - **Example:** Twenty similar documents in the window — the model quotes the neighbouring contract instead of the right one. - **Gotcha:** “Just in case” context feels harmless — and can be the very cause of the failure. - **Related:** Fixed by **Curation**; a bigger window (**Long Context Windows**) doesn't cancel it. ### 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. _Diagram: The curation funnel: out of everything that might help — only the top chunks, the part of history that matters, and nothing that's done its job._ #### Curation (ruthless context curation) - **Problem:** The window grows on its own: whatever is at hand gets sent to the model. - **Idea:** On every call: only the most relevant chunks, trimmed history, nothing that's done its job. - **Example:** Search finds 50 chunks, the best 3 go into the window; a tool output that's already been digested is dropped. - **Cost:** You can cut something needed — that's why changes are checked with **Context Evals**. - **Related:** Embodies **Relevance over Completeness**; sibling of **Trim & Summarize** and **Compaction**. > **The relevance question:** "Is every piece in this window actually relevant to the answer — or am I padding it 'just in case' and quietly making the model worse?" > More context is not better — irrelevant tokens dilute attention and raise hallucination. Curate ruthlessly: give the model exactly what this call needs, and nothing else. ## 5. The window is a budget Beyond quality, the window is a finite, paid resource. Treating it as a scarce budget rather than an infinite dumping ground is what separates a toy from a product. ### 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. _Diagram: The window has a hard cap, and every token in it is paid for in latency and money — on every call._ #### Context Budget (the window as a scarce resource) - **What it is:** The window is a finite, paid resource: a size cap and a price for every token. - **What you pay:** Latency and money — on every call, multiplied by traffic. - **Example:** A feature sends the whole history and the whole reference manual with every request — slow and expensive before quality even suffers. - **When to think:** From day one, as soon as the feature goes to real users. - **Related:** Spent wisely through **Trim & Summarize**; not cancelled by **Long Context Windows**. ### 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. _Diagram: Eight turns verbatim → a short summary of the first six plus the last two turns as they are. Fewer tokens, same meaning._ #### Trim & Summarize (trimming and summarizing history) - **Problem:** Conversation history grows, and every turn rides along in the window verbatim. - **Idea:** Old turns as a short summary, recent ones as they are; retrieve only what's needed now. - **Example:** Instead of 40 chat messages — a summary “customer wants to return order #…, already sent a photo” + the last 2 messages. - **Cost:** A summary can lose a detail — check it with evals. - **Related:** Spends the **Context Budget** wisely; in long tasks it becomes **Compaction**. ### 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. _Diagram: Both windows hold the same small amount of useful material. The big one just has more room for noise — and you still pay per token._ #### Long Context Windows (1M+ token windows) - **What it is:** Models with windows of a million tokens and more. - **The temptation:** Thinking that since everything fits, curation is no longer needed. - **Example:** Dumping the whole repository into the window “because it fits” — expensive, slow, and the model gets confused. - **Gotcha:** A fuller window means stronger **Context Dilution** and more room for **Context Rot**. - **Related:** Raises the cap of the **Context Budget**, but doesn't cancel **Relevance over Completeness**. > **The budget question:** "Am I spending this window's tokens on what genuinely improves the answer — or filling it because there's space, paying in latency, cost, and diluted attention?" > The window is finite and every token costs latency and money. Spend it as a budget — trim, summarise, retrieve only what's needed — and don't let a bigger window end the discipline. ## 6. Context rot and drift In long, multi-step interactions, the context doesn't just sit there — it accumulates and decays. Managing that decay is the hardest and most important part of context engineering at scale. ### 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. _Diagram: With every step the window grows: tool outputs, stale facts, contradictions. The goal sinks to the bottom and reliability falls._ #### Context Rot (context decay, drift) - **What it is:** Quality decay as the accumulated context gets noisier. - **What it looks like:** Stale facts next to fresh ones, contradictions, the original goal sliding out of focus. - **Example:** At step 30 an agent relies on a version of a file it rewrote itself at step 10. - **Gotcha:** A bigger window makes it worse: it gives the rot more room to pile up. - **Related:** Fixed with **Compaction** and **Goal Re-anchoring**. ### 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. _Diagram: The raw transcript (reasoning + tool outputs) is compressed into a running summary: the goal, decisions made, open questions, the current step._ #### Compaction (compressing context as you go) - **Problem:** A long-running agent drags the whole transcript along and starts getting confused. - **Idea:** Finished steps become a short current state; digested tool outputs get dropped. - **Example:** Instead of 200 lines of test log — “tests fail in `auth.ts`, cause: expired token”. - **Cost:** Compression can drop something important — write the summary with care. - **Related:** **Trim & Summarize** for agents; paired with **Goal Re-anchoring** against **Context Rot**. ### 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. _Diagram: Without an anchor every step looks reasonable, but the sum leads astray. With an anchor the goal goes back into the window at every step._ #### Goal Re-anchoring (restating the goal every step) - **Problem:** Over many steps the goal erodes, and the model drifts with the conversation. - **Idea:** Put the goal and the key constraints back into the window at every step. - **Example:** Every agent step starts with a block “Goal: move the API to v2 without changing public methods.” - **Cost:** A couple of lines of tokens per step — cheap compared to drift. - **Related:** Works together with **Compaction**; the first line of the running summary is the goal. > **The drift question:** "In this long interaction, is the window still a sharp, current picture of the goal — or has it rotted into stale, contradictory state the model is now reasoning over?" > Long contexts rot — stale, contradictory state accumulates and quality decays. Compress finished steps into a running summary and re-anchor the goal, because a bigger window only gives drift more room. ## 7. Using it well Context engineering done well is deliberate assembly, measured like everything else. The whole practice comes down to building the window on purpose and checking that it helped. ### 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. _Diagram: By accident — whatever is at hand (the full history, every tool, old logs). On purpose — every part has a decision and a reason._ #### Deliberate Assembly (building the window on purpose) - **Problem:** Context is assembled by accident — and the feature works only sometimes. - **Idea:** Make a decision for every part: system prompt, history, retrieval, examples, tools. - **Example:** The agent gets the 5 tools it needs instead of all 40 — and a short summary instead of the whole history. - **Cost:** Time spent designing the window — paid back in reliability. - **Related:** The habit on top of **Context Assembly**; verified with **Context Evals**. ### 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. _Diagram: The loop: change the context → run the evals → compare the score → keep or revert. Not “glance at one answer and hope”._ #### Context Evals (evals for context changes) - **Problem:** A window change looks better “by eye” — and actually quietly made quality worse. - **Idea:** Every context change gets a run on a fixed test set and a score comparison. - **Example:** History trimmed to 5 messages — run 100 test dialogues and see whether it got better or worse. - **Cost:** You need to build a test set and keep running it — that's work. - **Related:** Checks **Curation**, **Trim & Summarize**, **Compaction**; in depth — the evals course. #### Before you ship an LLM feature - **Is everything the model needs in the window** — or are you expecting it to know what you never gave it? - **System versus user** — durable rules in the system prompt, the request in the user message? - **Would examples help** — is this a case where few-shot beats more instructions? - **Is every piece relevant** — or is padding diluting attention and raising errors? - **Are you within budget** — trimming and summarising rather than dumping everything? - **For long tasks, are you compressing and re-anchoring** against context rot? #### Signs you engineer context well - You fix bad answers by **checking what's in the window** before rewording the prompt. - Durable rules live in the **system prompt**; you reach for **few-shot examples** when shape matters. - You **curate ruthlessly** — relevance over completeness — instead of padding the window. - You treat the window as a **budget**, trimming and summarising rather than dumping. - For long tasks you **compress and re-anchor**, and you **measure** context changes instead of guessing. ### 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. _Diagram: The chain of the course's concepts: from a stateless model to engineering the window, the three forces that degrade it, the practices against them, and evals as the check._ ## Cheat sheet: all 18 concepts ### The window - **Stateless Model** (no memory between calls): Remembers nothing between calls; a chat's “memory” is re-sent history. - **Context Window** (working memory): All the text of a call — the model's only working memory. Not in the window — not at all. ### The shift - **Context Engineering** (vs prompt engineering): Not wording the request, but assembling all the needed information into the window. - **Missing Context** (absent or wrong context): Most bad answers aren't bad phrasing — they're what wasn't in the window. ### Assembling the window - **System Prompt** (vs user message): Durable role, rules, tone, format — versus the one-off request. - **Few-shot Prompting** (examples in context): Show 2–3 “input → output” pairs — the model repeats the shape. - **Context Assembly** (built from parts): The window is assembled in code every call: rules, history, facts, examples, tools, request. ### Relevance - **Relevance over Completeness** (exactly enough): Give the model not everything, but exactly enough. - **Context Dilution** (drowned in noise): Irrelevant tokens spread attention thin and raise hallucination. - **Curation** (ruthless selection): Only the best chunks, trimmed history, nothing that's done its job. ### Budget - **Context Budget** (scarce resource): The window is finite; every token costs latency and money on every call. - **Trim & Summarize** (trim and summarize history): Old turns as a summary, recent ones as is; every token earns its place. - **Long Context Windows** (1M+ tokens): More room isn't permission to dump; the noise and the price remain. ### Rot and drift - **Context Rot** (context decay): Long context piles up stale, contradictory state — quality falls. - **Compaction** (compress as you go): Finished steps go into a short running summary instead of the transcript. - **Goal Re-anchoring** (restate the goal): Put the goal and constraints back into the window at every step. ### Practice - **Deliberate Assembly** (on purpose): Every part of the window has a decision and a reason — not “whatever was at hand”. - **Context Evals** (measure changes): Every window change is checked with tests, not by eye. > Context engineering is deliberate assembly of the window: the right rules, the right facts, the right examples, curated to relevance, kept in budget, and managed against rot — built on purpose and measured, not typed and hoped. End of express course · 7 chapters · 18 concepts Next comes practice: take an LLM feature that sometimes gives bad answers, and before touching the prompt wording, log exactly what was in the window on a bad call — you'll usually find missing, stale, or irrelevant context, not bad phrasing. Then fix the assembly: add the missing fact, cut the noise, summarise the history. The discipline clicks the moment a better-built window beats a cleverer prompt. But hold one idea above the rest: the model only knows what's in the window. Stop trying to coax intelligence out of it, and start engineering what it gets to see — that's where the quality was the whole time.