D5 TS 5.1 · 5.2 · 5.3 · 5.4 · 5.5 · 5.6 · ~6 hrs · Skip to quiz →
A subagent finishes a task that involved reading forty files. What comes back into your main session?
Only the report. A subagent gets its own context window, does its reading there, and hands back a summary. This module is about why that separation matters more the longer a session runs.
A retry cannot fix one kind of extraction failure. Which?
Information that was never there. A retry fixes what the model got wrong about information it has; it cannot conjure a date the note never stated. Hold that idea. This module applies it to summaries, sources, and confidence scores.
▶ Watch: one session fills, rots, and recovers · 3 min
A model advertises a context window of one million tokens. You have a 300,000 token session going. Is the model reading your session as well as it read the first 30,000 tokens?
No. Recall degrades as the window fills, well before the limit. The window is a capacity, and the model's attention is a budget spent across it.
First, the words. The context window is everything the model can see when it produces its next response: the system prompt, your instruction files, the conversation so far, every tool call and every result, every file it read. A token is the unit that window is measured in, roughly three quarters of a word in English. Claude Code starts every session by loading a good deal into that window before you type anything: the system prompt, your project's CLAUDE.md, auto memory, the list of available tools and skills, environment details. Then your prompt lands on top, and every file Claude reads and every command result piles on after it.
The industry has a name for the limit that matters, and it is a different limit from the window size. Anthropic's context engineering guidance calls it the attention budget: the model has a finite amount of attention to spread across whatever is in the window, and as the window fills, the share each token gets shrinks. The guidance puts the goal in one sentence: find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome. Treat context as a precious, finite resource.
The degradation that follows has a name too: context rot. Output quality gets worse as the input gets longer, even when the window is nowhere near full.
Flagged as field experience: Chroma's 2025 technical report tested 18 frontier models and found every one of them exhibited context rot. Three findings are worth carrying around. First, one distractor (a passage on the same topic that does not answer the question) measurably hurt accuracy, and the damage grew with input length. Second, the models did better on shuffled text than on logically coherent text, because coherent prose produces more plausible-looking distractors. Third, the older "lost in the middle" result held: facts at the start and end of a long input get found; facts in the middle get skipped. A practitioner who teaches agentic engineering full time, IndyDevDan, states the same idea as a rule for the user's chair: the context window is the agent's most precious resource, and the two moves are reduce what goes in and delegate what does not need to be in your window at all.
What this changes from your chair: you stop treating a long session as a single container you keep adding to, and start treating it as a budget with four levers. Anthropic names them, and the rest of this module walks each one:
| Lever | What it does | Where it shows up in Claude Code |
|---|---|---|
| Compaction | Summarizes the conversation and starts again from the summary | /compact, automatic compaction near the limit |
| Structured note-taking | Writes findings to a file outside the window, reads them back later | A scratchpad file, a progress file, auto memory |
| Subagents | Give noisy work its own window; only the result comes back | The Agent tool, custom agent definitions |
| Just-in-time retrieval | Keep a pointer (a path, a query) and load the content only when needed | Reading a file when it matters instead of at the start |
One number to hold onto: Claude Code's own documentation says a CLAUDE.md should stay under 200 lines, because longer files consume more context and reduce adherence. That is the attention budget stated as a house rule.
Why a consultant needs this: every long working session you run is a context budget being spent. When the answers start getting vaguer at 4pm than they were at 10am, that is context rot, and the fix is one of the four levers, never "try harder."
Your session has been open all day and Claude just described a class it read this morning in vague, general terms. Which lever is the cheapest first move?
Compact with a focus. A bigger window buys time and no attention; asking again spends more budget on the same rot. The focused compact keeps the current thread and drops the noise, and the sections that follow show what survives it.
At 2pm your session compacts itself. At 2:10pm you ask Claude what refund amount the customer stated, and it answers "a partial refund." At 11am the number was $412.50. Where did the number go?
Into a summary. Compaction condensed the conversation, and "$412.50" became "a partial refund." Numbers, dates, and stated expectations are the first casualties of summarization, so they get carried outside the summary, in a facts block or a file.
Compaction is the first lever and the one Claude Code runs on its own. When the window nears its limit, Claude Code summarizes the conversation and replaces the history with the summary. The official description is honest about the cost: the summary is lossy, and bad compacts happen when the model cannot predict where your work is going.
The documentation publishes exactly what happens to each kind of content when a session compacts. This table is exam material and daily-life material at once:
| What was in the window | After compaction |
|---|---|
| The system prompt | Unchanged; it was never part of the history |
| Project-root CLAUDE.md and unscoped rules | Re-injected from disk |
| Auto memory | Re-injected from disk |
| The plan Claude wrote in plan mode | Re-injected from disk |
Rules with a paths: scope, nested CLAUDE.md files in subfolders | Reloaded only when Claude next reads a file they apply to |
| Files Claude read or edited | Up to five re-read, most recently modified first |
| Skills you invoked | Their bodies re-injected, capped at 5,000 tokens per skill and 25,000 in total; the oldest drop first |
| The skill listing | Not reloaded |
| Everything you said only in conversation | In the summary, or gone |
Read the last row twice. An instruction you typed at 9am ("always write dates as YYYY-MM-DD") lives only in the conversation. After compaction it survives only if the summary happened to keep it. The memory docs say it plainly: if an instruction disappeared after compaction, it was given only in conversation. Add it to CLAUDE.md to make it persist.
The exam's version of this problem is a support agent handling a long case. The knowledge statements name the failure: progressive summarization condenses numerical values, percentages, dates, and customer-stated expectations into vague summaries. The skill they want is extracting transactional facts (amounts, dates, order numbers, statuses) into a persistent case facts block: a short, structured list of the facts of the case, kept as its own piece of text and included in every prompt, outside the summarized history. The number lives in a structure that never gets summarized, and the summary can be as lossy as it likes.
The same statement names two more drains on the budget:
Two more points from the same statement, both labeled exam material because your teammates will meet them only through a system someone else built. First, when a session covers several issues at once (a customer with a billing dispute and a return in the same conversation), each issue gets its own facts block, so the $412.50 refund never gets attached to the wrong order. Second, at the API level, the platform keeps no memory between requests: every request must carry the complete conversation history it wants the model to see. Claude Code does that carrying for you inside a session; a program built on the API has to do it itself, and a program that drops history to save tokens loses coherence in exactly the way this section describes.
From your chair, four habits cover the task statement:
/compact focus on the refund case; drop the earlier report formatting discussion. The summary keeps what you chose instead of what the automatic pass guessed. The docs also let you compact a slice: /rewind, pick a message, "Summarize from here." And /autocompact 500k sets how full the window gets before the automatic pass runs./clear when you switch work. The docs' rule is one line: when you start a new task, start a new session. Old conversation crowds out the files you need next and costs tokens on every message.> before we go further, write the facts of this case to case-facts.md:
order number, amounts, every date, and what the customer said they
expect. keep it updated as we learn more. read it back before each
answer.Flagged as field experience: the 1 million token window that Fable 5, Sonnet 5, Opus 4.6 and later, and Sonnet 4.6 support has not retired any of this. Practitioners who run long sessions report the same shape at 1M as at 200K: the automatic compaction arrives later, and context rot arrives earlier than the compaction does. A bigger window buys time. It buys no attention.
A support session has handled a return and a billing dispute for the same customer. Where do the two order numbers and amounts belong?
Two blocks, one per issue. A single summary is where the $412.50 gets attached to the wrong order. Structured facts outside the summarized history survive compaction and stay attached to the right case.
A customer writes "this is ridiculous, I want a human." The agent can see the issue is a simple address correction it could fix in one step. What does it do?
It escalates. Now. An explicit request for a human is honored immediately, before any investigation, however easy the fix looks.
Escalation means the system stops acting on its own and hands the decision to a person. Ambiguity resolution means the system asks a clarifying question instead of guessing. The exam treats both as design decisions you write into the agent's instructions, and it is specific about which triggers count.
Three triggers that should escalate:
Flagged as field experience: ICLR 2026 papers on verbalized confidence find that when a model is asked how sure it is, the number it produces is poorly calibrated by default, and good calibration is usually incidental. Training rewards the confident sounding sequence. So an escalation rule keyed to "confidence below 70 percent" is a rule keyed to a number nobody has checked. A separate 2025 paper on multi-agent systems, AgentAsk, found that adding a small clarification step at the handoffs between agents (ask before you pass along something unclear) cut cascading errors at under 10 percent extra cost. Asking is cheap. Guessing compounds.
In your chair, escalation has two everyday forms, and you have used both already. Plan mode is Claude asking before it acts: it explores, writes a plan, and waits for your approval. Clarifying questions are Claude asking before it assumes: when a request has two reasonable readings, it presents the options and waits. Both are the agent choosing to ask over guessing, and both get better when you tell Claude what counts as ambiguous for your work:
> when a request could mean two different things, or when a lookup finds
more than one match, stop and ask me which one. never pick by guessing.
put this in CLAUDE.md.The skill the exam names is writing explicit escalation criteria into the system prompt with few-shot examples: two or three short cases showing "this escalates, this resolves, this asks." The same move you learned for output formats works for judgment.
A customer asks for a price match against a competitor. The policy document covers price adjustments on the company's own site and says nothing about competitors. The agent should:
Escalate. A policy gap is a trigger in its own right, separate from case complexity. Applying the nearest rule is a guess with a refund attached; declining invents a policy that does not exist. A person decides.
A research subagent reports back "search unavailable." The coordinator now has to decide: retry, try another source, or report a gap. Which should it do?
It cannot tell. "Search unavailable" says nothing about whether the search timed out, returned nothing, or was refused. The coordinator needs the failure type, what was attempted, any partial results, and an alternative. Errors carry their story or they are useless.
Words first. A coordinator is the agent that plans the work and hands pieces to others; a worker (or subagent) is the agent that does one piece in its own context window and reports back. Error propagation is what happens to a failure as it travels from the worker to the coordinator: it either arrives with enough context for a good decision, or it arrives as a status code and forces a guess.
Three workers, three outcomes, one coordinator deciding what to do next:
The exam's knowledge statements draw two distinctions and name two anti-patterns.
The design the exam wants, stated as worker rules:
| The worker should | Example |
|---|---|
| Recover locally from transient failures | Retry a timeout twice with a short wait before reporting it |
| Propagate only what it cannot resolve, with its story | { type: "access_failure", attempted: "search 'prior auth' in policies/", partial: "3 of 7 folders read", alternative: "try the archived policies folder" } |
| Distinguish empty from failed | { type: "empty_result", attempted: ..., matches: 0 } |
| Annotate coverage in synthesis | "Well supported: A, B. Gap: topic C, source unavailable" |
Flagged as field experience: a 2025 arXiv paper on why multi-agent systems fail gives the handoff failures names that travel well: a Data Gap (the worker was never given what it needed), Signal Corruption (what it was given got mangled), Referential Drift (it answered a slightly different question than the one asked), and a Capability Gap (it was asked for something it cannot do). Empirical failure rates on benchmarks run from roughly 41 to 87 percent, mostly from coordination rather than from any one agent being weak. A separate 2026 case study of agentic scientific workflows found the dominant failure was the quiet one: syntactically valid work that produced plausible, wrong results with no error signal at all. Silence is the failure mode to design against.
From your chair, this is a rule you write into your agent definitions once:
> update every agent in the agents folder with a reporting rule: when
something fails, say what kind of failure (timed out, refused, empty
result, could not parse), exactly what you tried, whatever you did
manage to get, and one thing to try next. never report an empty
result as if it were a failure, and never report a failure as if it
were an empty result.Then your coordinator, which is your main session, can make the call the exam describes: retry the access failures, accept the empty results, and mark the gaps in the final synthesis instead of papering over them.
Six research workers run. One times out. What should happen to the run?
Retry, then synthesize with the gap annotated. Stopping wastes five good sources (anti-pattern two). Treating the timeout as an empty result hides the hole (anti-pattern one). The coverage annotation is what lets a reader know which topic is thin and why.
Day one exploring an unfamiliar codebase, Claude names the exact class that validates claims. Day two, same session, it says "the validation layer typically handles that." What happened between the two answers?
Context rot. The specific finding sat in a window that grew all day, and the model fell back on typical patterns instead of the specific class it had read. The fix is the four levers: delegate the reading, write the findings down, summarize between phases, compact with a focus.
The exam's fourth statement names the symptom exactly: in extended sessions, models start giving inconsistent answers and referencing "typical patterns" rather than specific classes discovered earlier. Every remedy it lists is one of the levers from the attention budget, applied to a codebase.
Delegate the reading. A subagent gets its own fresh context window. It can read forty files, and only its report comes back to you. The Claude Code docs recommend exactly this for investigation: run exploration in a subagent so file reads stay out of the main conversation. The exam's examples are precise questions, and precise questions produce short reports:
> use a subagent to find every test file in this repo and report back
the list with one line each on what it covers. do the reading in the
subagent; i only want the list.> use a subagent to trace the refund flow from the API endpoint to the
database write, and report the file and function at each hop.Write the findings down. A scratchpad file is a file in the repo where key findings get recorded as they are discovered, and consulted before later questions. It is structured note-taking, the second lever. The exam's skill statement: have agents maintain scratchpad files recording key findings, referencing them for subsequent questions to counteract context degradation. Ask for it at the start, before the window is full:
> as you explore, keep a file called findings.md: one line per thing you
learn, with the file path it came from. before answering any question
about the codebase, read findings.md first.Summarize between phases. When phase one (map the modules) ends and phase two (trace the data flow) begins, have the summary of phase one written to the file and injected into the prompt for phase two's subagents. The exam calls this summarizing key findings from one exploration phase before spawning subagents for the next.
Plan for the crash. The fourth skill statement is structured state persistence for crash recovery: each agent exports its state to a known location, and the coordinator loads a manifest (an index of what was done and where each result lives) on resume, injecting it into agent prompts. In a second brain, that manifest is a progress file.
Flagged as field experience: Anthropic's own engineering write-up on long-running agents describes the same design in production. Each session starts by reading a progress file and the git log, then verifies the app still runs before touching anything. Each session ends by committing with a descriptive message and updating the progress file. Git becomes the memory that survives any single context window, and the progress file is the manifest. The write-up also reports the failure the ritual prevents: without explicit instruction, the model tended to mark features complete without proper testing.
A teammate asks: "Why does a findings file help? Claude already read those files this morning." Answer in two sentences, out loud or in the box, then compare.
Something like: "What Claude read this morning is still in the window, but by afternoon it is buried under everything read since, and the model's attention is spread across all of it. A findings file sits outside the window, never gets summarized, and gets read back fresh before each answer, so the specific fact is at the top of the pile every time."
Configure the repo so less loads in the first place. The large codebase docs add three settings, all of which are asks you can make once:
| Setting | What it does | Ask Claude |
|---|---|---|
| Per-folder CLAUDE.md | Loads a subfolder's conventions only when Claude reads files there | "add a CLAUDE.md inside the claims folder with just its conventions" |
claudeMdExcludes | Skips CLAUDE.md files for areas you never work in | "exclude the legacy folder's instructions from loading" |
| Where you start Claude | Starting in a subfolder loads that folder's instructions plus its parents, and nothing from sibling folders | Open the terminal in the subfolder before typing claude |
And the lever you already know: /compact with a focus when the window has filled with verbose discovery output. The docs note that the plan file written in plan mode is re-injected after compaction, so a long cross-package session keeps its plan even when the conversation history has been summarized.
Phase one mapped the modules of a large codebase. Phase two will trace the data flow with new subagents. What should happen between the phases?
Summarize and inject. Subagents start with fresh windows and cannot see your conversation, so the findings have to be handed to them. A clean window with no notes throws away the morning's work; the scratchpad is what makes a clean window safe.
An extraction pipeline reports 97 percent accuracy overall. Leadership wants to stop human review on high-confidence extractions. What do you check before saying yes?
Accuracy by document type and by field. A 97 percent overall figure can hide a document type running at 60 percent, and a single field that is wrong half the time. Nothing gets automated until every segment has been measured.
Confidence calibration means checking whether a confidence score means what it says: when the model reports 90 percent, is it right about 90 percent of the time? Human review workflow means deciding which outputs a person looks at, given that a person cannot look at all of them. The exam's fifth statement ties them together for a document extraction system, and the knowledge statements are a checklist:
Flagged as field experience: Andrew Ng's position, repeated across his 2025 and 2026 agentic AI teaching, is that the single biggest predictor of a team's progress on agents is a disciplined process for evals (measuring the system) and error analysis (looking at the failures one by one and counting which step caused them). His starting advice is small: look at the outputs, spot the recurring mistakes, then design a metric to track them. McKinsey's 2025 writing on agentic AI describes credit workflows where agent confidence scores exist to prioritize human review, which is exactly item 4. And Gartner's 2025 forecast, that over 40 percent of agentic AI projects will be cancelled by 2027, cites insufficient risk controls among the causes. The review workflow is the risk control.
One caution: the confidence score the model writes is text it generated, checked against nothing. It becomes a calibrated number only after step 3, when it has been compared with labeled data. Until then, "route the low-confidence ones to review" routes by a guess about a guess.
From your chair, the everyday form is a sampling ask on any batch job:
> before i trust the extraction, pull a random sample of 20 rows from
each document type, show me the source passage next to each extracted
value, and tell me the error rate per type and per field. flag any
type where a field is wrong more than one time in ten.That prompt is stratified sampling, per-segment accuracy, and a routing threshold in four lines. The answer to "why would I need this" is that the 97 percent will be quoted to a client, and the 60 percent will be found by the client.
Two credible reports give different figures for the same statistic. The synthesis agent picks the higher one and moves on. A week later the client asks where it came from. What went wrong, and when?
Two things, both before the report was written. The conflict was resolved by a guess instead of being annotated with both sources. And the source attribution was lost somewhere in summarization, so nobody can answer the client.
Provenance is the record of where a piece of information came from: the source document, the location within it, the date it was published or collected. In a multi-agent research system, provenance dies in a specific place: when a worker's findings get summarized on the way to the coordinator, the claim survives and its source does not. The exam's sixth statement is about keeping the mapping alive.
| Problem | The design |
|---|---|
| Source attribution is lost during summarization | Workers output a claim-source mapping (source URL or document name, the relevant excerpt) and downstream agents preserve and merge it |
| Conflicting statistics from credible sources | Annotate the conflict with both sources. Never pick one. Let the coordinator decide how to reconcile before synthesis |
| Temporal differences read as contradictions | Require publication or collection dates in structured outputs, so a 2023 figure and a 2026 figure are recognized as a change over time |
| Findings all read as equally solid | Structure the report with sections that separate well-established findings from contested ones, preserving each source's own characterization and method |
| Everything flattened to one format | Render each content type appropriately: financial data as tables, news as prose, technical findings as structured lists |
Flagged as field experience: Anthropic's write-up of its multi-agent Research system describes the production version of this problem and its fix. By the time the final report was drafted, source URLs had been condensed and re-summarized through several subagent returns. So the system added a separate agent whose only job is citations: it reads the raw sources and the final report together and checks each claim against the actual document rather than against the lead agent's memory of it. Provenance was recovered by giving it its own worker with its own window. Community writing has started calling the wider practice "graph engineering," treating entities and their relationships as a context strategy of their own; that phrase is community vocabulary, and the exam does not use it.
From your chair, provenance is one instruction to any research subagent, and one instruction to the synthesis:
> for every claim you report, include the source document name, the
exact excerpt, and the document's date. if two sources disagree on a
number, report both with their sources and dates; do not choose.> write the synthesis in two sections: "well supported" for claims with
two or more sources that agree, and "contested or single-source" for
the rest. keep every source next to its claim. financial figures go in
a table, everything else in prose.The consultant's reason is the one from the question above: a week later someone asks where the number came from. With the mapping preserved, the answer is a document name and a date. Without it, the answer is a shrug with the firm's name on it.
A 2023 spec says the filing window is 90 days. The current code says 180. A worker reports both. What should the synthesis do?
Carry both, dated. The dates turn a contradiction into a story (the code is newer than the spec), and the coordinator, or the client, confirms which is live. Picking one is a guess that looks like a finding.
A consultant spends day one getting specific answers from a 1,400 file codebase: file names, function names, exact rules. Day two, the same session, the same kind of question gets a vague one. What changed?
Nothing in the codebase. The session had spent all day reading and answering, and by day two its attention was spread across everything it had read instead of the one fact that mattered. What the team changed is the case study below.
The five consultant team at the regional health plan was handed a codebase nobody on the client side could explain. The claims intake system was eleven years old, some 1,400 files, and the two engineers who built it had left. The team's job was a current-state assessment in three weeks: what the system does, where the risk sits, what a modernization would have to preserve.
Day one was good. One consultant opened a session in the repo and started asking. Where does a claim enter? Which class validates it? What happens on a rejection? The answers were specific: file names, function names, the exact rule that rejected a claim with a missing provider ID. By the end of the day the session held roughly 180 files' worth of reading and a long, useful conversation.
Day two was the problem. The same session, resumed. The consultant asked which class applied the timely-filing rule, a question the session had answered the day before. The answer came back: "the validation layer typically handles timely filing through a rules engine." No file name. No function. A typical pattern, offered in place of a specific class the model had read twenty hours earlier. Two more questions went the same way. The session was compacting under its own weight, and the summaries had kept the shape of the findings and lost the facts.
The fix took one morning, and nobody touched the codebase. The team changed three things: where the reading happened, where the findings lived, and how a session started.
findings.md, one line per fact with the path it came from. Every subagent appended to it. Every question started with reading it. Dates went on every line, because the codebase had two generations of validation code and the team needed to know which was live.progress.md: what was mapped, what was next, which subagent reports existed and where. Each morning began with "read progress.md and findings.md, then tell me where we are." Each evening ended with "update progress.md with what we learned and what is next." When a session compacted, those two files were re-read from disk, and the numbers survived because they were never in the summary to begin with.Replay the day-two question through both worlds.
| "Which class applies the timely-filing rule?" | |
|---|---|
| Before (one long session, day two) | "The validation layer typically handles timely filing through a rules engine." No file. No function. |
| After (subagent, findings file) | "Enforced in intake/rules/TimelyFilingRule.java, 180 days from date of service, with a hardcoded exception list for three payer codes." |
The consultant reads the line in findings.md and asks the next question. The hardcoded exception list, which nobody at the client knew existed, became the first item in the risk section of the assessment.
The near miss. In week two, a subagent tracing the appeals flow reported "no appeals handling found." The consultant nearly wrote "appeals are handled outside this system" into the assessment. Then the reporting rule the team had added to every agent kicked in on the rerun: the subagent's report distinguished the two cases the exam distinguishes. The appeals folder existed; the subagent's read of it had timed out on a 9,000 line file. Access failure, with the attempted path and the partial result attached.
The retry, with the big file read in two halves, found the appeals handler and a second undocumented exception list. Play forward the version where "no appeals handling found" shipped: the modernization scope excludes appeals, the vendor bids on that scope, and the missing module is discovered in build. The reporting rule cost one sentence in each agent definition.
Week three, Thursday. The assessment is due Friday. A subagent reports the filing window as 90 days from the 2023 spec; findings.md says 180 days from the code, dated last November. A teammate says: "Go with the code. Code is what runs." Pick your move, then read what follows from it. Try all three.
What the working practice looks like now. Every exploration question goes to a subagent. Every finding lands in findings.md with a path and a date. Every session opens by reading the progress file and closes by updating it. Every agent reports failures with their type, what it tried, and what it got. When two documents disagreed on the timely-filing window, the synthesis carried both with their dates, and the client confirmed the spec was obsolete. The assessment shipped on time with a risk section the client had not known it needed.
▶ Watch the demo: the legacy codebase assessment · 4 min
The prompt pack: every demo prompt, cleaned and explained
The demo runs the case study's practice on the client-project repo, from the user's chair, in three parts. Part one keeps the window lean: a findings file and a progress file are created with their read-and-update ritual, a subagent does the reading and only its report comes back, and a focused compaction proves the facts survive because they were in files. Part two makes failures speak: a reporting rule goes into the explorer agent, a timeout comes back as an access failure with its story, the retry finds the appeals handler, and a truly empty folder comes back as an empty result that nobody retries. Part three keeps the trail: a research subagent returns two disagreeing figures with sources and dates, the synthesis keeps them in a contested table, and a fresh session on Monday picks up exactly where the files say the work stands.
Then run the pack in your own repo. The prompt pack linked above holds every prompt from the demo, cleaned up and explained. Copied as is or rephrased in your own words, check what the demo checked as you go:
/compact with a focus, a specific question gets a specific answer, with the path, from findings.md.Take the Module 08 quiz → then hit the Study App for Domain 5 reps.