10 Context Engineering in Practice: Deciding What Earns a Place in the Window

June 2026 (24885 Words, 139 Minutes)

1. Introduction

Welcome to Week 10. Lecture 9 did not end with a summary; it ended with an instruction: “Bring the row. Bring the gap.” The row is your Locust step-2 record — one real agent attempt on the fail-to-pass instance you built with your own hands two weeks ago, carrying the estimate you wrote down before anything ran, the bill you read off the meter afterwards, tokens in and tokens out, the cached share, euros or the share of a five-hour usage window the attempt consumed, and solved-or-not as your own test answered it. The gap is the distance between the first number and the second. Put both on the desk now, next to your context budget policy. They are not last week’s homework waiting to be checked; they are this week’s raw material.

Start with the gap, because it is the most personal number in the room. Compare it with your neighbour’s — direction first, magnitude second — and then do what Lecture 9’s reflection prompt already trained you to do: locate the miss. Nearly every gap in the room lives mostly in one term — a prefix \(P\) that was larger than you counted, a per-turn growth \(d\) that one verbose test log dragged past your average, a turn count \(N\) you set optimistically because agents wander and hope persists. Collect the locations on the board and a pattern appears: the misses are locatable. That was last week’s point — calibration, not accuracy. Today’s point is what calibration is for.

Here is the thesis of the day, the sentence to carry to the exam: last week you learned to read the bill; today the terms of the bill become design variables — \(P\) is a prefix you lay out deliberately, and \(d\) is dominated by tool results you can filter, summarise, or isolate. Lecture 9’s closing already named the move: “Context engineering shrinks \(P\) and \(d\) on purpose instead of by accident.” Nothing about the quadratic gets re-derived today, and the worked example keeps its $9.90 exactly as Lecture 9 priced it. The formula is settled; what changes today is your relationship to its symbols — from measuring them to setting them.

First, though, the state of the wall, restated faithfully — because a board that is never restated quietly becomes folklore. The ledger, exactly as Lecture 9 left it:

And — say it once, lightly — the board takes on no new cargo today, for the first time since it went up. That is a decision, not an omission. The marketing has not run dry; you will meet a fresh specimen before the morning is out. But the board’s mechanics have done their teaching, and the discipline they taught now gets practised on unpinned sentences: chapter 8 takes a real marketing claim through Lecture 8’s nine questions as a worked example — same instrument, no ritual, nothing goes up and nothing comes down.

One more artifact comes back today, and it comes back armed. Your context budget policy — drafted in Lecture 7’s lab, given numbers and a cost section in Lecture 9’s — was sent home with a warning attached: “the context-engineering labs ahead will be measured against it.” Today is that lab. Every deliverable in chapter 13 names the policy rule it was checked against, which means the policy stops being a document you once wrote and becomes a standard you answer to — the difference between having opinions about context and having commitments.

The day runs in two movements, matching the two 90-minute blocks in the room. Block A — chapters 2 through 8 — names the discipline and works its first move. Chapter 2 gives the discipline its name, its provenance, and a definition precise enough to disagree with — and cashes a promise Lecture 7 made three weeks ago. Chapter 3 examines the published evidence that curation is forced rather than optional — that bigger windows do not dissolve the problem. Chapter 4 lays out the four moves the whole discipline reduces to. The rest of Block A then works the select move in depth: the instruction file standardised (chapter 5), retrieval industrialised (chapter 6) and split into two live philosophies (chapter 7), and the honesty chapter — what retrieval does not fix (chapter 8).

Block B — chapters 9 through 13 — turns to the other side of the window, and then to practice. Chapter 9 puts a contract on the output side: structured outputs in production, and where their guarantee breaks. Chapter 10 is spending less without knowing less — compression and isolation as quality-bearing decisions rather than bookkeeping. Chapter 11 is the instrument panel: the mid-2026 toolbox you will be operating twenty minutes after meeting it. And the lab arrives in two stages: chapter 12 turns your standing policy into a per-task strategy, and chapter 13 executes the measured before/after on your own Locust instance — the same instance your row on the desk already priced, re-run with a context you engineered on purpose.

Everything in that itinerary hangs off a name the course has owed itself for three weeks — promised in the middle of a chapter about budgets, deferred until the day you could do something with it. Today is that day. The naming, the birth certificate, and the definition are chapter 2.

2. The Discipline Gets Its Name

Chapter 1 ended on a debt three weeks old: a promise made in the middle of Lecture 7’s budget chapter, deferred until the day you could do something with it. This chapter pays it — the promise first, then the provenance, then a definition built for engineers, and finally the algebra that turns the definition into something you can act on this afternoon.

2.1 The promise, kept

When Lecture 7’s context-budget chapter had finished laying out the tenants of the window and the strategies for when it fills, it closed on a sentence this course has been carrying ever since: “Managing this budget deliberately — deciding what enters the window, what stays, what gets summarised, and what belongs on disk instead — is a discipline that Act 3 will give a proper name: context engineering.” Consider the promise kept. That is the name, and today is the day.

Lecture 7’s final chapter then sharpened the promise into a job description. The first item under what Act 3 holds promised that the budget “stops being something that happens to you and becomes something you manage deliberately: policies, layouts, and tooling for deciding what earns a place in the window” — read today’s subtitle again and you will recognise where it came from. The same bullet ended with a forecast: “Your lab policy from today is the seed of this.” Status report on the seed: born in Lecture 7’s lab, costed in Lecture 9’s, and promoted this morning to the standard every deliverable of chapter 13 is measured against. The seed grew on schedule.

Why make ceremony out of a name at all? Because of what names do in engineering: a named discipline can be taught, reviewed against, hired for, and — most useful of all in this course — disagreed with precisely. You have been doing context engineering without the name since Lecture 7’s lab: once, by hand, on your own project. The name marks the change of posture the rest of today enforces — from doing it once to doing it every session, deliberately, against your own written numbers.

2.2 Where the name came from

Honesty about provenance first, because the name is young and the practice is not — the term is barely a year old as of June 2026, and pretending it descended from a textbook would teach you a false history. The naming happened in public, across roughly two weeks of June 2025, in four sentences worth reading in their original wording:

Read the first two rows as the engineers’ rows. Cognition’s sentence is a job description — not “a useful skill” but the #1 job of the people building agents, ranked above the agent’s own code. Lütke’s is an acceptance criterion: “plausibly solvable” is a property of an input that you can argue about, test for, and fail to meet — engineering language, not enthusiasm. Both sentences move the unit of work from the message you write to the context the system assembles.

Karpathy’s row is quoted at full length deliberately, because the sentence is usually truncated and the truncation loses the engineering. The last four words — for the next step — are the agentic part. A chatbot prompt is composed once, for one exchange; an agent’s context is reassembled before every call of Lecture 7’s loop, and “just the right information” is therefore a moving target — what was exactly right at step 12 is ballast at step 13. Cut the last four words and you have described careful prompting; keep them and you have described a control loop.

And Willison’s row is the falsifiable one. “May have sticking power” was a prediction about terminology — the kind of sentence Lecture 8 taught you to respect precisely because it can fail. It did not fail: as of June 2026 the term is the industry’s default name for this work, which is why this lecture can put it in its title without scare quotes.

It is worth noticing what all four sentences quietly assume, because the assumption explains the timing. Cognition’s sentence is about “engineers building AI agents”; Karpathy’s ends on “the next step”; Lütke’s “task” is something the LLM works on, not something it answers in one reply. None of the four describes a chatbot. The name arrived when it did because by mid-2025 the loop you met in Lecture 7 had become the default way these systems were used — and the moment the window became an artifact a system assembles rather than a message a person types, the assembling needed a name.

What happened next is the part that matters for your working life: the coinage industrialised. LangChain published a practitioner taxonomy of the discipline in July 2025 — and that taxonomy is chapter 4’s organising frame, named here and explained there. Manus published production lessons from building an agent at scale in July 2025. Anthropic published “Effective context engineering for AI agents” on 29 September 2025. And the academic literature consolidated in the same season: a survey covering more than 1,400 papers (Mei et al., July 2025) gave the field a bibliography barely three weeks after Karpathy’s post gave it a name. Tweets in June, vendor guidance and a survey by autumn — less an invention than a precipitation.

One footnote keeps the record honest. “Context Engineering 2.0” (October 2025) traces the practice back to the context-aware computing of the 1990s: systems that decided what a machine needed to know about its situation existed decades before the transformer. So state the provenance precisely — 2025 named and unified an older practice; it did not invent one. That is no mark against the term: “technical debt” was also a new name for something every team already had. But it should inoculate you against anyone selling the discipline as last summer’s discovery.

2.3 A definition for engineers

Synthesised from those four sentences for this course’s use: context engineering is deciding what earns a place in the window — every token, deliberately, against a budget. Each word is load-bearing. Earns is Lütke’s acceptance criterion pointed at a single token: presence must be justified by a contribution to the task being plausibly solvable. A place concedes Lecture 7’s geometry — places are finite, and “a token granted to one is a token denied to another”. And deliberately — Karpathy’s “delicate art and science” — is the posture: the window’s contents stop being an accident of the session’s history and become a decision somebody made, where somebody is you.

The clause the quoted founders did not need and you do is the last one: against a budget. An art can be practised on taste; a discipline answers to numbers, and the numbers are yours — the policy on your desk has a maximum CLAUDE.md size, a restart threshold, and a cost rule with a counter attached. The definition without the budget clause describes a sensibility; with it, it describes work that can be reviewed, which is the standard this course holds everything to.

Notice also what the definition quietly relocates: the unit of engineering. Prompt engineering is the craft of one message — your message. But the model has never seen your message as a privileged object: it sees one token sequence, flattened, in which your prompt is one tenant among many. Revisit Lecture 7’s tenant table and count: seven tenants, of which you author perhaps two, while the largest — tool results, conversation history — were typed by nobody. Context engineering is the engineering of that whole sequence, over a whole session, including every token you never wrote.

Which settles a question you will be asked at work: no, prompt engineering is not dead. It is a subset, not a casualty. Lecture 6’s patterns remain exactly what they were — the per-message craft of phrasing, structuring, and steering a single instruction — and nothing today retires a word of them. What changed is the altitude of the job around them: the craft of one message now sits inside the engineering of the token stream that message lands in. If anything the demotion is a promotion — the skill generalised from the tokens you type to all of them.

The definition also hands you a working test you can run on any window, mid-session, today: pick a token and ask two questions — what is it doing for the next step, and what did its presence displace? Every chapter that follows applies this test at a different layer — to instruction files, to retrieved chunks, to outputs, to the session’s own history. If the test sounds expensive to run by hand, that is correct, and most of today is about the machinery that runs it for you.

2.4 P and d become design variables

A definition earns its keep in this course only when it binds to variables you can measure, and this one binds to three you have already measured on your own work. The quadratic — cited here, never re-derived — decomposed an agent session’s input into a fixed prefix \(P\), a per-turn growth \(d\), and a turn count \(N\). Last week those were measurement categories: you estimated each, measured the total, and located your miss. Today they change status. A design variable is a quantity somebody chooses — and from this morning on, the somebody choosing \(P\) and \(d\) is you.

Take \(P\) first. The prefix is the part of the window you control byte for byte — beyond the vendor’s system prompt, you wrote or installed every token of it — and Lecture 9 priced the consequence of treating it casually: a recurring charge, billed once per turn, so that almost all of the worked example’s $9.90 was, in Lecture 9’s words, “the same tokens, re-sent”. Laying it out deliberately is therefore not an aesthetic preference; the prefix is the linear term of your bill, chosen in advance.

Now \(d\). Lecture 9 was explicit about what sets it: “it is the tool side, not the reply side, that will set the number” — per-turn growth is dominated by tool results, the one verbose test run, the whole-file read, the stack trace. And tool results are exactly the material you can filter before it enters, summarise once it has served, or isolate into a window you intend to throw away. \(N\), the only symbol that enters the formula squared, yields to planning — fewer, more substantial turns. None of this is new advice: Lecture 9 §9.4 already named the three levers — keep \(P\) lean, keep \(N\) small, cap the accumulation — as consequences of the arithmetic. What is new today is their status: three sentences of advice in a pricing lecture are about to grow into a discipline with names, tooling, and published evidence behind it — the four moves of chapter 4, which this chapter deliberately leaves unexplained.

Be precise about the limits of the new ownership, though, because design variables come with constraints attached. The vendor’s system prompt is the landlord’s share of \(P\), not yours to trim; and Lecture 7’s tenant table was blunt about the largest source of \(d\) — the task dictates the tool results, “because you do not get to choose how long a stack trace is”. What you do get to choose, from today, is what happens to that stack trace next: whether it enters whole, enters filtered, gets summarised after it has served, or never touches your main window at all. Design within constraints is not a diminished form of design; it is the only kind engineering has ever had.

And one design variable hides inside another: layout. Prompt caching pays for prefix discipline — the discount that took the worked example’s bill from $9.90 to roughly $1.39 is earned only by a prefix that stays byte-for-byte stable across calls, which makes the order of \(P\)’s contents a design decision alongside their size. Stable material first, volatile material last: the rule was Lecture 9’s; making it a habit is today’s.

