Lecture 7

THE SYSTEM AROUND THE MODEL

AI-Supported Software Development — SoSe 2026
Four promises from Lecture 6
Promise from Lecture 6 Paid today
Resolve mystery 8 — same instructions, different tools, different behaviour Chapters 3–4 build it · chapter 12 retires it
Reframe skills as codified prompt patterns Chapter 7
Introduce MCP — the open tool/data standard Chapter 9
Set up evaluation — Act 3 begins Chapter 13
the contractEvery debt visible from the first page — and every one paid by the end of the lecture.
Two blocks, one zoom-out
Block A — The Orchestration LayerChapters 2–10 build the system piece by piece: the zoom-out, the token sequence, CLAUDE.md, memory, skills, the tool loop, MCP, the budget.
Block B — Lab, then ceremonyThree exercises on your own Locust files — then the Mystery Board comes down and Act 2 closes.
today's diagram tickThe LLM-in-One-Picture reaches its final Act 2 form: v1.3 — one version tick per lecture since Lecture 4.
The model is powerful but passive; the orchestration layer is simple but active — and knowing which job belongs to which is what separates someone who uses AI tools from someone who engineers with them.
the sentence to carry from here to the exam — chapter 2 earns it
1

The Orchestration Layer

LLM-in-One-Picture v1.3
Orchestration layer CLI / IDE / application
reads files from disk · manages conversation history · selects context · routes tool calls · makes the API calls
↓ token injection — which tokens, and when
The model
inputs→ tokens→ transformer→ distribution→ sample→ append ↺ repeat
the entire picture from Lectures 4–5, unchanged — now collapsed to one box
↑ output tokens — back to the wrapper, not to the world
parse what came back
plain text show it to the user
tool call execute it, append the result, send the sequence again
Two arrows, two jobs
arrow in — token injectionThe orchestration layer assembles a token sequence — from files it loaded, the conversation so far, and tool results — and ships it in.
arrow out — output tokensThe model's tokens go back to the wrapper, not to the world. It parses them: plain text → display; tool call → execute, append, send again.
the whole lectureEverything the model does to the outside world, it does by emitting tokens the wrapper chooses to act on. It has no other interface. It never did.
Powerful but passive, simple but active
The model The orchestration layer
Initiates anything? Never — runs only when called Always — loads files, assembles context, makes every call
Reads the filesystem? No — does not know what files exist Yes — by rule (file discovery, tool execution)
Executes commands? No — only describes a command in tokens Yes — decides whether and how to act
Persists between conversations? No — nothing carries over inside Yes — files on disk
How it fails Probabilistically — distribution shape, attention competition Deterministically — a rule fired or it didn't
Call it out
Inner box or outer box?
A surprising word choiceinner — distribution
A file got loaded… or didn'touter — rules
It "remembered" a preferenceouter — filesystem loop
Decide before you read the tag. Three observations, three diagnoses.
Two systems, one illusion
the Lecture 3 "magic", dissolvedTwo systems were always involved. The orchestration layer noticed CLAUDE.md and loaded it — a rule, a dozen lines of code. The model then processed those tokens through attention — strong, but never absolute.
the magic was a division of labourOne system put the tokens in the room; the other listened to them, probabilistically.
Why the wrapper stays invisible
interface designA chat window presents a single persona — one name, one voice. Every capability gets attributed to that persona: "the AI has memory", "the AI ran the tests".

The persona is a deliberate, reasonable design choice. But it is also why nearly every user's mental model is wrong in the same direction: everything is credited to the model, and the wrapper — where most engineering decisions live — becomes invisible.

v1.3's jobYou cannot engineer what you cannot see. Make the wrapper visible, and keep it that way.
2

What the Model Actually Sees

The token sequence, end to end
One API call — what the model receives, top to bottom
[system]
system prompt
role definition · safety guidelines · tool descriptions · response-format rules
config-dependent — mostly tool schemas
[user]
CLAUDE.md contents
project conventions · architecture notes · command reference
~100–2,000 tok
[user]
memory index + memory files
~50–500 tok
the conversation so far — appended turn by turn
[user] your first message
[asst] first response
[asst] second response + tool call
[user] tool result
···
[user]
your current message
generation frontier
→ the model’s one job: predict the next tokens, given everything above — and after it, nothing.
The role rhythm

Strip away the contents and one API call is just a sequence of role-labelled turns — and the role labels are tokens in the text, not metadata around it:

