What goes in the window

In this module you will

Define context engineering and say how it differs from prompt engineering: the prompt is the wording; the context is everything the model sees at this step, chosen again at every step.
Name what competes for the window: rules, tool definitions, history, tool results, retrieved text, notes and the question, and say which of them must never be dropped.
Build a context assembler as four small functions (supersede, trim, select, arrange) plus a wrapper (fence), each testable on its own.
Count a budget honestly: the wrapper around each item costs tokens too, and so does the question.
Measure whether the answer reached the window, separately from whether the model then used it. The first is a fact you can check; the second is a model property you must measure.
Explain, with numbers, four ways "keep everything" fails: the request grows until it is refused, it costs more at every step, old values sit beside corrected ones, and longer inputs are read less well.
Show where a lexical (word-matching) selector breaks, and why that leads to retrieval in module 4.
Stop text from a tool or a user forging your structure, and say what that does not protect against.
Test an assembler: 187 tests, and 29 planted defects to find out which mistakes the tests would miss.
Answer "what goes in the context window, and who decides?" in a way that sounds like someone who has built it.

A model has no memory of its own. Each time an agent calls it, the model sees one string and nothing else. Whatever the agent "knows" at that step is whatever that string contains. So the most important line of agent code, after the loop itself, is the one that builds the string.

That chapter and this one agree on the shape: context is built, step by step, from a larger store, under a budget.

Levels 1 to 6 sent the model a growing list of messages. That works for ten steps and fails for a hundred. This level is how an agent keeps working after that point. This first module is the foundation: given everything that exists and a budget, what does the model see right now? Modules 2 to 8 then add the things that feed that decision (memory, summaries, retrieval, files) and the things that make it cheaper or safer (caching, isolation).

About the examples, and what is real

Everything runs offline in code/mini-window. Real: the assembler (supersede, trim, select, arrange, fence), the budget accounting, the test suite, the planted defects, and one of two "readers": presence, which asks whether the correct answer string is in the text the model would be shown and whether a stale value sits beside it. Those are checks on text, not guesses.

Its numbers are directions, not predictions. The window limit of 12,000 tokens is an imagined small limit chosen so the effect appears in a short run; real limits are far larger, and module 6 covers what happens before you reach them. No real model is called anywhere. Hard exercises say "I did not run this, so your numbers are the ground truth".

Overview