All of which rests on a premise worth doubting out loud: that deciding what earns a place still matters when places are abundant — when vendors advertise windows of a million tokens, as of mid-2026, and the obvious strategy is to stop deciding and start stuffing. If that strategy worked, context engineering would be a transitional artifact and this lecture a eulogy for it. It does not work — but a claim that large deserves better than folklore, and better than a three-week-old slogan. The published, measured evidence that curation survives the million-token window is chapter 3.

3. Why Bigger Windows Don’t Save You

Chapter 2 gave the discipline its name, its provenance, and a definition: deciding what earns a place in the window — every token, deliberately, against a budget. But a definition is worth nothing if the problem it answers is about to dissolve on its own, and there is an obvious candidate for the dissolving. Million-token windows are table stakes at the frontier as of June 2026 — you read them down the Context column of Lecture 9’s pricing table — and a million tokens holds several novels’ worth of text. If the window fits everything, why decide what earns a place? Stuff the repository in, stuff the documentation in, and let attention sort it out.

That reflex deserves a proper execution rather than a dismissive wave, because the trend behind it is real: Lecture 7 §10.2 traced context windows growing three orders of magnitude in roughly seven years, and the growth has not stopped. What does not follow is the conclusion that curation is obsolete, and this chapter shows it does not follow — in three steps. First, the evidence you already own from Act 2, linked rather than re-taught (§3.1). Second, the evidence published since, which is sharper and closer to your daily work than anything Lecture 6 had available (§3.2). Third, the argument that needs no quality evidence at all: the invoice (§3.3).

3.1 The evidence you already own

Most of the case was on the table weeks ago. Lecture 6, chapter 7 taught lost in the middle in full, and it is not re-taught here: retrieval accuracy as a function of where information sits in the context is U-shaped — strong at the beginning, strong at the end, twenty percentage points or more weaker in the middle — and the dip sharpens as the context grows. Hold that last clause against the sales pitch: a bigger window is, by construction, a longer middle.

Lecture 6 §7.2 already cited Chroma’s Context Rot report, so its headline needs only one sentence here: across 18 frontier models, performance grows increasingly unreliable as input grows — even on tasks that stay simple. The effect was universal; only its shape varied by model.

Underneath both empirical curves sits the mechanism of Lecture 6, chapter 6: attention mass is a normalised sum spread across every position in the sequence, so every token you admit taxes the attention available to every token already there. Stuffing is not neutral storage. It is active interference, and it is priced in a currency — attention — that window growth does not mint more of.

What is new today is who concedes the point. Anthropic’s engineering post “Effective context engineering for AI agents” (September 2025) calls context “a critical but finite resource” and describes the model as spending an “attention budget” that is drawn down by every token added. Note the author. The company selling some of the largest windows on Lecture 9’s table is the company writing, in its own engineering documentation, that the resource is finite — the constraint is not a critic’s complaint from outside the industry; it is the vendor’s own position, in the vendor’s own words.

3.2 The evidence that arrived since

Lecture 6’s evidence still left a sceptic one retreat: the degradation results concern awkward synthetic retrieval, while the vendors’ own needle-in-a-haystack tests show near-perfect scores at full window length. NoLiMa (Adobe Research and LMU Munich; arXiv, February 2025 — figures pinned to the v1 paper) took the retreat away by asking what those near-perfect scores actually measure. In the classic test, the needle shares words with the question — ask about the character who visited Dresden, and the needle literally contains visited Dresden — so finding it rewards lexical matching, not comprehension. NoLiMa removes the overlap: question and needle are connected only by an associative hop, and the model must understand rather than string-match.

The flattery collapses with the crutch. Of the 12 models tested — every one advertising a window of 128K tokens or more — 10 fall below 50% of their own short-context baseline by 32K tokens: at a small fraction of their advertised capacity, less than half the competence they showed when the context was short. GPT-4o, the strongest model in the study, dropped from 99.3% at short lengths to 69.7% at 32K. The figures describe early-2025 models and have aged accordingly; the methodological lesson has not. A perfect haystack score can be string matching wearing the costume of long-context comprehension, and the costume comes off the moment the words stop matching.

The second new result moves from retrieval scores to your daily genre. SlopCodeBench (arXiv, March 2026) — emerging work, not yet peer-reviewed, and to be weighted accordingly — evaluates long-horizon coding agents checkpoint by checkpoint and reports structural erosion accumulating in 77% of trajectories: as the session grows, the code the agent writes does not merely stall, it degrades structurally, with agent code measuring 2.3× more verbose than the human reference. If those figures hold up under review, they extend the degradation story from where the literature had it — can the model find a fact in a long context — to where you live: what happens to code quality over the length of a real session.

Set the five pieces side by side and the pattern is monotone. Long-context capacity and long-context competence are different quantities, and every published measurement so far has found the second one smaller.

3.3 The cost side seals it

Now grant the sceptic everything anyway. Suppose a model arrives next quarter that retrieves perfectly from a packed million-token window — no U-shape, no rot, no dilution. The case for curation survives the supposition, because Lecture 9, chapter 9 is not about quality at all. The API is stateless; the orchestration loop re-sends the whole conversation on every call; total input therefore grows with the square of the session’s length — and every careless token admitted to the array is re-billed on every subsequent call, \(N\) times over a session. The worked example’s $9.90 of input was almost entirely that mechanism at work: the same history, re-sent fifty times, with the genuinely new text a rounding error beside the repetition.

And a bigger window makes the arithmetic worse, not better, because capacity is an invitation: more room means longer sessions before anything forces a reset, a fatter prefix \(P\), heavier per-turn growth \(d\) — every term of the formula nudged upward — and Lecture 9’s pricing chapter added that the largest, late-session calls are exactly the ones that cross the context thresholds where the per-token price itself steps up. Even if quality survived the stuffing, the bill would not: the quadratic re-bills every careless token \(N\) times, so quality and cost point the same way — at curation.

Lecture 7 reached this verdict before most of this chapter’s bibliography existed, from the attention arithmetic alone, and it is worth quoting exactly as §10.2 there printed it: window growth bought headroom, not immunity — and a bigger window makes attention dilution more relevant, not less. In Lecture 7 that sentence was a mechanistic argument. Today it is a defended position: NoLiMa quantifies the missing immunity, SlopCodeBench shows the decay reaching code, the vendor concedes the budget in writing — and the invoice would enforce the same conclusion even if every quality result above were somehow wrong.

So curation is forced, three times over — by attention, by measurement, by invoice. But curate is a verdict, not a procedure: knowing that you must choose says nothing about what the choices are. The practitioners who named the discipline in chapter 2 also catalogued its options, and the catalogue turns out to be remarkably short: four moves, every one of them machinery you already own. Naming them — and discovering that everyone’s catalogue is secretly the same list — is chapter 4.

4. The Four Moves

Chapter 3 closed every escape route: attention degrades with length, the measurements confirm it, and the invoice would force curation even if they did not. So curation it is. But a forced conclusion is not yet a practice — deciding what earns a place in the window needs a repertoire, a short list of things an engineer can actually do when the answer to “does this earn its place?” is no.

This chapter supplies the repertoire, and its punchline is how little of it is new. Four moves organise every intervention the rest of this lecture teaches — and every one of them is machinery you already operate, described in full by Lecture 7, now renamed from something the tool does into something you decide.

4.1 Write, select, compress, isolate

The taxonomy comes from the practitioner side of the provenance trail chapter 2 walked: LangChain (Lance Martin) published it in July 2025 — it had appeared on Martin’s personal blog in late June, and the LangChain page carries no byline, which is why the attribution names both. Four verbs: write — save context outside the window; select — pull in only what is needed; compress — retain only the tokens required; isolate — split work across contexts. Every context intervention you will meet today, and most you will ever meet, is one of these four or a composition of them.

Write is the move you have been making since Lecture 3 without the name. A CLAUDE.md is project knowledge written to disk once instead of re-explained every session — Lecture 7, chapter 4 traced exactly how that file becomes tokens — and the memory files of Lecture 7, chapter 5 are the same move executed by the model itself: notes written outside the window so that no window ever has to carry what the disk can hold. Lecture 7’s habit — the disk is the durable record, the window is scratch space — was write all along.

Select is the complement: of everything written, pull into the window only what this task, at this step, needs. The loader’s two rules from the same Lecture 7 chapter are select implemented as if-statements — the directory walk at session start, the on-demand injection when a tool first touches a subtree — and skills are select with a price structure: descriptions always loaded, bodies only on invocation. New today is the third implementation, where a program rather than a person decides what gets pulled in: retrieval. Chapters 6 through 8 are select industrialised, debated, and audited.

Compress is what happens when the window fills anyway: retain the information, shed the tokens. Lecture 7 §10.3 named the strategies — sliding windows, recency cut-offs, summarisation — and Lecture 9 §9.4 gave the move its economics: replace old history with bounded summaries instead of dragging every tool result to the end of the session. What a summary costs in information — the quality side of that trade, which Lecture 9 deliberately deferred — is chapter 10’s subject.

Isolate is the only move whose deployment is genuinely new today, and even it is new only as deployment, not as concept. Lecture 7’s message array is the data structure behind every session you have ever run; a subagent is nothing more exotic than a different message array — a separate window in which heavy exploration happens, with only a distilled result returning to the parent. The mechanism is explained properly in chapter 10; for now, hold the shape: when context cannot be compressed without losing what matters, give it somewhere else to live.

Here is the same map as a table — the frame the rest of the lecture hangs from:

Notice what the taxonomy does not contain: anything mechanically new. The difference between Lecture 7 and today is not the machinery — it is the agency. Lecture 7 described what the orchestration layer does; the four verbs describe what you decide. The same directory walk that was a mechanism three weeks ago is now a select policy you can second-guess, and a CLAUDE.md that was a file format is now a write decision with a budget attached.

4.2 The same map in vendor language

If the taxonomy were one company’s framing, it would be a blog post, not a discipline — so test it against a vendor who never uses LangChain’s verbs. Anthropic’s “Effective context engineering for AI agents” (September 2025 — the same post that conceded chapter 3’s attention budget) names four techniques for long-horizon agents: compaction, structured note-taking, sub-agent architectures, and just-in-time retrieval. Lay them over the verbs and the territory maps one-to-one: compaction is compress, structured note-taking is write, sub-agent architectures are isolate, just-in-time retrieval is select. And the academic cut slices the same territory a third way — a 1,400-paper survey (Mei et al., July 2025) organises the field as retrieval, processing, and management — without surfacing any operation the four verbs miss.

The taxonomies differ; the moves are stable — and that stability is what makes context engineering a discipline rather than a tips list. Tips are tool-shaped: they expire with the next release, the next renamed command, the next default flipped. The moves are constraint-shaped: they exist because attention is finite and re-sending is quadratic, and chapter 3’s constraints will outlive every tool this lecture names. When a practitioner taxonomy, a vendor playbook, and an academic survey converge on the same underlying operations from three directions, you are looking at structure, not fashion.

You have heard this move before, one week ago, about prices: learn the structure; look up the numbers — Lecture 9’s instruction for a pricing table that drifts. The same instruction now applies to your tooling: mechanics drift — chapter 11 will stamp every one of its commands “as of mid-2026” for exactly that reason — but the four moves are what you re-derive the mechanics from when they do.

4.3 The picture, unchanged

A frame this central would normally earn the course diagram a new version. Today, deliberately, it does not. LLM-in-One-Picture stays at v1.4 — the evaluation-harness ring Lecture 8 drew around the orchestration layer of Lecture 7’s final Act 2 picture, structurally untouched — and what the four moves add is annotation, not architecture. Write and select are labels on the arrows where context enters the window; compress is a label on the message array between turns; isolate is the observation that the whole picture can be cloned in miniature — a second, smaller window beside the first, connected by one thin arrow carrying a summary back. Labels on the orchestration ring. No new boxes, no new arrows, not even a new version number.

That restraint is the chapter’s thesis in geometric form. The picture does not change today — what changes is who is driving it. Up to Lecture 7 the diagram described what the system does around you: the loader loads, the array grows, the evicter evicts. Read after this chapter, the same diagram is a control panel — every annotation marks a decision that has so far defaulted to the tool and is now yours to make on purpose. The picture’s final version, v2.0, stays reserved for the final lecture; nothing about taking the controls requires redrawing the machine.

The four verbs also lay out the rest of the day. Chapter 5 works write and select at the human level — the instruction file, now standardised across tools. Chapters 6, 7 and 8 work select at the algorithmic level: the canonical pipeline, the live industry split over code, and the honest account of what selection cannot fix. Chapter 9 crosses to the output side of the window — the shape of what comes back. Chapter 10 works compress and isolate as quality-bearing decisions. Chapter 11 supplies the instruments, and chapters 12 and 13 turn all of it into a written strategy and a measured lab.

First verb first, then. The oldest written context in your projects — the instruction file you have curated since Lecture 3 and rebuilt in Lecture 7’s lab — has spent the past year acquiring something it never had before: a cross-tool standard with a spec, a foundation behind the spec, and one prominent holdout. That standard is AGENTS.md, and turning it from a name you have heard into engineering practice in your own repository is chapter 5.

5. Instruction Files as a Standard: AGENTS.md