[system] [user] [user] [user] [asst] [user] [asst] ··· [user]
one detail[system] is not a flag on a database row. It is rendered into the sequence as special turn-boundary tokens — the same kind post-training was formatted with. The labels are part of the text the model reads.
Observation 1: no instruction channel
observation 1From the model's perspective, there is no difference between CLAUDE.md tokens and your question tokens.

At the embedding layer there is no instruction channel (Lecture 5), and there is no instruction channel anywhere else either. The only structural marking is the role label — and a label is influential not because the architecture enforces it, but because post-training taught the model to weight [system] turns heavily.

the interface lies (helpfully)Your chat window renders the blocks differently — instructions hidden, messages in colour, tool output folded away. The model sees none of it. It receives a flat sequence of tokens.
Observation 2: the sequence only grows
observation 2The sequence only grows. Every reply, every tool result, every correction, every false start — appended. Never removed, never overwritten.

Your mistakes and the model's mistakes stay in the sequence alongside everything that came after them. Chapter 6 turns this property into the most counter-intuitive practical scenario of the day.

Observation 3: re-sent on every call
observation 3The entire sequence is re-sent on every call. The model is stateless — a forward pass is a function from a token sequence to a distribution. The continuity you experience is carried entirely by the sequence itself.
KV cache ≠ "the model remembers"The KV cache saves recomputation within one generation. It changes what must be recomputed — not what must be sent. The full sequence ships every time.
Observation 4: one response = many calls
observation 4What you experience as one assistant response is frequently many API calls.

Each time the model wants to read a file or run a command, generation stops, the wrapper acts, the result is appended, and a fresh call ships the grown sequence back. Five or ten round trips behind a single apparent "response" is unremarkable.

a consequence you can feelResponses slow down as a session ages — every generated token attends over the whole accumulated sequence. The mechanics of that loop are chapter 8.
The message array

What the orchestration layer keeps between calls is almost embarrassingly plain — a list with an append method:

messages = [
  { role: system, content: <system prompt> },
  { role: user,   content: <CLAUDE.md contents> },
  { role: user,   content: "Fix the failing test in parser.py" },
  { role: asst,   content: "Let me look." + tool_call(Read, parser.py) },
  { role: user,   content: <tool result: parser.py contents> },
  { role: asst,   content: "Done. The off-by-one on line 41 is fixed." },
]
one write, one readThe array supports exactly one write — append. Its one read is the API call: serialise the whole array and ship it — not the delta — on every round trip.
Every chapter from here is a rule about what gets appended to this array, and when.
CLAUDE.md loading · memory · skills · tool results · the context budget
Checkpoint: the token sequence
hold these four 1. One sequence, top to bottom — no side channel.   2. It only grows.   3. Re-sent in full on every call.   4. One "response" = many API calls.

Every chapter from here applies them. Next: how CLAUDE.md becomes part of this sequence.

3

How Context Enters the Sequence

Rule 1: the ancestor walk
Session started in /project/src/components/ — the CLI walks up the tree to the root, collecting every CLAUDE.md it passes
walk up ↑
/project/CLAUDE.mdloaded · ancestor
/project/src/CLAUDE.mdloaded · ancestor
/project/src/components/CLAUDE.mdloaded · working dir
The walk runs before your first message — a dozen lines of ordinary code, no model involved — and hands over one concatenated [user] block.
Rule 2: on-demand injection
Rule 2 — a directory’s CLAUDE.md is injected the moment a tool call first touches it
[user]
/project/CLAUDE.md tokens
loaded at start
[user]
/project/src/CLAUDE.md tokens
loaded at start
··· the conversation so far ···
[asst]
tool call: Read tests/test_foo.py
touches a new directory
[user]
/project/tests/CLAUDE.md tokens
← injected NOW
[user]
tool result: contents of test_foo.py
Once per file, mid-sequence. A directory’s conventions are paid only by the conversations that actually open it.
The neural network does not decide
the loading claimThe neural network does not decide which instruction files to load — it cannot ask for more context. The orchestration layer decides, by rules as dumb as directory traversal.
dumb is a featureBecause the rules are mechanical, you can know — exactly, without running any model — which instruction files entered a given session. A neural decision would be one you could neither predict nor audit.
Never loaded vs loaded but outcompeted
Failure mode What happened Which half The fix
Never loaded Neither rule fired — the file sits where the walk never went Orchestration (this chapter) Move the file up the tree, or start where the walk finds it
Loaded but outcompeted Tokens are in the sequence, but attention competition eroded them Model (L5 §16.1 + L6) Shorten, front-load, back with deterministic enforcement
both wear the same face"The model ignored my CLAUDE.md" — but the two fixes have nothing in common, which is exactly why the diagnosis matters.
Memory: the read-write loop
Read memory files
at start
→
Inject as tokens
→
Model reads
(in-context)
→
Model writes
new memory
→
Next session
starts blank
the pytest anecdote, dissolvedMemory is a read-write loop mediated by the filesystem — the persistence lives on disk, not in the model. Each conversation starts with a model that has never met you.
CLAUDE.md vs MEMORY.md
Aspect CLAUDE.md MEMORY.md + memory files
Who writes it A human — deliberately The model — during conversations
Where it lives In the repo, version-controlled Outside the repo — per user, per machine
Shared with the team? Yes — everyone who clones gets it No — it follows you, not the project
Reliability Human-reviewed, diffable Unverified — possibly stale or wrong from the start
"works on my machine", AI-era variantSame repo, same CLAUDE.md, same model — different behaviour. Their memory directories differ, so the sequences differ, so the distributions differ.
What can go wrong with memory
StaleThe project moved on; the memory didn't. May's truth, asserted in June — in the privileged early positions.
Born wrongThe model writes memory by sampling, exactly as it hallucinates in chat. "Team adopted httpx" — when it was only discussed.
UnverifiedNothing checks a memory against the codebase. Attention can't tell "team convention" from "thing it concluded one Tuesday".
the postureTreat memories as soft context — useful for preferences and continuity — and verify any load-bearing technical fact against the repository.
The mid-conversation edit
You edit CLAUDE.md mid-session and re-read it — here is the sequence afterwards
[user]
v1CLAUDE_md_v1_tokens
position ~500 · loaded at start
~10,000 tokens of conversation: prompts, responses, tool calls, tool results
[asst]
tool_call(Read, CLAUDE.md)
you ask it to re-read
[user]
tool_result: v2CLAUDE_md_v2_tokens
position ~10,500 · lands here
No overwrite, only accumulation. Your edit changed the file on disk — but the model sees the sequence, and the sequence can only grow. v1 and v2 now coexist.
State machines forget; sequences remember
# a state machine
x = 5
x = 10
print(x) # 10 — the 5 is gone
# a token sequence
CLAUDE v1 @ pos 500
CLAUDE v2 @ pos 10500
generate(...) # both vote
the deepest counter-intuitionState machines forget; token sequences remember everything, including what you wanted forgotten.
Start a new conversation
the only true overwriteFresh sequence. The orchestration layer reads CLAUDE.md from disk as if for the first time; only v2 is loaded; v1's tokens do not exist anywhere, because the message array they lived in is gone.

The folklore — "when in doubt, start a new chat" — finally gets its mechanism. Restarting isn't free: it forgets the bad and the good together. Judging when accumulated context has stopped earning its place is chapter 10.

Forward pointer: retrieval (Act 3)
the smallest external knowledge storeA directory of text files, read at startup and injected as context, is the minimal implementation of external knowledge.

Act 3 meets the same idea again, scaled up, under the name retrieval (RAG) — where an algorithm replaces the filesystem walk in deciding what gets injected. The architecture is identical: knowledge outside the model, selected and spliced in by the orchestration layer.

4

From Context to Action

Skills: codified prompt patterns
Lecture 6's promise, keptA skill is a prompting pattern — a few-shot or chain-of-thought pattern — captured as a file on disk, injected into the token sequence only when it is triggered.
.claude/skills/error-handling/SKILL.md
---
name: error-handling
description: Use when writing or changing HTTP error handlers
---
Follow the project's error-handling pattern. Two references: ...
CLAUDE.md vs Skill: a timing rule
Aspect CLAUDE.md Skill
When it loads Every session, at start Only when triggered
Token cost Paid in every conversation Paid only when used
What it carries Always-relevant conventions One task's pattern
Until needed — Sits on disk, at zero token cost
the whole differenceSame transport as CLAUDE.md — text spliced into the sequence. The entire difference is a timing rule inside the orchestration layer.
Always-on → on-demand → workflows
Always-on
CLAUDE.md
→
On-demand
Skills
→
Workflows
skills that invoke skills
the arcThe orchestration layer getting progressively smarter about when to inject which tokens. The layer stays simple; its rules get more discriminating.
The loop that acts
the channel that flows back outEverything so far moved text into the sequence. This is the channel that flows back out — tokens that act on the world.