Chapter 4 closed on a map, and this chapter is the map’s first stop: the write and select moves at the human level. The instruction file — the artifact chapter 4 just called the oldest written context you own — executes both moves at once: write, because it stores project knowledge on disk, outside the window, where it survives every session; select, because a loader decides which parts of it enter which conversation. Nothing about the file is new today. What is new is the engineering reading of it.

That reading was promised to you, word for word. Lecture 7’s closing chapter listed the themes of Act 3, and the second was this: “Instruction files as cross-tool standards. AGENTS.md, and what chapter 4’s loading mechanics look like once the industry converges on shared conventions instead of per-tool file names — the answer to mystery 8, already complete as of today, turned into engineering practice.” This chapter is that practice. Notice what the promise does not ask for: the mystery itself was retired in Lecture 7’s final board closure, and nothing today reopens it. What remains is engineering.

The record so far fits in one paragraph, because Lecture 6 §6.1 already told the story and we will not retell it: every modern AI coding tool reads at least one instruction file from the project root; across vendors the file name has converged on AGENTS.md; the convention was born in August 2025 at OpenAI and donated in December 2025 to the Agentic AI Foundation under the Linux Foundation — on 9 December, to be exact, alongside Anthropic’s MCP and Block’s goose, two details today adds to Lecture 6’s record. Lecture 6 put the pattern and the governance on the record; Lecture 7, chapter 4 supplied the loading mechanics for one concrete tool.

What neither lecture did is read the standard as an engineering document. So that is the plan: what the spec actually specifies (§5.1), how its reference loader budgets (§5.2), who really reads it (§5.3), what our own tool does about it (§5.4), and what the first published measurement of the file’s value found (§5.5).

5.1 What the spec actually says

Open the spec expecting a schema and you will be disappointed in a way worth dwelling on. AGENTS.md is defined as “a README for agents”: a plain Markdown file, “use any headings you like”, no required fields, no required sections, nothing to validate against.

A specification that specifies almost nothing about content is a design statement, not an omission. The authors are telling you that what you write is your project’s business — conventions, test commands, architecture notes, whatever your repository needs an agent to know — and the standard’s only job is to make sure every tool looks for it under the same name. Radical smallness is also an adoption strategy: a spec with no schema has no compliance cost, and a file that is just Markdown can be adopted by a tool in an afternoon.

What the spec does fix — the part with engineering content — is loading behaviour, and it fixes exactly two rules. Rule one: the nearest AGENTS.md wins. In a repository with several such files, the one closest to the code being worked on takes precedence — which is monorepo support in one sentence: a root file for the conventions every team shares, per-package files for each team’s own.

Rule two, verbatim from the spec: “explicit user chat prompts override everything.” Whatever the file says, the human typing in the session outranks it. The file is a default, never a cage — standing instructions for the unattended case, overridden the moment you state an intention that conflicts with them.

Put the two rules next to each other and notice what kind of rules they are: not content rules but precedence rules — answers to “which tokens enter, and which win when they conflict”. The spec standardises the file; it conspicuously does not standardise the loading strategy. Every tool still answers the two questions Lecture 7, chapter 4 said every tool must answer — which files to read, and where in the sequence to splice them — in its own way. Which makes it instructive to watch two loaders answer them differently.

5.2 Two loaders, one lesson

The cleanest worked example is the reference implementation: OpenAI’s Codex, documented in its AGENTS.md guide. Codex resolves a global chain first — ~/.codex/AGENTS.override.md if present, then a personal AGENTS.md — and then walks the project scope from the git root down to the working directory, picking up at most one AGENTS.md per directory and concatenating root-down, so that the nearest file arrives last and wins.

You already own the other answer to the same questions. Claude Code walks from the working directory up the tree, collects every ancestor CLAUDE.md, concatenates them near the top of the message array, and lazy-loads subdirectory files only when a tool call first touches that directory — Lecture 7’s two rules, which you can recite by now. Side by side, as of mid-2026:

Same two questions, different answers — and the differences are not cosmetic. A down-walk with one file per directory and last-wins precedence is an override model: the loader resolves conflicts before the model ever runs. An up-walk that loads everything is a union model: every file is present, and disambiguation is outsourced to the attention mechanism you studied in Lecture 5.

Two defensible designs, one trade — mechanical predictability against mechanical simplicity — and neither is mandated by the spec, which is the point: the standard standardises the file, and the strategy remains each tool’s signature.

But the row to stare at is the third one. Codex ships with a default combined budget of 32 KiB for instruction files, full stop: beyond that, the loader simply stops including content. That is not advice, not a lint warning, not a best practice in a blog post. It is a context budget, enforced by production software, on by default.

You wrote that rule yourself. Your context budget policy acquired a max-CLAUDE.md-size rule in Lecture 7’s lab, and Lecture 9’s lab attached a token counter and a cost rationale to it. Your policy’s max-size rule has a production analogue: the reference implementation of the industry’s instruction-file standard enforces a context budget by default — the budget discipline this course made you write down is what the standard’s own authors decided a loader should impose on every project, unasked.

When a default in shipping software agrees with a rule in your policy document, take the agreement seriously: two independent parties looked at the same failure mode — instruction files that grow without limit — and reached for the same instrument. Keep that convergence in mind for §5.5, where it acquires data.

5.3 Adoption, as of June 2026

Lecture 6 stamped its tool-support list “April 2026 snapshot” and attached the sentence that licenses this whole subsection: “This snapshot will date; the pattern will not.” Two months on, here is the updated snapshot, carrying the same warranty. As of June 2026, the spec site’s self-reported compatibility list names roughly two dozen tools, and the adoption figure stands at more than 60,000 open-source repositories containing an AGENTS.md — a December 2025 count that, as of June 2026, is still the figure the spec site itself quotes, so it is the one this lecture quotes too. No verified larger number exists; we do not inflate.

Read both figures with the qualifiers they come with, in the spirit of Lecture 8: the compatibility list is self-reported by the listed tools, and the depth of what “compatible” means varies widely — from full nearest-file precedence to reading a single root file when a setting allows it.

The teaching nuance — the part a checklist reader misses — is that “listed as compatible” and “reads it by default” are different claims, and the gap between them is where portability projects quietly fail. Three examples, all as of June 2026.

Gemini CLI defaults to its own GEMINI.md and reads AGENTS.md only after a one-line settings opt-in (context.fileName) — listed, supported, and off until you act. VS Code reads a root-level AGENTS.md via a setting (chat.useAgentsMdFile), with nested per-directory support still experimental — whether your monorepo layout works is a question about configuration, not about the listing. And Zed checks legacy files — .rules, .cursorrules — before AGENTS.md in its first-match order, so a leftover legacy file in the repository silently shadows the standard one.

The engineering habit to take from this is the one Lecture 9 taught for pricing pages: the durable skill is the verification procedure, not the snapshot. Before you rely on any tool reading your AGENTS.md, probe it — put a detectable instruction in the file and check the behaviour. Sixty seconds of probe beats any compatibility table, including this lecture’s.

5.4 The Claude Code bridge

Which brings us to the course’s own tool, and the most instructive wrinkle in the whole adoption story. As of mid-2026, Anthropic’s documentation says, verbatim: “Claude Code reads CLAUDE.md, not AGENTS.md.”

What has changed since Lecture 6 — which called the workaround a community pattern — is that the bridge is now officially documented: a CLAUDE.md whose body is the single import line @AGENTS.md (the recommended form on Windows), or a symlink (ln -s AGENTS.md CLAUDE.md) where symlinks are dependable.

The docs go further: /init now incorporates an existing AGENTS.md when it scaffolds a CLAUDE.md, and reads other tools’ configuration files — .cursorrules, .devin/rules/, .windsurfrules — while it is at it.

There is no new mechanism to learn here, because the import is Lecture 7, chapter 4’s @-reference resolution doing what it always did: “by the time it runs, the indirection has already been flattened into tokens.” The model never knows which file name your conventions lived in; the loader erased the distinction before the first forward pass.

The tension deserves to be named honestly rather than smoothed over. Anthropic co-founded the Agentic AI Foundation and sits as a platinum member of the body that stewards AGENTS.md — and yet native support for the standard remains the most-watched open feature request on Claude Code’s tracker: issue #6235, open since 21 August 2025, with roughly 4,100 upvotes and over three hundred comments, and no committed timeline, as of mid-June 2026.

The bridge is one line; the flattening mechanism has shipped for over a year; nothing technical is missing. Standards adoption is a strategy decision, not a technical limitation — and the gap between a vendor’s governance seat and its product’s default behaviour is a fact about incentives, not about engineering. This is, flatly, the likeliest fact in this lecture to have flipped by the time you read it: re-verify it the week you need it, against the docs and the issue, not against this paragraph.

Either way, the engineering answer is already in your hands. The lab homework (chapter 13) has you configure exactly this bridge in your own Locust project: extract the cross-tool content into AGENTS.md, leave the Claude-specific remainder plus the one-line import in CLAUDE.md, and verify the load. Two files, one source of truth, portable by construction.

5.5 The minimalism result

One question remains that neither the spec nor any vendor answers: does the file actually help? For most of the convention’s life the honest answer was “everyone assumes so”. Since February 2026 there is a first measurement.

Gloaguen et al., “Evaluating AGENTS.md” (arXiv:2602.11988) found that on the benchmarks tested, context files tend to reduce agent task success rates while adding more than 20% inference cost. Mechanically, neither half should surprise you: the file’s tokens are paid in attention competition on every generation step, and re-billed on every turn by Lecture 9’s quadratic — and on these benchmarks, the measured benefit did not cover the bill. The study’s recommendation: minimal, human-written files.

Treat the result with Lecture 8’s discipline: one study, on particular benchmarks, with particular agents — evidence, not consensus, and presented here as exactly that. But notice whose side the evidence lands on. The spec’s own advice is to keep the file small; your policy caps its size in tokens; Codex’s loader caps it in KiB; and the one published measurement says the cost of overstuffing is real and the benefit is not guaranteed. Four independent signals, one direction.

The operating rule, then, is the one Lecture 7 already gave you, now with data behind it: anything in the file that is only relevant to one kind of task is a skill waiting to be extracted — zero tokens until invoked, instead of a standing tax on every session. The instruction file earns its place in the window the same way every other tenant does: line by line, against the budget.

And that sentence marks this chapter’s limit. An instruction file is context selected by a person: you decide, in advance and by hand, what every session should know, and a loader’s dumb rules do the injecting. The select move has a second, altogether more ambitious form — a program that decides, per query and at runtime, which tokens out of a corpus too large for any window are the relevant ones. That is retrieval, and it is chapter 6.

6. Retrieval: The Select Move, Industrialised

Chapter 5 left the select move in human hands, and deliberately so: a loader decides where an instruction file gets spliced, but a person decided every line of what. This chapter hands that second decision to a program. It is also where the course pays the last of the three promises Lecture 7’s closing chapter aimed at this lecture, and the promise is worth quoting in full: “Embeddings have been familiar since Lecture 4; retrieval is what happens when a program, not a person, uses them to find the most relevant tokens and inject them — the orchestration layer’s file-loading rules, generalised into search.” Due today.

The seed is older still. When Lecture 7’s memory chapter noticed that a directory of notes read at startup is a minimal external knowledge store, it looked ahead to exactly this moment: Act 3 would meet the same architecture again, scaled up, under the name retrieval — “where an algorithm replaces the filesystem walk in deciding what gets injected.” The whole upgrade fits in one sentence. Lecture 7’s loader selects context by directory traversal; retrieval selects it by similarity search — a program, not a person, now decides what gets injected into the window.

That sentence also names the fault line this chapter and the next one sit on: algorithmic versus human-curated context selection. Mind the versus — it is not replaced by. Both options remain live engineering practice as of mid-2026, and chapter 7 is the industry’s genuinely unresolved argument about which one your code deserves. First, though, the machinery — which, it will turn out, you already own almost all of.

6.1 Embeddings become a search engine

Nothing in this section is new mathematics. Embeddings have been on your desk since Lecture 4’s embedding table turned token IDs into vectors of learned numbers, and Lecture 5 made the geometry usable: the dot product and cosine similarity as the measure of how aligned two vectors are, and the t-SNE and UMAP projections that let you see that nearby vectors mean related things. None of it was taken on faith, either: in the Lecture 5 notebook you computed cosine similarities over real pretrained embeddings with your own hands — nearest neighbours, code-versus-prose clusters, king − man + woman ≈ queen.

A retrieval system is that notebook exercise, pointed at a corpus and run as infrastructure. Embed the query — the question being asked, the agent’s current need — into a vector. Embed every chunk of the corpus — every documentation section, every ticket, every function — into vectors of the same dimensionality, ahead of time. Rank the chunks by cosine similarity to the query. Inject the top-\(k\) winners into the context window. That is the entire idea — nearest-neighbour search in embedding space, run as a search engine — and everything downstream of this sentence is engineering around its failure modes.

One genuine difference from the notebook deserves its own sentence. There you compared word embeddings, one vector per token; a retrieval system assigns one vector to an entire passage, produced by an embedding model trained so that texts about the same thing land near each other in the space. The vectors got wider and the corpus got larger. The operation at the centre — a dot product, normalised — is the one you have already computed by hand, and that is the demystification to hold on to whenever a product page says “semantic search”: it is the Lecture 5 arithmetic, at scale.

Why select algorithmically at all? Because the corpora worth searching do not fit. A real project’s code, documentation, tickets, and history exceed any context window — and even where they would technically fit, chapter 3 has already shown you what indiscriminate stuffing does to quality, and Lecture 9’s quadratic what it does to the bill. Retrieval is the budget answer to both constraints at once: pay for the \(k\) most relevant chunks instead of the corpus.

6.2 The canonical pipeline

The production version of the idea has a lineage worth naming exactly once: retrieval-augmented generation — RAG — after Lewis et al., NeurIPS 2020, whose title hardened into the generic name for the whole architecture: retrieve first, then generate conditioned on what you retrieved. What the industry built on that name is a pipeline of six stages — chunk → embed → index → retrieve → rerank → inject — and the stages are stable even where the products churn, which is why this section names stages and deliberately tours no vendors:

The offline–online split is the pipeline’s economic logic: the corpus is embedded once, the query at question time, so the expensive preparation amortises across every search. And of the six stages, the least glamorous is the most consequential. Where you cut decides what can be found: split a function across two chunks and neither half answers a question about it; make chunks too large and one match drags a thousand irrelevant tokens into the window with it. Chunking is a judgement call frozen into infrastructure — the curation question of chapter 5 did not disappear when the algorithm took over; it moved upstream.

Note also where all six stages live: in the orchestration layer — Lecture 7’s “simple but active” software, doing one more active thing. The model never sees the pipeline. It sees tokens that arrived in its window, with no marker of the machinery that put them there.

6.3 Why every stage exists

A fair question at this point: if cosine ranking is the whole idea, why do production pipelines carry the extra stages? Because the one idea fails at measurable rates, and each stage was added to buy the failure rate down. The cleanest published ladder of numbers comes from Anthropic’s contextual-retrieval post (September 2024) — measured on the vendor’s own evaluation sets, so the figures carry the usual Lecture 8 flag — but the shape of the ladder is the teaching:

One row needs a gloss before the lessons. Contextual embeddings attack a failure baked in at the chunking stage: a chunk ripped out of its document forgets where it came from — “the function returns the cached value” embeds poorly when nothing says which function, in which module. The fix is to prepend each chunk with a short, model-generated note situating it in its source before embedding, so the vector carries its surroundings. A patch, in other words, for a wound the pipeline’s own first stage inflicts.

Two lessons, and the first is the one practitioners relearn most often: hybrid beats pure-dense. BM25 is a ranking function over exact lexical matches — grep’s cousin — and it rescues precisely the cases embeddings fumble: the error code, the function name, the identifier that must match character for character. A query and its answer can share meaning and no words, or share every word and no meaning; dense and lexical search therefore fail on different queries, which is exactly why running both beats running either. Lexical match never stopped mattering — a sentence to keep warm, because chapter 7 is largely a fight about it.

The second lesson is about the pipeline as a whole. Read the table top to bottom and each row exists because the row above it fails at a known rate: contextual embeddings exist because naive chunks lose their surroundings, hybrid exists because dense search misses exact strings, reranking exists because fast similarity scoring is a blunt judge of relevance. Every stage of the canonical pipeline exists because the stage before it fails at a measured rate — the pipeline is not architecture for its own sake but a stack of patches over published failure modes. When you meet a retrieval product, that is the question to put to each component it advertises: which measured failure is this stage buying down?

One placement observation closes the loop with everything you know. Whatever the pipeline retrieves lands in the same message array as everything else — and Lecture 7’s completed three-layer model already ruled on what that means: “anything that enters the token sequence is influence-layer material — whoever wrote it, whenever it arrives.” Retrieved chunks shift the distribution; they do not command it (Lecture 6’s verdict, unchanged). They compete for attention with every other tenant of the window, they can be ignored, and they can be wrong. Retrieval upgrades the selection of context, not the physics of what happens to context once it is in.

So the pipeline exists, its stages earn their keep against measured failures, and its output is ordinary influence-layer material. But before you deploy any of it on the material you touch every day, a prior question needs answering, and the industry has not answered it: does code want this pipeline at all? Two camps, both shipping production systems, both publishing their reasons — chapter 7 stages the argument.

7. The Two Retrieval Philosophies for Code

Chapter 6 handed you the canonical pipeline and the measured reason for each of its stages, and for prose corpora — documentation, tickets, knowledge bases — that pipeline is settled engineering: chunk, embed, go hybrid, rerank, done. Point the same pipeline at a codebase, however, and the agreement stops. As of mid-2026 the industry is genuinely split into two camps — serious, well-resourced organisations on both sides, shipping production systems and publishing their reasons — and the split is not a marketing skirmish but a real disagreement about what kind of corpus code is.

A disclosure before the fight starts: this course runs on Claude Code daily, and Claude Code is the flagship of one of the two camps. That is precisely why the other camp goes first, at full strength. A house tool is a bias to correct for, not an argument — and the index camp’s case is strong enough that no strawman survives contact with it.

7.1 The index camp

The index camp’s position: a codebase is a corpus like any other, so build chapter 6’s pipeline over it and keep the index fresh. Cursor is the camp’s most prominent member, and as of mid-2026, per its own documentation, the implementation is exactly the canonical pipeline wearing an IDE: code is split into semantic chunks, embedded with a custom-trained embedding model, and stored in a vector database; the index is re-synced incrementally about every five minutes, using file-hash comparison over a Merkle tree so that only changed files are re-embedded. One design detail the vendor emphasises, worth recording fairly: the embeddings are stored, the plaintext is discarded — the index holds vectors about your code, not a copy of it.

The camp’s headline evidence arrived in November 2025, when Cursor published an internal benchmark: adding semantic search on top of grep gave on average 12.5% higher accuracy answering codebase questions — a range of 6.5 to 23.5% depending on the model — with the biggest gains on codebases of a thousand files and more. By now a bell should be ringing of its own accord: this is a vendor eval, on a vendor benchmark, reported on the vendor’s blog. Run Lecture 8’s nine questions — question 9, who reports it and has anyone reproduced it; question 8, is the task distribution yours — and the number does not vanish; it acquires its correct epistemic weight: evidence consistent with the camp’s own architecture decision, not independent confirmation of it.

Cursor is not alone. Windsurf — the other major AI-native IDE, under Cognition since the 2025 acquisition — sits in the same camp, shipping a full-codebase index feeding retrieval, as of mid-2026 per its docs. The position is a camp, not one vendor’s quirk.

7.2 The agentic camp

Claude Code ships no index. No embedding step, no vector database, no five-minute sync — context is retrieved on demand with grep, glob, and read, the same tools you watched run in Lecture 7’s loop. The model finds code the way an engineer new to a repository does: search for a string, open what looks relevant, follow the imports, search again. Where the index camp answers a query with one nearest-neighbour lookup, the agentic camp answers it with a short investigation.

This is a stated position, not one this lecture infers from an absence. Anthropic’s engineering guidance puts it in one sentence, published alongside the Agent SDK in September 2025: “Semantic search is usually faster than agentic search, but less accurate, more difficult to maintain, and less transparent” — and the same post’s advice is to start with agentic search. The creator’s testimony adds the part a position paper would omit: Boris Cherny has said publicly that early versions of Claude Code used RAG with a local vector database and dropped it — agentic search “generally works better… doesn’t have the same issues around security, privacy, staleness, and reliability.” Note the genre of that evidence: not a thought experiment but a team that built the index camp’s architecture, ran it, and walked away from it.

Nor is the walk-away unique to Anthropic. In February 2024 — before Claude Code existed — Sourcegraph moved Cody off embeddings as its retrieval backbone, citing third-party embedding exposure (your code shipped to someone else’s embedding API), the maintenance burden of keeping indexes current, and the operational cost of vector search at hundred-thousand-repository scale. Same conclusion, independent organisation, two years earlier.

There is also a supporting datum from outside the vendor fight, with a caveat that must stay permanently attached: an AAAI 2026 paper from Amazon measured a ReAct-style agent equipped with keyword-search tools alone at over 90% of vector-RAG performance — on document question-answering, not code. The caveat travels with the number, here and anywhere you ever quote it.

7.3 Convergence and decision rules

By mid-2026 the camps lean visibly toward each other. Cursor’s agent now picks per query between grep and semantic search — the index camp conceding that exact match has irreplaceable uses — while Anthropic’s own sentence above already concedes the opposite direction in its first clause: semantic search is “usually faster”, a speed optimisation worth adding when the corpus and the latency budget demand it. The argument is not collapsing into a winner. It is collapsing into a decision — one you make per corpus and per query, and one this course can now state as rules:

Search for what you can name; embed what you can only describe; and if you build a production retrieval pipeline, go hybrid with reranking from day one. That single sentence is the operational residue of the whole fight, and it will reappear in your own hands shortly: field four of the strategy template in chapter 12 asks you to write down — for your own Locust instance — what you would grep first and what, if anything, would justify an index.

And then the meta-rule, which matters more than the rules. Which camp wins is an evaluation question, and the published evidence on both sides is mostly vendor evals — the nine questions apply to architecture marketing exactly as they apply to leaderboards. Cursor’s 12.5% lives on Cursor’s benchmark; Anthropic’s “less accurate” is a stated judgement with no benchmark attached at all; Amazon’s 90% was measured on the wrong task; Sourcegraph’s reasons were operational, not a controlled accuracy comparison. None of that makes either camp wrong. It makes the question open — and Lecture 8 taught you precisely how to hold an open question without buying anyone’s poster.

Whichever camp you join — index, agentic, or the converged middle that mid-2026 is drifting toward — notice what none of them changes: what generation is. Retrieval decides what the model is conditioned on; the conditioning then feeds the same next-token machinery it always fed. What that does and does not buy you — in published, occasionally uncomfortable numbers — is chapter 8.

8. What Retrieval Does Not Fix

Chapter 7 ended, deliberately, without a winner: decision rules instead of a verdict, because the index camp and the agentic camp are each right about different workloads. But step back from the dispute and notice what it was actually about — how to choose the tokens. Nothing in it touched what happens after the choice is made. However the context is found — by an embedding index re-synced behind your back or by an agent grepping its way through the tree — it ends the same way: as tokens in a window, handed to the same forward pass, sampled by the same machinery you have carried since Act 2. Whichever camp wins, neither changes what generation is.

That observation calls in a debt this lecture has been accumulating for two chapters. Chapter 6 built the pipeline and chapter 7 staged the architecture fight, and both talked — as the industry talks — about how retrieval helps. A discipline that wants to be taken seriously must also say, in public and with numbers, what its favourite move does not fix; a treatment of retrieval that skips this section is a sales deck. So this is the honesty chapter, and it runs in four steps: the mechanism that survives any pipeline (§8.1), the flagship number that punctures the strongest marketing sentence in the field — run through Lecture 8’s discipline as a worked example (§8.2), the two structural limits that no amount of vendor engineering abolishes (§8.3), and the loudest debate in retrieval, resolved as a question of economics rather than ideology (§8.4).

8.1 A grounded distribution is still a distribution

The mechanism argument fits in one paragraph, because every piece of it is already yours. Lecture 6 established that hallucination is not a bug but the expected behaviour of next-token prediction when the context is insufficient to peak the distribution onto a correct answer — a flat distribution sampled confidently. Retrieval attacks exactly that insufficiency, and nothing else: pull the right chunk into the window and the conditional distribution sharpens toward the documented answer, which is why retrieval genuinely reduces hallucination and why the entire industry of chapter 6 exists. But generation after retrieval is the same generation as before retrieval — a forward pass producing a probability distribution, a sampler drawing from it, token by token. A grounded distribution is still a distribution: good context shifts probability mass toward the truth, and it cannot pin it there.

The word that hides this from buyers is grounded, because it borrows the grammar of human reading. When you ground an argument in a source, you consult the source — look up the passage, check the claim against it, cite it. The model does none of that. It is conditioned on the retrieved text: the chunk’s tokens reshape the probability landscape over the next token, alongside — and sometimes in losing competition with — everything the model’s weights already believe. Conditioning is a statistical relationship, not a citation; there is no step in the forward pass where the model verifies its own sentence against the document sitting in its window.

Take a moment to see what that single sentence predicts, because §8.2 is about to test the prediction. If retrieval merely reshapes the distribution, then a retrieval-augmented system can still answer from its priors and ignore an inconvenient chunk; it can quote a real document and draw a conclusion the document does not support; it can paraphrase faithfully retrieved text into something subtly false. Every one of these is generation working exactly as designed on top of retrieval working exactly as designed. The mechanism therefore predicts a hallucination rate that is lower than the ungrounded baseline and above zero — for any RAG system, built by anyone, at any budget. The only open question is the number.

8.2 Hallucination, with a bibliography

Here is the marketing sentence, and it is not a strawman — it has been the load-bearing promise of an entire product category. Commercial legal-research tools — retrieval systems over databases of case law and statutes, sold to professionals for whom a fabricated citation is a sanctionable offence — have been marketed as “hallucination-free”, on precisely the argument §8.1 just dismantled: retrieval grounds every answer in a real document, therefore the answers are reliable. One housekeeping note before we rate it: the Claim Board takes no new cargo today — the ledger carries over from Lecture 9 unchanged — so this sentence gets the worked-example treatment — Lecture 8’s instrument applied, verdict issued — with nothing pinned to the wall.