How can a model that only emits tokens nonetheless read files and run tests? It cannot. The orchestration layer does — on the model's behalf, when the model's tokens ask it to.

The mechanism, in five steps
Emit tokens
that describe a call
→
Intercept
→
Execute
actual I/O
→
Append result
→
Re-call model
no new machineryStep 1 is a next-token prediction. Step 3 is actual I/O — the model is idle. A sixth step hides between 2 and 3: the human permission gate.
"Fix the bug in stats.py" — four API calls
“Fix the bug in stats.py” — one response, four API calls
[user]
“Fix the bug in stats.py”
[asst]
“Let me read the file.”
tool_call(Read, stats.py)
↓ orchestration executes Read — one full API round trip ends here
[user]
tool result stats.py contents
~500 tok
[asst]
“The comparison in percentile() looks inverted. Let me check the tests.”
tool_call(Read, test_stats.py)
↓ orchestration executes Read
[user]
tool result test_stats.py contents
~300 tok
[asst]
“Confirmed. Fixing it.”
tool_call(Edit, stats.py, …)
↓ orchestration executes Edit
[user]
tool result “File updated successfully”
[asst]
“Done. The inverted comparison in percentile() is fixed.” — no tool call, so the loop exits and this reaches your screen.
Act–observe–act
Reason
→
Act
emit a tool call
→
Observe
result returns as tokens
↺
chain-of-thought that acquired handsSome intermediate tokens now trigger execution, and the world's replies return as context. A failed command is not an exception — it's just more tokens, and the next attempt is conditioned on the exact failure text.
Division of labour in the loop
In the loop The model The orchestration layer
Contributes The decision, as tokens Every action on the world
Sees Only the token sequence The filesystem, the network, the shell
Carries state between calls Nothing The whole message array
Fails by Distribution problem (L6's toolkit) Software problem (a debugger)
the polarity, sharpestThe layer that can do everything decides nothing; the model that decides everything can do nothing.
Every capability that touches the world belongs to the orchestration layer; the model contributes exactly one thing — the decision, expressed as tokens.
the model has no hands. it has no eyes. it has tokens.
Checkpoint: skills and tool calls
four to keep 1. Skill = codified prompt pattern, loaded on-demand.   2. Tool loop = five steps, all append-only.   3. "Fix the bug" = four API calls.   4. The boundary: model decides (tokens), wrapper acts (I/O).

Next: the standard interface, and the one window everything shares.

Why a standard: N×M → N+M
N apps × M tools
= N×M bespoke integrations
→
a protocol
in the middle
→
N + M
one client each, one server each
not an AI problemAn interface-explosion problem, solved by software engineering's standard technique. LSP did it for editors × languages; MCP does it for AI tools × data sources.
MCP: indistinguishable from native
The Chapter 8 loop, unchanged — only the executor behind the tool got swapped
[system]
built-in Read · Edit · Bash
via MCP tracker_search — “search issues by text”
[user]
“Is there an open issue about the rate limiter?”
[asst]
tool_call(tracker_search, query="rate limiter")
↓ the orchestration layer routes the call to the MCP server
[user]
tool result 1 open issue — #4112 “Rate limiter drops bursts”
[asst]
“Yes — #4112 looks like exactly your case…”
to the modelAn MCP tool is indistinguishable from a native one. The standard lives entirely in the orchestration layer; the model needs no MCP support.
Four enforceable decisions
Decision wired at the interface Mechanism What it gives you
Which tools exist The catalogue you expose The model cannot call what isn't there
What each may do Permissions / scopes A read-only tool can't write
What shapes are legal Schema validation Malformed calls rejected before I/O
What gets audited Logging at the boundary Every action is on the record
L6's enforcement layer has a street addressThe permission gate you've seen all semester — "may I run this command?" — is the orchestration layer holding a call at this interface.
Capability = tool surface, not intelligence
the security thesisWhat an AI system can actually do is determined by its tool surface, not by its intelligence. The model cannot exceed the tools the orchestration layer wires up.

Every tool you add widens what a hijacked token sequence can do. A model that emits a destructive call because an attacker buried an instruction in a web page is not malfunctioning — it is completing the most plausible continuation.

the defenceNever a sterner CLAUDE.md. A narrower tool surface. Enforcement, not influence.
Everything competes for the same window
Context source Typical size (tokens) Who controls it
System prompt — role, guidelines, built-in tool schemas config-dependent (often five figures); MCP schemas deferred The vendor
Instruction files — the CLAUDE.md hierarchy ~100–2,000 You
Memory files ~50–500 The model
Conversation history grows without bound Everyone
Tool results — files, command output ~100–10,000+ each The task
Current prompt ~50–5,000 The user
Response space whatever remains Nobody — the remainder
one window, not separate poolsEverything competes for the same finite window — and being in the window is necessary; being attended to (per head, per query position) is the real currency.
Hands up
Your Locust CLAUDE.md — how many tokens?
< 200  ·  200–500  ·  500–1,000  ·  > 1,000
That cost is paid in every conversation you start in that repo. Hold the number — the lab measures it for real.
Why is there a maximum at all?
nothing in the arithmetic imposes a ceilingAttention multiplies a sequence of any length; the feed-forward network runs per token; the residual stream does not care if it carries a hundred tokens or a million.
so where does the size come from?The maximum context window is nowhere in the transformer's arithmetic — it is a declared limit. Three constraints from Lecture 5 force the declaration.
Three constraints from Lecture 5
Constraint Why it bounds the window
Position A learned table runs out of rows; rotary/relative schemes drift past the trained length — the model no longer knows where a token is
Quadratic attention Every token scores every other → an N × N grid per head, per layer. The published number is the length they paid to train
KV cache Stores a key+value per token at serving time; grows with the conversation and must fit in accelerator memory
read honestlyThe vendor's number means "trained, affordable, and supported up to here." A property of the deployment as much as the architecture.
Window sizes: a short history
Generation Year Context window
GPT-2 2019 ~1K tokens
GPT-3 2020 ~2K tokens
GPT-4 era 2023 8K/32K at launch; 128K with Turbo
Current frontier 2024–2026 200K – 1M tokens
three orders of magnitude in seven years — and this chapter still existsWindow growth bought headroom, not automatic immunity. More room helps only if the added context is relevant and well placed; lost-in-the-middle is an empirical, model/task-dependent U-shaped effect.
When the window fills
Sliding windowDrop the oldest messages. Cheap, predictable, and brutal — turn three is simply gone.
Keep N recent turnsPreserve the system prompt + instructions at the head; the middle of the session is lost.
SummarisationCompress older turns into a digest — but the digest is generated text, with opinions.
eviction is a system decisionWhen a long session "forgot" something, the orchestration layer evicted it — not a memory failure inside the weights. Act 3 names this discipline: context engineering.
5

The System, Completed

The influence layer, revisited
influence = anything that enters the token sequenceInstruction files, memories, skills, tool results, prompts — all the same kind of thing: text spliced in, competing for attention.
three rules, now derivableKeep it concise (the budget).   Front-load (position + lost-in-the-middle).   Be specific (distribution shape).
The enforcement layer, revisited
enforcement = determinism bolted on from outsideLinters, tests, CI, schema validators. The output re-enters the model as tool-result tokens — a gate on the way out, a feedback signal on the way back in.
the dual natureA failing test is deterministic on the way out and influence on the way back in.
Determinism cannot be prompted into the model; it has to be bolted on from outside.
a better influence layer narrows the distribution — only the enforcement layer truncates it
The human layer, revisited
human = author of every wrapper decisionWalk back through chapters 2–10: every load-bearing decision was a human decision expressed as configuration — CLAUDE.md content, memory curation, skill codification, tool permissions, budget policy.

The model is powerful but passive, the wrapper simple but active — and the activity is scripted. The orchestration layer has no judgement of its own; every rule it follows is a rule a human wrote down.

The three-layer model, completed
Layer Lecture 6 description Act 2 mechanism Where in v1.3
Influence Probabilistic Files & patterns become tokens; attention shapes the distribution Inside the token sequence
Enforcement Deterministic Exit codes & validators; results re-enter as tokens In the wrapper's world
Human Semantic Decides what "right" means; authors every config decision Outside both
carry this into Act 3Every property is now derivable, not asserted. Influence = chs 3–7. Enforcement = ch8's feedback loop. Human = every chapter's configuration decision.
Likely, catches, judges
asserted in L6, derived todayThe influence layer makes the model likely to do the right thing; the enforcement layer catches it when it does not; the human layer judges what "right" means.

Likelihood is attention arithmetic and distribution shape. Catching is determinism injected from outside. Judging is the one part that was never next-token prediction to begin with.

Checkpoint: from mechanism to framework
three layers, fully derived 1. Influence = tokens in the sequence (chs 3–7).   2. Enforcement = determinism from outside the model (ch8 loop).   3. Human = author of every wrapper decision.

Every mystery on the board is now answerable somewhere inside this picture. Which means the board has served its purpose.

Think — pair — share
Same instructions, two tools, different behaviour. Why?
You've had the mechanism for two chapters now. Name the differences before the reveal.
Mystery 8, fully resolved
why do different tools behave differently from the same instructions?Four concrete differences — each a mechanically different token sequence:
Different filesCLAUDE.md vs AGENTS.md vs copilot-instructions
Different placement[system] vs [user] — different learned weight
Different loadingstart vs mid-conversation — different position
Different contextdifferent memories, skills, tool results
there was never anything else to explainSame weights, different wrapper, different token sequence, different behaviour.
The Mystery Board comes down (1/2)
# Mystery Resolved Mechanism, in one line
1 Can't count letters L4 Tokenisation hides characters inside multi-character tokens
2 CLAUDE.md inconsistent L5+L6+L7 Injected as tokens (L7); attention competition, drift (L5+L6)
3 English prompts better L4+L5 Token efficiency + attention-competition effects
4 Curated > paste-all L5 Distractor tokens compete with what matters
5 Hallucinated APIs L6 Pattern completion, no ground-truth check (flat OR confidently wrong)
6 Vague prompts → nonsense L6 Under-specified task; model fills gaps from learned priors
The Mystery Board comes down (2/2)
# Mystery Resolved Mechanism, in one line
7 CLAUDE.md compliance inconsistent L6 Attention competition + positional effects
8 Different tools, different behaviour L6+L7 Different files, placement, loading, context → different sequences
9 Few-shot works L6 In-context learning via induction heads
10 Step-by-step helps L6 CoT uses the auto-regressive loop as a scratchpad
11 Voting improves accuracy L6 Self-consistency: variance reduction over reasoning paths
the board is closedEvery mystery from Act 1 has a mechanistic explanation.
Every mystery from Act 1 has a mechanistic explanation — there is no magic, and there never was.
and it reaches past the elevenEven the question the board never listed — why is the context window finite? — falls the same way: position, quadratic cost, KV cache. Architecture and deployment, not magic.
The question changes
Act 2 askedWhy does the system behave this way? — answered by naming the mechanism.
Act 3 asksHow do we engineer reliable software work on top of that behaviour?

The question changes from explanation to engineering — budgets turned into policies, anecdotes upgraded to measurements, "it seems better" upgraded to a number.

What Act 3 holds
Context engineeringThe budget, turned into a deliberate discipline.
AGENTS.mdThe cross-tool instruction-file standard.
Retrieval (RAG)External knowledge, selected by algorithm.
Validation + CIThe enforcement layer, built out.
SWE-benchAct 3's first stop — measuring what these systems can do (contested — see L8).
names only — for nowEach gets its own full treatment. Bring your redesigned CLAUDE.md next week.
What you'll do in the lab
Three exercises — on your own Locust files
1. Context budget calculator — measure your real token numbers, fill the tenant table.
2. Buried-instruction experiment — test the positional story empirically.
3. CLAUDE.md redesign — the capstone of Act 2.
Deliverables: a context-budget policy with numbers · an experimental record · a before/after CLAUDE.md with a rationale for every change.

Questions?

THE SYSTEM AROUND THE MODEL

dome.muller@googlemail.com

Welcome to the Act 2 finale. Last week ended with an accounting: ten mysteries solved, one (mystery 8) left open. Today the board comes down for good. One move of the camera makes it possible — for three weeks we were INSIDE the model; today we step outside it.

Make the debts explicit from page one. Hold the class to this contract: every promise gets checked off by the end. The shift that makes all four possible is a single move of the camera — out of the model and into the wrapper around it.

Block A is dense: ten chapters of architecture. Block B is hands-on, then ceremonial. On the page the lab sits last by convention; in the room the exercises come FIRST and the ceremony after — the board should come down while your hands are still warm from the lab.

State the thesis BEFORE it is earned — chapter 2 earns it properly. For now, hold it as the lens through which every chapter looks.

Every Act 2 lecture opens by changing what the running diagram shows. L4 introduced it; L5 unlocked the transformer interior. Today the camera moves backwards for the first time — the whole picture becomes one box inside a larger one.

v1.3 — one version tick per lecture since L4. Nothing INSIDE the old picture changes; what changes is the frame. Read the arrows: the arrow IN (token injection) is everything this lecture is about; the arrow OUT goes to the wrapper, not the world, and is the tool loop (ch8). The outer box is DIFFERENT for every tool — which is precisely mystery 8's soil.

Read the arrows, because the arrows are new and they are the whole lecture. The arrow IN is everything this lecture is about. The arrow OUT is the tool loop (ch8). The outer box is different for every tool — mystery 8's soil.

Walk each row. This table is the lens for the rest of the course. When something goes wrong, the first question is: which box? People write elaborate prompts to fix orchestration problems and fiddle with config to fix distribution problems — misdiagnosing the bin is the most common failure mode.

Quick. Each card is a diagnostic exercise. Ask the room to call the box before revealing the tag. Surprising word choice → inner (Lectures 4–6 toolkit). File loaded or not, a 'memory' that appeared → outer (this lecture).

Reference their own Locust CLAUDE.md. The magic was twelve lines of ordinary code (a directory walk) plus attention (L5). Two systems, one illusion.

EXTENDED. Why users misattribute everything to the model. Act 3 is largely about making deliberate decisions in this invisible layer.

The centrepiece. The one object that ever crosses the boundary between the two boxes: the token sequence the orchestration layer assembles and ships. If you carry a single picture out of today, carry this one.

Walk it top to bottom. System prompt: the vendor's block, before anything you control. CLAUDE.md: your first control point. Memory: files the model wrote for itself. Conversation: the growing middle. At the bottom, your current message; after it, nothing. There is no side channel — if a fact is not in this sequence, the model does not have it.

The tool result — the contents of a file the MODEL asked for — arrives marked [user]. From the model's standpoint, the world answers it in the user's voice. Nobody inside the model chose that; the orchestration layer assigns the label.

Strip the learned preference away and [system], CLAUDE.md, and your question are the same kind of thing: text in a sequence. The visual hierarchy you experience has no counterpart on the other side of the API.

Quick. Foreshadow ch6: this property stops being bookkeeping and starts producing behaviour when you edit CLAUDE.md mid-session.

The KV cache is L5's optimisation. What the growing payload implies for long sessions — Lecture 9 picks up. Today it is enough to register the protocol fact.

Foreshadow ch8. You typed one question; behind the scenes, five API calls happened, each re-sending the entire accumulated sequence.

This is the simplest possible data structure doing the simplest possible thing. No database, no relevance ranking, no intelligence — bookkeeping that the entire system stands on. Once you see the array, every behaviour in chapters 4–10 is some rule about what gets appended to it, and when.

Pivotal framing. CLAUDE.md loading = an append rule at start. Memory = an append at start from a model-written directory. A skill = an append on a trigger. A tool result = an append mid-loop. The context budget = what to do when the array's serialisation approaches the window's edge.

Quick consolidation. These four observations carry most of the explanatory weight of the lecture.

Three closely related sections in one chapter: how files become tokens (CLAUDE.md), the files the model writes for itself (memory), and what happens when a file changes mid-session.

A loop any of you could write in a dozen lines. No model has run yet. The most consequential context decision of the session is made by filesystem traversal. The Locust CLAUDE.md was a root-level file — present in every session you ever ran.

The testing conventions arrive when the model first touches the tests — mid-array, at a late position. A conversation that never touches tests/ never receives those tokens.

The closest the model comes is indirect: rule 2's trigger is a tool call it emitted — but it asked for the test file, not for the conventions. The orchestration layer's stupidity is what makes the system debuggable.

Before today you couldn't tell these apart; now it's a five-minute check.

In session 1 the model wrote a memory file recording your preference. In session 2 the orchestration layer injected it before you typed anything. Attention did the rest. At no point did the model retain anything between sessions.

By the time the tokens reach the model, both are the same kind of thing: text in early positions competing for attention. Every difference that matters lives one layer up — in who writes the files, and where they sit.

A chat hallucination scrolls away. A hallucinated memory is re-injected into every future conversation until someone deletes it. The repository is ground truth; the memory directory is notes about it.

Your edit changed the file on disk — but the file on disk is not what the model sees. The model sees the sequence, and a sequence cannot be edited retroactively. Both versions now vote at every generation step — intermittent compliance.

Assignment is destructive — after line 2, the value 5 does not exist anywhere. A token sequence is the opposite: both 'assignments' exist forever, and a question about x is answered by weighing them.

A new conversation is the only true overwrite this system offers. If you must stay in the session, repeat the corrected rule in your next message — recency advantage. But that is influence management, not an overwrite.

EXTENDED. One forward-pointer to Act 3. Names only — do not expand.

The first half of Block A moved text INTO the sequence. This half is where the layer stops being a loader and starts being a system — skills loaded on a trigger, and the loop that lets a passive predictor act on the world.

L6 taught you the patterns; a skill is how a team reuses one without retyping it — and without spending its tokens in sessions that never need it. Structure, promoted from habit to artifact: it has a filename, lives in version control, can be diffed and improved for everyone at once.

Anything in your CLAUDE.md only relevant to one kind of task is a skill waiting to be extracted. The lab asks you to find exactly those lines.

Keep light. The thread ends at the course finale, where the orchestration layer stops being simple.

Mark the turn from inbound context to outbound action.

The model emits tokens that look like a tool call. The wrapper intercepts, executes, appends the result, calls again. The model has no hands; it only ever emits tokens.

Each arrow is the end of one API call. Four calls behind a single 'response'. The model never saw stats.py before the wrapper executed its request and appended the contents. By the final 'Done', the conversation is permanently heavier.

The named loop: act–observe–act. L8 references it by this name. When an agent 'self-corrects', this is the mechanism.

The last row is the one to keep for Act 3. Model failure = distribution problem. Wrapper failure = software problem.

Let this land. The sharpest articulation of the polarity, and the sentence Act 3 references.

Quick consolidation. Bridge to MCP and the budget.

Keep schematic. The argument is arithmetic, then a reference to LSP, then MCP by name. No wire-level detail.

The loop from ch8 runs unchanged; only the executor behind it got pluggable. Extending what the system can do required touching only the simple-but-active layer.

Wiring up a tool is a security decision, every single time.

Security = tool surface + permissions + schema validation + human gate. The defence is enforcement, not influence.

Read the control column: no single party manages the budget. The vendor takes its share before you type; the task dictates tool-result size; the response is the remainder.

Quick poll. Most people underestimate. The first lab exercise turns this guess into a measured number.

Coming from L5, students see no reason for a ceiling — feed a longer sequence through the same weights and every matrix multiply is still defined. The limit is declared, not architectural.

Position bounds where it can place a token; quadratic cost holds the training length down; the KV cache holds the servable length down. The usable window can be smaller than the declared one — model/task-dependent (§10.1's attention competition).

Demand grows to fill supply: agentic workflows read whole files and run whole test suites. A serious session fills even a 200K window without trying.

EXTENDED. In all three strategies information is lost — the only choice is which, and by whose rule. The heuristic: when responses slow or early instructions stop biting, a fresh conversation is a budget reset.

Every component is on the table. Now step back: revisit Lecture 6's three-layer model with Act 2's full vocabulary — nothing needs to be asserted anymore, every property can be derived. Then the board comes down.

L6 said 'keep CLAUDE.md concise' was advice. Now it is arithmetic over rule one. Memories, skills, tool results — all influence-layer material, whoever wrote it, whenever it arrives.

Determinism cannot be prompted into the model — L5's forward pass ends in a sample. The enforcement layer truncates; the influence layer only narrows.

Let it land. This is why Lecture 6's three-layer model places enforcement as a separate, non-negotiable layer.

The human layer is not just review — it owns the wrapper.

Point at each cell: where did we derive this? This table is the framework students carry into Act 3.

T17 verbatim. The summary sentence, asserted in L6, derived today.

Bridge to the Mystery Board. Quick consolidation before the closing ceremony.

60 seconds in pairs. This is mystery 8 — the one left open since Act 1. Let them assemble the answer from the token-sequence mechanism before you show the four factors.

The emotional climax of Act 2. Take a beat. The token sequence is the only input the model has — same model under different orchestration is processing different sequences.

Walk each row quickly. Eleven mysteries, eleven mechanisms, zero appeals to magic. The fourth column is a compressed index of Act 2 itself.

In the room, this is the closing ceremony. Each student articulates one sentence: 'I experienced X in Act 1; now I understand it because Y.' If you can say it without hand-waving, the act has done its job.

No magic does not mean no open questions. The claim is narrower: no question of the form 'why did the tool do that?' needs an appeal to mystery. And the no-magic reach extends past the eleven, to questions the board never thought to ask.

Explanation is finished when the mechanism is named. Engineering wants budgets turned into policies and 'it seems better' upgraded to a number.

Preview of Act 3. SWE-bench named per L6's promise.

One compact frame. The exercises run outside the theory deck — do NOT expand into full worksheets; the lab instructions live separately. In the room, these come BEFORE the ceremony.

Act 2 ends here. The board is empty, and it stays empty. Next week: Act 3 opens with "how do we know what these systems can do?"