The evidence is unusually good, which is what earns this subsection its title. Stanford researchers ran a preregistered study of exactly those commercial tools — Magesh et al., Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools, published in the Journal of Empirical Legal Studies in 2025 — and measured hallucination rates of 17–33%, depending on the tool. Notice that the question mark in the paper’s title is doing the work the marketing copy refused to do. And read both halves of the result with equal care, because the study is not a hit piece: the tools hallucinated less than general-purpose chatbots on the same tasks — retrieval helps, measurably, just as §8.1 predicts — and the rates are nowhere near zero, just as §8.1 also predicts. One answer in six to one answer in three, from systems sold on the word “free”.

Why a legal study, in a course about software? Because it is the cleanest preregistered measurement anywhere of the exact promise the developer-tool market makes to you in different words. “Grounded in your codebase”, “answers from your documentation”, “cites its sources” — the pitch pattern is identical: retrieval touches real documents, therefore trust the output. Law just happens to be the domain where someone with no product to sell measured the gap between touches real documents and is correct, under a protocol fixed in advance. The number is domain-specific; the lesson — that grounding reduces and does not eliminate — is the mechanism’s, and the mechanism ships in every RAG system you will ever buy or build.

Now walk the sentence through the relevant rings of Lecture 8’s checklist — abbreviated, because three of the nine questions decide this one:

The third row deserves a sentence of prose, because it is the quietly impressive one. Judging whether a legal answer is hallucinated is itself expert judgement — the grader problem Lecture 8 taught you to interrogate — and a grader with discretion after the fact is a grader that can flatter. Preregistration removes the discretion: the definitions and the protocol were committed before the results existed, which is the same discipline Lecture 9 demanded of the word “solved” in your own evals — define it before the run, not after you have seen which definition flatters which tool.

Verdict, per the rubric: refuted-as-stated. And in Lecture 8’s register, be precise about what that does and does not say. It is a statement about the sentence, not about the tools: the tools are measurably better than ungrounded chatbots, retrieval reduces hallucination demonstrably, and a lawyer using one is better served than a lawyer pasting questions into a general-purpose chat window. What is refuted is the word free. “Reduces” was available, true, and provable; “eliminates” was chosen instead — and the slogan is, as Lecture 8 said of another, advertising wearing the grammar of a measurement.

One last observation, because it sharpens your feel for the rubric. When Lecture 8 refuted “the best coding model in the world”, the verdict was about the sentence’s grammar: the slogan named no measurable quantity, so it could be refuted only as stated — there was nothing to take into a lab. “Hallucination-free” is different: it asserts a number, and the number is zero. A zero is the most falsifiable claim in science — one counterexample ends it, and Magesh et al. supply counterexamples at industrial scale. Same verdict, two different defeats: one slogan fell to its own grammar; this one was honest enough to be falsifiable, and was falsified.

And finish the exercise the way Lecture 8 trained you to — by naming the disclosure that would have saved the sentence, because that is what separates criticism from cynicism. An honest version exists and was always available: our tool hallucinates on roughly one query in six under this published protocol — measurably less often than an ungrounded chatbot on the same tasks. That sentence is verifiable, it is genuinely impressive, and a professional audience would reward it. The vendors did not write it. When you ship a retrieval system — and some of you will, within a year — the rate-with-protocol sentence is the one you owe your users.

8.3 The retrieval ceiling and the stale index

§8.2 measured the failure that survives successful retrieval. The second honest admission is that retrieval itself fails — structurally, in two ways that matter directly for code.

The first is the retrieval ceiling. CodeRAG-Bench (NAACL 2025 Findings) benchmarked retrieval for coding tasks and found that retrievers often fail to surface the documents that would actually help — and that the failure is worst at repository level, which is precisely where your work lives: the relevant context for a bug fix is rarely a self-contained paragraph, it is a call site here, a config default there, a test that encodes the intended behaviour somewhere else. Similarity search has no concept of this depends on that; it has a concept of this sounds like that, and the two part company exactly when a codebase gets interesting.

The consequence is asymmetric and unforgiving: no generator recovers what retrieval never fetched. The model downstream can be arbitrarily strong, the prompt arbitrarily well engineered — if the chunk that mattered never entered the window, the system is answering a different, smaller question than the one you asked. Chapter 6’s pipeline is best read in this light: every stage — hybrid lexical search, contextualised chunks, reranking — exists to lower a measured miss rate, and even the full stack leaves a residual floor. Engineering shrinks the ceiling’s shadow; nothing yet removes it.

The second is staleness. An index is a snapshot of a moving codebase: between one sync and the next, the function you are asking about may have been renamed, refactored, or deleted, and the index will confidently retrieve the world as it was. This is not a hypothetical — it is the failure Claude Code’s creator cited when explaining why early versions abandoned their local vector database (chapter 7), and the index camp does not deny it so much as manage it: Cursor’s roughly five-minute incremental re-sync (as of mid-2026) is exactly that — engineering, not magic, a window of wrongness narrowed to minutes and never closed. The agentic camp pays for freshness differently, with tokens and latency at query time. Either way the limit is real and managed, never abolished; the honest engineering question is only how much wrongness your task tolerates, and for how long.

Put the two limits next to §8.1 and you can see the full failure surface of a retrieval system: selection can miss (the ceiling, the stale snapshot), and generation can err even on a perfect hit (the distribution). The layers multiply rather than excuse each other. Worse, a selection failure rarely announces itself — a missed retrieval throws no exception; it produces a fluent answer grounded in nothing in particular, indistinguishable at a glance from a grounded one. That is why mature teams evaluate retrieval and generation separately — measure whether the right chunks arrived before debating what the model did with them — a directly actionable echo of Lecture 8: instrument the stage, not just the outcome.

8.4 Long context versus RAG: economics, not ideology

Every context-window announcement of the past few years has revived the same headline: long context kills RAG — why build chunking pipelines and fight stale indexes when you can inline the whole corpus and let attention do the selecting? The debate is usually conducted as ideology — pipeline people versus window people — and it dissolves on contact with measurement. Google DeepMind ran the comparison directly: the Self-Route study (Li et al., EMNLP 2024) found that long context beats RAG on quality when you can afford the tokens; that RAG is dramatically cheaper; and that a simple router — ask the model whether the retrieved chunks suffice to answer, escalate to the full window only when they do not — captures most of the long-context quality at a fraction of the cost. Neither architecture won. A price-aware combination of both did.

And you, specifically, can price the two sides, which is the point of having sat through Lecture 9. Inlining a corpus into an agentic session grows the fixed prefix — the term that the worked example’s $9.90 taught you is re-billed on every one of \(N\) turns — while retrieval spends engineering effort so that each call carries only what it needs. Which expense is justified is not a matter of taste; it is cost-per-solved-task — total spend over tasks actually solved — computed on your workload, with the quality difference sitting in the denominator where it belongs.

The quality side is not a clean win for the big window either, and this lecture already showed you why: chapter 3 put the bibliography behind the claim that models degrade on long contexts even when the information is verifiably present. So the honest ledger of the debate reads, in full:

Read the table as a whole and the debate’s headline dissolves. Neither long context nor retrieval simply wins — and that is precisely why context engineering exists as a discipline rather than a default setting. If stuffing the window were free and lossless, selection would be pointless; if retrieval were solved, curation would be obsolete. Every option on the table works, fails, and costs — and the job this lecture is training you for is choosing among managed failures on purpose, per system, with numbers.

That closes Block A, and it closes on a deliberately unheroic summary. The block’s question was the lecture’s subtitle — what earns a place in the window — and you now hold every selection mechanism the industry uses: curated instruction files, similarity search, agentic exploration, and the honest accounting of where each one breaks. Selection is solved by no one; it is engineered by everyone. But selection only governs one boundary of the window. Block B opens at the other: the shape of what comes out. The moment a model’s output feeds a parser, a pipeline, or a tool rather than a human reader, its format becomes a contract — and Lecture 6 left you a promise about exactly that contract, named but never demonstrated. Cashing it is chapter 9.

9. Structured Outputs in Production

Block B opens here, and it opens on the sentence that closed Block A. Chapter 8 ended with selection solved by no one: retrieval misses, indexes go stale, grounded generation still hallucinates at measured rates — every mechanism Block A toured decides what enters the window, and every one of them is better-not-reliable. This half of the lecture turns the pipe around. Whatever you selected in, the model will generate something out, and in agentic work that output rarely goes to a human first — it goes to a parser, a validator, a test runner, the next iteration of the loop. So before this lecture can teach you to compress, isolate, and strategise, it has to answer the outbound question: in what shape does the output arrive, and what is the rest of your system allowed to assume about it?

9.1 The mechanism you already have

The first thing to be clear about is that this chapter contains no new mechanism, because you already own it completely. Constrained decoding was taught, mechanistically and in full, in Lecture 6 §15.1: the output grammar masks the sampling distribution so the model never has the option of emitting a token that would violate the schema. How the grammar is compiled, what gets masked, where the idea comes from — all of that lives in Lecture 6 and is deliberately not repeated here; if any of it is fuzzy, re-read §15.1 before going on, because the rest of this chapter stands on it. What Lecture 6 left behind was not a mechanism but an instruction:

Operational rule. If the output has a grammar, use constrained decoding plus a parser-plus-retry wrapper. Use prompting to explain the task. Use decoding and validation to enforce the shape. This is the difference between hoping the model produces JSON and making it produce JSON.

Today is the production half of that rule. Lecture 6 told you to use the wrapper and then stopped, on purpose: it showed you no wrapper, and beyond OpenAI’s documentation and the open-source engines it named no vendor — in May, the industrial landscape was out of scope. Today the scope arrives, in four steps: what the industry built so that the rule is followable (§9.2), the two places where the resulting guarantee is documented to break (§9.3), the wrapper itself, demonstrated at last (§9.4), and the one sentence that keeps the whole apparatus honest (§9.5).

9.2 The vendor landscape, as of June 2026

Three first-party offerings dominate, and their differences are exactly the kind of perishable detail this course stamps. Every entry in the table below comes from the vendor’s own documentation, current as of June 2026, and will drift on the usual clock. What does not drift is the pattern every row instantiates — a JSON schema goes in with the request, grammar-constrained decoding comes out — which is Lecture 6’s one mechanism wearing three different API surfaces. Learn the pattern; look up the parameters — Lecture 9’s pricing-table rule, transplanted.

The OpenAI row carries the distinction every team integrating against that API must know, because the two features sound interchangeable and are not: JSON mode promises only that the output parses; Structured Outputs promises that it parses into your schema. When Structured Outputs launched in August 2024, OpenAI’s own evaluation reported 100% schema-following for the launch model against under 40% for its prompted predecessor — a vendor eval of the vendor’s own feature, so read it with Lecture 8’s nine questions at hand; but the direction of the gap is exactly what Lecture 6’s mechanism predicts, since prompted formatting is influence and constrained decoding is not.

The Anthropic row’s loudest detail is the 400. Per the structured-outputs documentation (as of mid-2026), a schema that uses an unsupported feature fails the request outright instead of being quietly approximated — and a request rejected at submission time is a far better failure than a response that arrives looking guaranteed and is not. The rows also disagree about recursion: a self-referential schema — an expression tree, a nested comment thread — works via $ref on OpenAI and, since the November 2025 upgrade, on Gemini, but not on Anthropic’s implementation as of mid-2026. None of this ranks the vendors; it tells you that “supports structured outputs” is underdefined until you have read the limits column for the schema you actually need.

The Anthropic row also poses a choice the other rows hide inside one feature: JSON outputs or strict tool use? The decision rule is about who consumes the result. When the structured object is the deliverable — a report row, an extraction, a record for a database — use the JSON output format: the response body is the artifact. When the structured object is an instruction for the orchestration layer to act on — call this function, with these arguments — use strict tool use: the schema guards the arguments before any code runs on them. Same mechanism underneath, different position in the loop; and the distinction transfers to every vendor, whatever the parameter names, because it is a statement about your architecture, not about an API.

One paragraph for everything the table leaves out, because the capability is not a frontier-vendor moat. The Outlines lineage Lecture 6 named has been industrialised: XGrammar is the constrained-decoding backend in vLLM and SGLang, llama.cpp enforces GBNF grammars and converts JSON schemas into them, and the lineage keeps moving — an XGrammar-2 release in May 2026 extended the approach to tool-calling formats, as of mid-2026. If your works council ever routes you to the open-weights world of Lecture 9, chapter 4, the schema guarantee comes with you: local models enforce shapes too.

9.3 Where the guarantee breaks

Every guarantee in that table has documented exceptions, and — remarkably, for an industry that agrees on little — the vendors agree on what they are. Two escape hatches, industry-wide: safety refusals and token-limit truncation. In both cases the API returns text that may not match your schema, and in both cases this is documented behaviour, not a bug.

Anthropic’s documentation names exactly these two. A refusal arrives as a stop reason — stop_reason: "refusal" — on an HTTP 200: the request succeeded, the tokens are billed, and there is no schema-conforming payload in the response. And a generation that hits the max_tokens ceiling stops mid-structure, which matters because a prefix of valid JSON is not valid JSON — the truncated output fails to parse at the first missing brace. OpenAI’s documentation names the same failure classes in its own vocabulary: a dedicated refusal field, a finish_reason of "length", and content-filter interruptions. Different field names, identical engineering reality.

The rule that falls out is short enough to be the chapter’s first thesis: check the stop reason before you parse. A guarantee with documented exceptions is not a broken promise; it is an engineering material, like steel with a rated yield strength — you do not discard it for having limits, you build for the limits. The check costs one if statement, and the wrapper in the next section has it built in.

9.4 Parse, validate, retry

Here, at last, is the wrapper — the thing Lecture 6’s operational rule prescribed and never showed. The client below is schematic; the pattern is not, and it transfers to any of §9.2’s rows:

from typing import Literal
from pydantic import BaseModel, ValidationError

class Triage(BaseModel):
    severity: Literal["low", "medium", "high"]
    component: str
    needs_human: bool

def triage(issue_text: str, max_retries: int = 2) -> Triage:
    messages = [{"role": "user", "content": TRIAGE_PROMPT + issue_text}]
    for _ in range(1 + max_retries):
        resp = client.generate(
            messages=messages,
            output_schema=Triage.model_json_schema(),  # shape: enforced by the API
        )
        if resp.stop_reason != "end_turn":             # refusal / max_tokens:
            raise OutputUnavailable(resp.stop_reason)  # the guarantee is void (section 9.3)
        try:
            return Triage.model_validate_json(resp.text)
        except ValidationError as err:                 # content rules the schema can't express
            messages += [
                {"role": "assistant", "content": resp.text},
                {"role": "user", "content": f"Validation failed:\n{err}\nReturn corrected JSON only."},
            ]
    raise OutputUnavailable("still invalid after bounded retries")

Four moves, each earning its line. The schema travels with the request, so shape is enforced at sampling time — that is §9.2’s product doing its work. The stop-reason gate runs before any parsing — §9.3’s rule as code. The application-side validation then checks the response again, cheaply, and — more importantly — checks everything your schema language could not express: value ranges the vendor’s subset rejects, cross-field consistency, an enum that depends on another field. And when validation fails, the validator’s error message goes back to the model as the next turn for a bounded retry — models are markedly better at correcting against a named error than at guessing what displeased you, and the bound keeps the loop from buying correction attempts on Lecture 9’s quadratic forever. The pattern has a canonical embodiment: the instructor library, which takes a Pydantic model as its response_model and feeds validation errors back automatically with bounded retries — its adoption figures are self-reported, but the pattern matters more than the package, and now you can write the loop yourself in twenty lines.

Place the wrapper on the course’s map before moving on, because it sits at a seam. Lecture 7’s completed three-layer model said that a better influence layer narrows the distribution and “only the enforcement layer truncates it” — and constrained decoding is precisely that truncation, relocated to sampling time: the enforcement layer operating at the shape boundary. But everything inside the shape — the severity the model chose, the component it named, the boolean it set — is still sampled from the influence layer’s distribution, conditioned on whatever Block A selected into the window. That is why the wrapper validates more than syntax, and why this chapter cannot end here.

9.5 Schema-valid is not correct

Google’s own documentation says it outright: structured output “does not guarantee the values are semantically correct.” Take the sentence seriously, because vendors do not volunteer limits of their own features for fun. Lecture 6 said the same thing in its own words — “The shape is enforced; the truth is not” — and the production landscape of §9.2 changes nothing about it. A schema-valid wrong answer arrives faster and looks more trustworthy than a malformed one — validation of shape is never verification of truth. You have met this asymmetry before, as Lecture 8’s grader question: a score is only as strong as whatever graded it, and a schema is the weakest grader you have ever held — it checks form, perfectly, and content not at all. {"severity": "low"} validates beautifully while the building burns.

There is also a live quality debate worth carrying with its stakes attached. Tam et al. (EMNLP 2024 Industry) reported that format restrictions degraded reasoning performance on their benchmarks — “Let Me Speak Freely?” is the paper’s own framing. The structured-generation company dottxt published a point-by-point rebuttal showing the effect largely vanishes with matched prompts and true constrained generation (on GSM8K, 0.78 constrained against 0.77 unconstrained). Note who is speaking: dottxt sells structured generation; the original authors had a paper to defend. The honest takeaway is the disagreement itself, not a verdict — and the engineering posture follows Lecture 8’s habit: if reasoning quality under constraints matters for your task, measure it on your task, rather than inheriting either side’s conclusion.

Now the turn that makes all of this daily rather than exotic. Every tool call you have watched this semester — every tool_call(Read, ...) in Lecture 7’s loop — is schema-bound output: the model emits a call that matches the tool’s declared input schema, and the orchestration layer parses it on arrival. You have been consuming structured outputs since week one without naming them; the lab (chapter 13) makes you a producer, when you write the JSON schema for your own Locust row and name the two stop reasons that would void its guarantee.

So the outbound side of the window now has a contract: shape enforced, exceptions documented, content still yours to verify. The inbound side has no such bargain — the window keeps filling, every token it carries is carried again on every subsequent call, and so far this lecture has only taught you to choose tokens, not to shed them. Spending less without knowing less — compaction, and its sharper sibling, isolation — is chapter 10.

10. Compression and Isolation

Chapter 9 settled the question of shape: what you select into the window can arrive under a contract the rest of your system can parse. This chapter settles a question that has been standing open — with a promissory note attached — since the day you first priced a session. When Lecture 9 §9.4 named summarisation as the lever that caps the quadratic’s accumulation term, it paused to be honest about what the lever costs: “Compressing history is a judgment call about what the rest of the session will need — engineering, not bookkeeping — and getting it wrong buys you a cheaper session that fails. The cost side of that trade you can now compute; the quality side is a later lecture’s craft.”

This is that later lecture. Two of chapter 4’s moves remain unworked — compress and isolate — and they are the pair that acts on the conversation itself rather than on what you feed it. §10.1 takes the quality side of the trade seriously; §10.2 works compression in the concrete tool, including the one table in this chapter worth photographing; §10.3 works isolation, which turns out to be compression’s smarter sibling: instead of deciding what to throw away, you arrange never to have carried it.

10.1 The quality side of the trade

Lecture 9 priced compression from the cost side: a summary carries fewer tokens, fewer tokens shrink \(d\), and a smaller \(d\) deflates the term that grows with the square of the session. But it also conceded the quality side in one passing sentence — “A summary carries fewer tokens because it carries less information” — and that concession, made in passing there, is the whole subject here. Promote it to the chapter’s first thesis: a summary carries fewer tokens because it carries less information — the saving and the loss are the same event, and the craft is choosing which information the rest of the session can live without. There is no compression move that only removes tokens; every one of them removes answers to questions the session has not asked yet. Lecture 9’s own example still says it best: the model can re-read a full test log and notice the warning three lines above the failure; it cannot ask a summary a follow-up question.

So the craft question is which information the rest of the session will need — and notice who answers it. Not you, and not a rule: compression in every serious tool is performed by another model call, which means it is a judgement call executed by a machine. The summariser reads the history, decides what mattered, and writes a digest; the session then continues on that digest as if it were the past. Lecture 9 called the call engineering, not bookkeeping; what it left for today is the observation that, by default, the engineer making it is not you.

Lecture 7 §10.3 planted this flag three weeks ago, in a phrase worth re-quoting: the digest is “a judgement call performed by another model call, compression with opinions”. It can omit the one detail that mattered, flatten the reasoning behind a decision into the decision alone, or assert something nobody said — everything Lecture 6 taught you about generated text applies, without exception, to the machine-written summary of your own session. In Lecture 7 that was a warning about one eviction strategy among three. Today it is the operating principle of a command you will run weekly.

And notice how this particular failure presents, because it is quieter than anything in chapter 9. A schema violation throws; a bad summary does not. The session continues, fluent and confident, on a past that no longer contains the constraint from turn six — and the first symptom you observe is a wrong decision twenty turns later, with the evidence of why it is wrong already summarised away. Lecture 9’s “cheaper session that fails” fails silently, which is exactly why the trade deserves a chapter rather than a footnote.

What makes the trade engineerable rather than merely dangerous is that you hold two handles on it. You can steer the judgement call — tell the summariser what the rest of the session will need, instead of letting it guess. And you can arrange for the material you cannot afford to lose to be immune to summarisation entirely, by putting it where the summariser never reaches. The first handle is a command-line argument; the second is a filesystem. Both are §10.2.

10.2 Compaction and what survives it

In Claude Code — the course’s one concrete orchestration layer; every other agentic tool has a sibling mechanism — the compression move is called compaction, and as of mid-2026 it works like this. /compact replaces the conversation so far with a model-written summary, and it accepts optional focus instructions: /compact focus on the failing test and what we changed so far is you, the human, answering §10.1’s craft question explicitly instead of delegating it. If you never run the command yourself, the tool eventually does: auto-compaction fires at roughly 95% of window capacity, and older tool outputs are cleared first — a sensible default, since Lecture 9 §9.2 showed you that \(d\) is dominated by tool results, and a stale test log from forty turns ago is usually the lowest-value tenant in the window.

The interesting question is not what compaction removes but what it preserves — and as of mid-2026 the documentation publishes the answer, which means you can plan around it. Read the following table as a budget map of the far side of /compact:

Now read the middle column top to bottom and notice what every “re-injected” row has in common. What survives compaction is what lives on disk. Lecture 7 §10.3 gave you the principle as a habit — “The disk is the durable record; the window is scratch space.” — and what was a habit three weeks ago is now an operating rule executed by the machine: the orchestration layer itself treats files as the things worth keeping and conversation as the thing worth paraphrasing. The engineering corollary writes itself: anything you cannot afford to lose to a summary — the decision you reached in turn twelve, the constraint the issue imposes, the list of files you ruled out — belongs in a file before compaction, not in your hopes for the summariser’s judgement after it.

The table’s “lost” row deserves one extra beat, because it is the surprise. If your testing conventions live in a nested tests/CLAUDE.md — exactly where Lecture 7’s rule two told you to put them — then after compaction they are gone, and they stay gone until the next tool call touches that directory and the loading rule fires again. The mechanism that saved you tokens at session start costs you continuity at compaction time. Neither behaviour is a bug; both are the same rule, and now you know to expect it.

One distinction closes the section, one sentence each. /clear is for a new task: it discards the window entirely and starts from disk, with the previous conversation parked under /resume rather than destroyed. /compact is for the same task: it buys the current job more runway, at the price — now familiar — of continuing the session on a paraphrase of itself.

10.3 Isolation: subagents and the file system

Compression decides what to keep after the conversation has grown. Isolation, the fourth and final move, makes a better offer: arrange the work so that the expensive part of the conversation never grows in the first place — not in your window, anyway.

The mechanism, as of mid-2026: a subagent is a worker defined by a file on disk — a Markdown file under .claude/agents/, where only a name and a description are required — that runs in its own context window. The parent session does not see the subagent’s conversation, its file reads, or its tool results; it sees exactly one thing, the subagent’s final summary (plus a small metadata trailer), appended to the parent’s array like any other tool result. Subagents cannot spawn subagents of their own, which keeps the topology flat: one parent window, several disposable side-windows.

You do not even have to define one to benefit. As of mid-2026 the tool ships built-ins — among them a read-only exploration agent that runs on a smaller, cheaper model, a planning agent, and a general-purpose worker — and the read-only one is the move in miniature: codebase reconnaissance is exactly the work whose findings you want and whose transcript you do not, so the default architecture hands it a disposable window and a model priced for throwaway reading. Where Lecture 9 taught routing as a cost decision between tasks, isolation applies it within one task: the expensive window does the deciding, the cheap window does the wandering.

Read that design against Lecture 9’s formula and you see what it is for. The sprawling search across thirty files, the 10,000-line test log, the exploration that takes twenty tool calls to conclude “the bug is not in the parser” — all of it happens in a window you intend to throw away, and the parent pays for the conclusion, not the journey. \(d\) in the main session stays small by construction, which keeps the quadratic term shallow by construction. This is the quadratic engineered, not endured.

Notice the symmetry with §10.2, because it is the cleanest way to remember both. Compaction is compression after the fact: the history exists, and a machine judges what to keep. A subagent is compression by design: you place the summary boundary before the exploration happens, and the subagent’s brief — the description you wrote on disk — decides what is allowed to cross back. The same trade as §10.1, with one decisive difference: the judgement call about what the rest of the session will need is made while you can still write it down.

Beyond the tool’s own mechanisms there is a layer of production folklore worth naming, and it comes with attribution: the team behind the agent product Manus, whose write-up “Context Engineering for AI Agents: Lessons from Building Manus” (July 2025) sits in chapter 13’s optional reading, reports having rebuilt its agent framework four times — and calls the KV-cache hit rate “the single most important metric” of a production agent, which is Lecture 9’s cache discipline restated as a survival condition. Two of their habits belong in this chapter.

The first is the file system as context: write intermediate state — the long observation, the scraped page, the full log — to a file, keep the path and a one-line gloss in the window, and re-read the file on demand. The window carries a pointer and a conclusion; the disk carries the bytes. You will recognise it as §10.2’s survival rule run in the opposite direction: instead of asking what compaction will preserve, you store the material on disk yourself, pre-emptively, and let the window stay light. Compression that loses nothing, because the “lost” information remains one tool call away.

The second is recitation: the agent maintains a todo file and keeps re-writing it as work proceeds, so that the goal and the remaining steps re-enter the conversation at its end — the recency-advantaged region that Lecture 6’s positional story mapped, and that long sessions otherwise push the original task statement out of. Nothing about the mechanism is exotic; it is lost-in-the-middle, used deliberately, from the inside. An agent that recites its plan is doing position engineering on itself.

That completes the taxonomy: four moves, each now attached to machinery you can run this afternoon — files and rules for write, loaders, retrieval, and skills for select, compaction for compress, subagents and the file system for isolate. What you do not yet have is instruments: something that shows you, mid-session, what the window actually contains and whether the moves are doing what you think they are. That panel is chapter 11.

11. The Instrument Panel

Chapter 10 completed the four moves, and with it the lecture’s machinery: everything from chapter 4 onwards has told you what to do to a context window. None of it has shown you the window. Lecture 9 made the point about money — an estimate you never check against a measurement is folklore — and it holds token for token here: a context strategy you never inspect mid-flight is a hope, not a strategy. This chapter is the instrument panel: one command that shows you the budget live, and a brisk tour of the toolbox read as instruments — every item a Lecture 7 mechanism grown up, every detail stamped “as of mid-2026” for reasons §11.3 makes explicit.

11.1 Watching the budget live

The main instrument is /context. It renders the current occupancy of the window as a coloured grid — block by block: system prompt, tool definitions, instruction files, memory, skills, MCP schemas, and then the accumulated conversation — with optimisation suggestions attached, simulated against a 200,000-token window as of mid-2026. You met it a week ago, and Lecture 9 §12.1 already told you exactly what you are looking at: the top of the grid is the fixed prefix \(P\), the bottom is the per-turn growth \(d\) in mid-accumulation — the quadratic chapter’s “formula rendered live”. And it said what staring at it teaches: “Watching /context during a long agentic session is watching the quadratic happen: the fixed block never shrinks, the history only grows, and every turn re-submits both.”

What changes between that lecture and this one is your relationship to the grid. Last week you watched it the way you watch a taximeter — a bill forming, legible but inevitable. Today every block in the grid is the output of a decision, and most of the decisions are yours: each coloured region maps onto one of the four moves, applied or neglected. A bloated instruction block is a write move done badly; a fat MCP segment is a select move not yet made; a conversation block at 60% is chapter 10 waiting to happen. The grid is the same; the reader has changed.

It is also the lab’s main instrument (chapter 13). The window audit asks you to run /context on a real session and put the title of this lecture to every tenant: what, exactly, earned this block its place in the window — and against which rule of your context budget policy?

11.2 The toolbox, move by move

Now the panel itself, move by move. This chapter is a panel, not a manual: each instrument gets the one paragraph it needs, the mechanics are Claude Code’s as of mid-2026, and every concept transfers — other orchestration layers ship the same moves under different names. The pattern to watch for, four times over: nothing below is new machinery; it is Lecture 7’s machinery with loading rules sharpened into budget controls. First the panel at a glance, then the paragraphs that earn each row:

For write, the instruction-file family has grown a scope axis. Rules files — Markdown under .claude/rules/ — load at launch like CLAUDE.md, unless they declare a paths: glob in their frontmatter, in which case they load only when a matching file is read: Lecture 7 ch4’s rule two, generalised from “this directory” to “any file matching this pattern”. Auto memory — the read-write loop Lecture 7 ch5 dissected — is now on by default, with a documented per-session load cap (the first 200 lines or 25 KB of the index file): the loop you learned as a mechanism has been productised with a budget attached. And @-imports — one file pulling in another, up to four hops deep — expand at launch: they organise content; they do not save a single token. Knowing which of your write-side files are budget-capped, lazily loaded, or merely reorganised is the difference between a prefix you designed and a prefix that happened to you.

For select, the on-demand economics of Lecture 7 ch7 now come with published numbers. Skill descriptions are always in context — truncated at 1,536 characters apiece in the listing — while skill bodies load only on invocation (and survive compaction only under chapter 10’s caps): you pay a permanent index and rent the contents. MCP has moved the same direction: tool schemas are deferred by default, names only until a tool is actually needed, and /mcp itemises what each server costs your window — which means the system-prompt tenant in Lecture 7 ch10’s budget table is simply smaller than it was when that table was drawn. The drift is uniform and worth saying once: between Lecture 7 and today, the defaults moved from always-loaded towards loaded-when-earned.

Compress and isolate you now own outright: /compact and its survival table, subagent definitions on disk and their disposable windows — chapter 10, both. On this panel they are one gauge each: how much of the window is conversation, and how much of the work is happening in windows that are not this one.

And one worker sits off the budget entirely. Hooks are lifecycle shell commands — scripts the orchestration layer runs at fixed points in the loop — and they run as code, not context: their execution costs the window nothing. That makes them the natural pre-filter at the tool boundary: the same 10,000-line log that chapter 10 sent into a disposable subagent window can instead be grepped down to its twelve ERROR lines before any model, parent or child, pays attention to a single token of it. Determinism for free, exactly where determinism works — Act 3’s division of labour in one mechanism.

What a hook prints can enter the context — deliberately, and bounded. For some lifecycle events plain stdout is fed straight back to the model, and hook output strings are capped at 10,000 characters as of mid-2026, with overflow diverted to a file. The shape is the right one to internalise: code does the reading, the model pays only for the verdict, and even the verdict has a budget.

11.3 Mechanics drift, moves do not

Two footnotes keep Lecture 9 true, because its instruments have already drifted in the weeks since it was written. First: /cost is now an alias of /usage — same habit, new name, and the habit is the part that matters. The dollar figure it reports is a local estimate aimed at API users; on a subscription you see plan-usage bars and a breakdown of what consumed the session instead of a bill — the two billing worlds Lecture 9, chapter 13 taught you to tell apart, metering the same token flows. ccusage, for its part, still does what Lecture 9 described — a community tool that rebuilds usage reports from the JSONL transcripts already sitting on your own disk — and has since grown beyond one CLI.

Second: the window itself. The default is 200K tokens; 1M-token variants exist on recent frontier models, plan-dependent, as of mid-2026 — and that sentence is hedged to exactly the precision it deserves, because the model list and the plan rules churn faster than a lecture can. You do not need the list. You need the reflex of checking it.

Which is the honest way to close a chapter like this one. Count what you have just read: a percentage threshold, two token caps, a character cap, a truncation length, a default window size, a command rename. Every one of them was verified against the documentation in June 2026, and every one of them is one documentation check away from being stale — next semester some will be. The four moves are not like that: they fall out of arithmetic and architecture — a stateless API, a quadratic bill, a finite attention budget — and those do not rename themselves in a point release. Mechanics drift; moves do not — and the one-minute documentation check before you rely on any mechanic is not an annoyance on top of the discipline, it is the discipline.

So the panel is lit: you can see the budget, and you can name the move behind every block in the grid. You also still hold the context budget policy you have been writing since Lecture 7 — the standing rules for what is always true of your project’s window. What neither the instruments nor the policy answer is the question each new task asks: what should this job get — which files, which instructions, which output contract, at what predicted cost? A standing policy plus a live panel wants a per-task plan, and writing one is chapter 12.

12. From Policy to Strategy

Chapter 11 closed on a deliberately double-edged note: the instruments are in your hands, and the panel they sit on has an expiry date — the mechanics will have drifted by the time you next need them, while the moves underneath stay put. This chapter is where the moves finally get a document of their own. Because an instrument panel is not a flight plan: everything the day has assembled — the four moves of chapter 4, the standard of chapter 5, the retrieval decisions of chapters 6 through 8, the output contracts of chapter 9, the compression craft of chapter 10 — tells you what can be done to a context window, and none of it commits you to what will be done to this one, tonight, on your own task.

The missing document is half a page long. This chapter defines its genre (§12.1), gives you its template (§12.2), and — before anything runs — fixes in writing how honestly its results may be read (§12.3), so that the lab can hand you the form and nothing else.

12.1 The standing policy and the disposable strategy

You already own one of the two documents this section contrasts. Lecture 7’s lab had you write a context budget policy — “a maximum CLAUDE.md size in tokens, a maximum conversation length before a fresh start, and which files are always-loaded versus on-demand” — and Lecture 9’s lab extended it to “four rules with numbers in them”: a token cap with the counter that checks it, a cache-discipline rule, a routing rule, an alert threshold. Look past the contents at the genre for a moment. The policy is standing infrastructure. It speaks in the permanent tense — maximums, defaults, thresholds. It says what is always true of your project’s context, and it does not know that tonight’s task exists.

A strategy is the other genre. It is task-level, written before the run, stapled to the result afterwards, and never reused — its useful life is exactly one attempt. It says what this task gets: which files are read deliberately, which instructions load, which retrieval approach runs, which output contract the run must satisfy, at what predicted cost. The policy says what is always true of your project’s context; the strategy says what this one task gets — and the strategy earns its keep precisely by being disposable. This is the documented strategy Act 3 has been steering you toward since Lecture 7 sketched what was coming: not another standing artifact to maintain, but a half page of deliberate decisions that travels with one run and turns “the agent did something and it cost something” into “I selected this context, predicted this bill, and here is what happened.”

Side by side, the two genres look like this:

The two documents need each other, and the dependency runs both ways. A policy with no strategies under it is never tested against a real task — it ossifies into the memo Lecture 9 warned about. A strategy with no policy over it has nothing to be checked against, and a checklist nothing checks degenerates fast. The relationship is building code and architect’s drawing: the code outlives every house and constrains all of them; the drawing is for one house, and a competent drawing cites the code clause by clause.

12.2 The strategy template

Here is the template — six fields, half a page. The lab (chapter 13) has you fill it in for your own Locust instance tonight, so read it as a form you are about to sign rather than a slide to nod at. No field is optional, and every field names the policy rule it satisfies.

1. Target. The issue you are pointing the agent at, and the test that defines “solved” — for tonight, your Locust instance’s fail-to-pass test from the Lecture 8 homework. A target without a test is a hope; you learned that about benchmarks before you learned it about your own work.

2. File shortlist. What gets read deliberately, with one line of why per file. The why-line is the field’s entire value: it forces each selection to be a decision instead of a reflex, and it is exactly what your red-team partner will attack in the lab.

3. Instruction budget. Which CLAUDE.md/AGENTS.md state the run starts from, and its token count against your policy’s cap — the policy’s first rule, checked before the run instead of regretted after. If the count is over the cap, the strategy says what gets cut; the run does not start until it does.

4. Retrieval approach. Agentic search is the default in your tool (chapter 7); the field records what you would grep first, and what — if anything — would justify an index for this repository. For most Locust-sized tasks the honest answer to the second half is “nothing”, and writing that down is the point: a decision against infrastructure is still a decision.

5. Cache layout. Stable prefix first, volatile content last — the policy’s cache-discipline rule, which Lecture 9’s caching chapter priced and your policy already encodes, applied to this run’s actual prefix. One time-stamped line above the fold and the field is failed.

6. Output contract and predicted cost. The row schema the run must produce (chapter 9), and the estimate by Lecture 9’s pre-task recipe: count \(P\) with a real counter, estimate \(d\) from your own logs, pick \(N\) pessimistically, apply the formula, and price the result in euros or window-share — before you touch anything.

Notice that not one field requires machinery this course has not already handed you: the template is an assembly, not an invention. Its discipline lives in the cross-references. Lecture 9’s lab ruled that “a policy without numbers is a wish”, and the same grammar extends one level down: a strategy that ignores its own policy is a wish. The why-lines, the counted budget, the named rules are what make the half page falsifiable — and falsifiable is the only property tonight’s comparison will need it to have.

12.3 Honest comparison

Because here is what the lab does with that half page: runs it, once, against your own Locust instance, and sets the resulting row next to the row you recorded for Lecture 9’s homework — the unengineered attempt against the engineered one. That comparison is the act’s first real before/after, and precisely because it will feel like a verdict, its epistemic weight has to be fixed in writing before anything runs — honesty is cheapest in advance.

Lecture 8 §5.4 did the arithmetic once and for all: “Two models reported five points apart on such a benchmark can be statistically indistinguishable: the gap is barely half a standard error of the difference.” That sentence was about sixty-task benchmarks. Your comparison tonight is one run against one run on one instance — a fortiori, whatever the five-points-apart argument forbids, \(n=1\) against \(n=1\) forbids harder. If the engineered run comes in cheaper, you may not conclude that context engineering works; if it comes in dearer, you may not conclude that it does not. Sampling noise alone — the wandering \(N\), the lucky first hypothesis — can produce either outcome unaided.

So the deliverable requires, not suggests, one sentence stating what your comparison can and cannot support. What it can support: calibration — did field six’s estimate land within its factor, and which term missed — and craft: which move you executed, and which term of the bill it visibly touched. What it cannot support: significance. Any sentence of the form “the engineered context is better” needs more runs than you will have. And the lab rule inherited from Lecture 7 holds with its original wording: “A null result is a finding.” An engineered run that costs the same, or fails where the naive one succeeded, is information about your strategy — a file the shortlist cut that the task needed, a summary that carried less than the session required — and information is the deliverable.

The gap between your two rows is a design review, not a verdict. Read it the way you would read a colleague’s review of your architecture: every difference between the rows points back at a field of the strategy — a decision you can name, defend, or revise — and pointing at decisions is everything an \(n\) of one is good for.

That is the last piece of framing the day owes you. What remains is to do it: audit a real window, write the strategy, formalise the row, and run the re-run. The lab is chapter 13.

13. Lab and Deliverables

Twelve chapters of moves, standards, contracts, and instruments — and so far not one of them has cost you anything or saved you anything, because nothing of yours has run. Lecture 9’s lab ended on a warning addressed to exactly this evening: “the context-engineering labs ahead will be measured against it” — it being your context budget policy. This is that lab, and the measurement is now. Tonight the policy stops being a deliverable and becomes the measuring stick: every line you record names the policy rule it was checked against.

The chapter has the usual four parts. Three in-class exercises walk from a live window to a written strategy to a formalised row. The homework executes the strategy on your own Locust instance — the same one your Lecture 9 row priced — and writes the act’s first before/after. The reflection log runs the audit once more, alone, on a session nobody staged for you. The optional reading collects the primary sources, including the ones that are built to expire.

13.1 In-class exercises

Three exercises, about forty-five minutes, each producing one artifact: a measured eviction, a falsifiable plan, and a schema the finale will have to vote on.

1. The window audit (~15 minutes). Open a real session — your Locust checkout, or the instructor’s demo session on the course repository if yours is not at hand — and run /context (chapter 11). Inventory what you see against two references: Lecture 7’s tenant table, which tells you who each occupant is and who put it there, and your policy’s numbers, which tell you what each is allowed to weigh. Then:

   • Find one tenant that does not earn its place. There usually is one — an instruction block no task this month has touched, an MCP server along for the ride, a paragraph of project lore that is really a skill in disguise.

   • Evict or restructure it: trim the instruction file, defer the server, extract the skill — the write and select moves of chapter 4, executed rather than admired.

   • Re-run /context and record before and after — tokens, not impressions.

   • The record is four lines: tokens before, tokens after, what was evicted and where it went (deleted, deferred, or moved to disk), and one sentence on what the eviction might cost a future task — chapter 10’s trade, acknowledged in advance.

   • Every recorded line names the policy rule it was checked against. A line that cites no rule either reveals a gap in your policy or does not belong in the record; both findings count.

2. The context strategy (~20 minutes, written). Fill chapter 12’s template for your own Locust instance — the same issue your Lecture 9 step-2 row priced. Estimate before you touch anything: field six runs Lecture 9’s pre-task recipe exactly as written, and an estimate made after peeking at the repository is half a peek. Then swap with a partner for a five-minute red-team, two questions only:

   • What did they pay for that they will not use? Every file on the shortlist whose why-line does not survive a stranger’s reading is \(P\) or \(d\) spent on comfort.

   • What will they need that they did not select? The inverse failure is worse and quieter — chapter 12 warned that a cut the task needed produces a cheaper session that fails.

   The swap is where the teaching happens — your own selections always look deliberate to you, which is precisely why field two demands why-lines a stranger can attack. Annotate your strategy with the red-team’s two best objections before it leaves the room; the homework will test whether they were right.

3. The row schema (~10 minutes). Lecture 9’s step 2 told you what to record in prose: “Estimate versus actual. Tokens in versus tokens out. Cached share.” Tonight you formalise it: write the JSON schema your own Locust row would validate against — issue, test, estimate, actual, tokens in and out, cached share, solved-or-not. Then two honesty annotations, straight from chapter 9:

   • Name two ways a schema-valid row can still be wrong. The schema checks shape, not truth — a solved-or-not box ticked from an impression instead of a test run validates beautifully.

   • Name the two stop-reasons that would void the guarantee if a model were filling this row in (chapter 9) — because in the finale’s pipeline, one might be.

   Bring the schema to the finale as a proposal. The class will need to agree on one schema before Locust-bench can be assembled, and a vote needs candidates. Nothing is assembled today.

Three things leave the room with you: a measured eviction with its rule citations, a red-teamed strategy, and a schema proposal. Keep all three. The first seeds tonight’s diary entry, the second is the homework’s script, and the third is the finale’s ballot paper.

13.2 Homework

Three items. The first is the one the whole day was built around; the other two are short, and one of them is reading.

1. Locust thread, step 2½: the engineered re-run. Execute your strategy from exercise 2 — not approximately, as documented, because tonight the strategy is the experiment and deviations are unrecorded variables.

   • (a) Set up. Arrange the context exactly as the strategy says: the shortlisted files, the instruction state from field three, the cache layout from field five. Capture your /context profile at the start — it is the “before” photograph of the window you engineered.

   • (b) Run. One fresh agent attempt on the same Locust instance as Lecture 9’s step 2. One attempt, not best-of-\(N\) — the same discipline as last week, for the same reason. When it stops, read /cost, or ccusage for the session (Lecture 9, chapter 12; chapter 11 noted the command’s mid-2026 alias).

   • (c) Record the row. The same row as step 2, in your own exercise-3 schema if you like: estimate first, measured actual after, tokens in and out, cached share, euros or window-share — and solved-or-not, which is still “not a vibe”: your fail-to-pass test answers it, not your impression of the diff.

   • (d) The before/after. Set Lecture 9’s row against tonight’s — tokens in, cached share, cost, solved-or-not — and write three things under the pair: the honesty sentence chapter 12 requires (one run against one run; calibration and craft, not significance), the /context profile from (a), and one closing paragraph: which move earned its keep, in which term of the formula you can see it — \(P\), \(d\), or \(N\) — and what you would try next.

   The strategy document travels with the row; a row whose strategy is lost has lost its explanation. Two notes on spirit, both inherited. Lecture 9’s holds word for word: “a failed attempt is a data point, not a failed homework” — an engineered run that does worse, honestly recorded, is worth more to the finale than a flattering one half-documented. And as last week: if your seat hits a usage window mid-attempt, record that too; the pause is part of what the row costs.

2. The portability bridge (~15 minutes). Make chapter 5’s configured fact true of your own project:

   • In your Locust checkout, extract the cross-tool content of your CLAUDE.md — build commands, test invocations, project conventions — into an AGENTS.md, leaving the Claude-specific remainder in CLAUDE.md plus the one-line @AGENTS.md import.

   • Verify the load with /context or a behaviour probe — a configuration you did not verify is a configuration you believe in.

   Two files, one source of truth, portable by construction — fifteen minutes of refactoring that outlives your tool choice.

3. Reading (~20 minutes). Two pieces, both in §13.4 with the rest of the bibliography:

   • Anthropic’s Effective context engineering for AI agents, end to end — after today you will read it as a colleague rather than a student, and you should notice which of its four techniques your strategy used.

   • A skim of the Manus lessons post, for what production agents taught one team the expensive way — the file-system-as-context and recitation patterns chapter 10 named.

13.3 Reflection log

One AI-diary entry for this lecture:

Run /context in the middle of a real session. Name the biggest tenant of your window that you did not put there on purpose. Evict or restructure it, measure again, and record before/after — plus one sentence on what the eviction cost you.

This is exercise 1 run again, alone, on a window nobody staged — which is the version that counts. The last clause is the load-bearing one: an eviction that cost you nothing is either a genuine free win or a sign you have not yet noticed what the tokens were doing, and chapter 10’s trade — fewer tokens because less information — is how you tell the two apart.

If no suitable session is at hand mid-week, the homework’s engineered re-run provides one: pause at its midpoint and run the audit there. The diary’s estimate-versus-actual column gets its final pass in the last lecture, next to the Claim Board, and entries like tonight’s are what will make that pass worth reading.

13.4 Optional reading

Everything the lecture leaned on, grouped, one line each on why it earns your time — with Lecture 9’s warning carried forward: several of these links are perishable by design. The vendor documentation pages below are not background reading but the places where you re-verify chapter 5’s most flip-prone fact and chapter 11’s mechanics before you rely on either.

The discipline (chapters 2 and 4):

• Anthropic. Effective context engineering for AI agents. The homework reading: the “attention budget” framing and the vendor’s four techniques, in the vendor’s own words.
• Manus (Yichao ‘Peak’ Ji). Context Engineering for AI Agents: Lessons from Building Manus. Production lessons — the KV-cache hit rate as the metric, the file system as context, recitation — from a team that rebuilt its framework four times.
• LangChain (Lance Martin). Context Engineering. The write/select/compress/isolate taxonomy chapter 4 organised the day around.
• Mei et al. A Survey of Context Engineering for Large Language Models. The 1,400-paper academic consolidation; its taxonomy cuts differently from LangChain’s, which is itself a lesson in how young the discipline is.
• Context Engineering 2.0. arXiv:2510.26493. The honesty footnote: the practice traces back to 1990s context-aware computing — 2025 named and unified it; it did not invent it.

The evidence (chapter 3):

• Liu et al. Lost in the Middle: How Language Models Use Long Contexts. TACL 2024; taught in Lecture 6, cited today as a standing engineering constraint.
• Chroma Research. Context Rot. Eighteen models, one direction: accuracy on buried information decays as input grows.
• NoLiMa. arXiv:2502.05167. Remove the lexical overlap and the needle-in-a-haystack flattery collapses — chapter 3’s sharpest figure.
• SlopCodeBench. arXiv:2603.24755. Structural erosion over long coding sessions; emerging and not yet peer-reviewed — read it with exactly that grain of salt.
• Gloaguen et al. Evaluating AGENTS.md. The minimalism result behind chapter 5: one study, not consensus — and your policy’s max-size rule is the practical hedge either way.

The standard (chapter 5):

• AGENTS.md. agents.md. The spec itself — short enough to read while the coffee brews, which is the design.
• OpenAI. Codex AGENTS.md guide. The reference implementation: the discovery chain and the 32 KiB default budget — a context budget enforced by a loader.
• Anthropic. Claude Code: Memory. CLAUDE.md mechanics, imports, and the documented @AGENTS.md bridge from homework 2 — the page to re-check the week you rely on it, because chapter 5 told you it can flip.

Retrieval (chapters 6–8):

• Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020 — where the acronym comes from.
• Anthropic. Contextual Retrieval. The failure-rate ladder behind chapter 6’s numbers; a vendor eval, and says so.
• CodeRAG-Bench. arXiv:2406.14497. NAACL 2025 Findings; the measured retrieval ceiling of chapter 8.
• Li et al. (Google DeepMind). Self-Route. EMNLP 2024; the long-context-versus-RAG debate resolved as economics — and you can now price both sides yourself.
• Magesh et al. Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools. The preregistered study behind chapter 8’s flagship number; if you read one paper from this list, read this one.
• Cursor. Improving agent with semantic search. The index camp’s evidence, published by the index camp — Lecture 8’s nine questions travel well.
• Anthropic. Building agents with the Claude Agent SDK. The agentic camp’s position statement — equally a vendor document; read the two posts back to back and you have chapter 7 from primary sources.

Structured outputs (chapter 9):

• OpenAI. Structured outputs. The JSON-mode-versus-strict-schema distinction every team must know, from the vendor that drew it first.
• Google. Gemini structured output. Carries the sentence chapter 9 built a section on: structured output “does not guarantee the values are semantically correct.”
• Anthropic. Structured outputs. The documented escape hatches — check the stop reason before parsing. All three vendor pages are perishable by design, and together they are the first place to re-verify chapter 9’s landscape.
• Willard & Louf. Efficient Guided Generation for Large Language Models. The mechanism paper — already cited in Lecture 6 §15.1, listed again because chapter 9 stands on it.
• Tam et al. Let Me Speak Freely?. EMNLP 2024; the case that format restrictions degrade reasoning.
• dottxt. Say What You Mean. The rebuttal; both parties have stakes, which is why chapter 9 taught you the disagreement rather than a verdict.
• instructor. python.useinstructor.com. The parse-validate-retry wrapper as an installable habit.

The board’s ledger after today is the shortest of the act, and deliberately so: nothing came down, and nothing went up. No new card was pinned — a decision, not an omission (chapter 1) — and the state carries over from Lecture 9 unchanged: claims 4 and 5 still pinned, the sixteen-hour claim still waiting for the finale; claims 6, 7, and 9 standing wherever your share-out left them. The diary keeps collecting estimate-versus-actual gaps, tonight’s eviction entry among them.

And the Locust thread is now the richest artifact you own. After tonight, each of you carries two rows and a strategy: an unengineered attempt, an engineered re-run, and the half page that explains what changed between them — plus a schema proposal for what every future row should look like. That is no longer homework residue; it is the raw material of a benchmark with a cost column, waiting for one decision the class has not made yet.

One column of that row is still soft, and you know which one. Solved-or-not is currently answered by you, running a test by hand and writing down a boolean — honest, but hand-checked honesty does not scale to a class-sized benchmark, let alone to a pipeline that runs without you watching. What “solved” is allowed to mean — who checks the box, with what test, wired into what pipeline — is the next lecture: Validation, Trust, and CI Integration. The finale then assembles what the class has been building all along. Bring both rows.