What you will be able to do
- Recognise the symptoms of context degradation in a long exploration session
- Use scratchpad files so key findings survive context resets and compaction
- Run /compact with focus instructions and know what survives it
- Spawn subagents for specific exploration questions so verbose output stays out of the coordinator's context, and brief each new phase with a summary of the last
- Design crash recovery where each agent exports state to a known location and the coordinator loads a manifest on resume and injects it into agent prompts
Key concept
Context degradation (context rot) — The more tokens an exploration session piles into the context window, the worse the model gets at recalling specific facts from it. Everything else in this lesson is about keeping the working context small while keeping hold of the facts that matter.
1.What degradation looks like in a long exploration
Exploring a large codebase is mostly reading: grep results, directory listings, whole files, test output. Every one of those tool results stays in the conversation and is paid for again on each later turn. The compaction docs name the consequence directly: response quality degrades as a conversation grows. The context engineering cookbook calls the effect context rot. Needle-in-a-haystack studies showed that recall of information already in the window gets worse as the token count climbs.
The exam guide describes how this shows up in practice. Early in a session the agent finds concrete facts: a class called RefundService, the module that owns currency rounding, the exact config key for retries. Hours of discovery output later, you ask a follow-up and the answers start to drift. They become inconsistent with earlier answers, and the agent starts describing "typical patterns" for a service like this instead of naming the specific classes it found. The facts are still somewhere in the transcript. The model just isn't recalling them reliably from under all that noise.
This matters for exam scenarios because the symptom does not wait for the hard limit. The cookbook stresses that even before the hard context limit is reached, the agent may be getting less out of each token. It frames the discipline as finding the smallest set of high-signal tokens that gets the outcome you want. So the fix is never "use a bigger window". The fix is to get the discoveries out of the noisy transcript and into somewhere small and durable, and to keep the noise out in the first place.
2.Scratchpad files: findings that live outside the window
The first fix protects the facts. The cookbook calls it memory, or structured note-taking: the agent regularly writes notes persisted outside the context window, then pulls them back in at later times. For codebase exploration that means a scratchpad file, for example exploration-notes.md, where the agent records each key finding as it lands. Record class names, file paths, the call chain it traced, and exact values like a timeout or a feature flag name.
The file only helps if the agent actually goes back to it. When the next question comes in ("which of those classes touches the ledger?"), the agent reads its scratchpad first and answers from the recorded facts, not from its recall of a long transcript. That is what counters degradation. A few hundred tokens of precise notes are high-signal. Tens of thousands of tokens of old grep output are not.
Make this a standing instruction rather than a hope: have every agent in the exploration maintain a scratchpad file recording its key findings, and have it reference that scratchpad for each subsequent question before it searches or answers. The cookbook describes the payoff: the agent tracks progress across complex tasks, maintaining critical context that would otherwise be lost across dozens of tool calls or across context resets. Writing findings down as they land and reading them back on every later question is how agents counteract context degradation in a long session.
Scratchpads also survive the events that wipe conversational memory. The cookbook says that after a reset (a new session, or after compaction), the agent reads its own notes and continues. Claude Code's own context-window docs show the same property for its built-in memory: after /compact, auto memory and the project-root CLAUDE.md are re-injected from disk. The conversation itself only comes back as a summary. Whatever is on disk comes back exactly as written. Whatever lived only in the conversation comes back as someone else's paraphrase.
3./compact: reclaim space without losing the thread
The second fix removes the noise. In Claude Code, you run /compact, which replaces the conversation with a structured summary. Use /compact to reduce context usage during an extended exploration session, at the point where the context has filled with verbose discovery output (grep hits, directory listings, file dumps) that you won't read again. The cookbook describes compaction as keeping architectural decisions, unresolved questions and key facts while dropping redundant content. It also warns that compaction is lossy by design: overly aggressive compaction can lose subtle but critical context whose importance only becomes apparent later.
You steer what the summary keeps. Run /compact with instructions, like /compact focus on the auth bug fix, before starting a long new task. In the docs' words, the summary keeps what you choose instead of what the automatic pass guesses is important. In an exploration session, that means naming the subsystem you are still investigating so its findings get priority in the summary. For related situations the docs offer /clear when switching to unrelated work, and /autocompact to set how full the window gets before the automatic pass runs.
| Mechanism | After compaction |
|---|---|
| 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 |
| Files Claude read or edited | Claude Code re-reads up to five, most recently modified first |
| Background commands and background subagents | Keep running |
| Context that hooks added earlier | Summarized with the rest of the conversation |
Content loaded from disk (CLAUDE.md, auto memory, the plan file) is re-injected intact, and only up to five recently modified files are re-read. Everything else, including dozens of explored files and the facts the agent pulled from them, survives only as far as the summary keeps it. A finding in a scratchpad file can be read back exactly. A finding that exists only in the transcript is at the mercy of the summary.
An architect has been running a single Claude Code session for several hours exploring a large monorepo. Early on, the agent correctly identified that OrderService extends a custom TransactionalBase class with a distinctive retry mechanism. Hours later, asked about OrderService again, the agent describes it as 'typically extending a standard base controller with default error handling,' ignoring its earlier finding. What should the architect do going forward to prevent this?
Correct answer: A — Have the agent record concrete findings, such as exact class names, in a scratchpad file and consult it before answering.
- A. Correct. Persisting exact findings to a scratchpad file gives the agent a durable, specific anchor that survives context degradation, so later answers stay grounded in what was actually discovered.
- B. Incorrect. Output token limits control response length, not whether earlier findings remain salient in context, so raising this limit does not address degradation.
- C. Incorrect. Model size does not restore recall of facts diluted across a long context window; the problem is context management, not raw model capability.
- D. Incorrect. Re-reading the whole repository for every follow-up is expensive and does not build a durable record the agent can reliably reference for the rest of the session.
4.Subagent delegation: keep verbose exploration out of the coordinator
Compaction cleans up noise after it has landed. Subagent delegation keeps it from landing in the first place. The Agent SDK docs describe the context isolation: each subagent runs in its own conversation, its intermediate tool calls and results stay inside the subagent, and only its final message returns to the parent. A research subagent can explore dozens of files, and the parent receives a concise summary, not every file the subagent read. Claude Code's context-window docs give the same advice in one line: delegate large reads so the file contents stay in the subagent's context window, not yours.
That splits the work into two roles. The main agent acts as coordinator and preserves the high-level understanding: which subsystems exist, what has been established, what is still open. The verbose exploration output goes to subagents. Spawn each one to investigate a specific question, such as "find all test files" or "trace refund flow dependencies", and have it return a short answer with the class names and file paths it found. Claude Code's built-in Explore subagent exists for exactly this: its purpose is file discovery, code search and codebase exploration, with read-only tools. Independent questions can run as parallel subagents, finishing in the time of the slowest one rather than the sum of all of them.
Exploration usually runs in phases: map the modules, then trace specific flows, then check the tests around them. Before spawning the sub-agents for the next phase, summarize the key findings from the phase that just finished, ideally straight from the scratchpad, and inject that summary into each new subagent's initial context through its prompt. A standard subagent starts fresh in its own conversation, so it does not see what the coordinator learned earlier. Without the summary it rediscovers the same ground, or contradicts it. With the summary it starts phase two already knowing that refunds go through RefundService.
The file reads, grep output and dead ends stay in the subagent's own context window. Only the subagent's final summary, with the specific classes and paths, comes back to the coordinator. The coordinator's context stays small and high-signal, so it keeps recalling the specific findings instead of generalising.
5.Crash recovery: state exports and a manifest the coordinator loads on resume
A multi-agent exploration can die halfway: a crash, a killed terminal, a session that times out. What survives is only what was written to disk. The exam guide's answer is structured state persistence. Each agent exports its state to a known location, for example exploration-state/refund-tracer.json, holding the question it was given, the findings so far, the files already covered and the questions still open. The coordinator keeps a manifest, such as exploration-state/manifest.json, that lists every agent, the path of its state export and whether it finished.
On resume, the coordinator loads the manifest first. Finished agents need no rerun: their exported findings are already on disk. For each unfinished agent, the coordinator reads its state export and injects it into the prompt of the agent it spawns to continue the work. That injection step is the part that is easy to miss. A new subagent starts fresh in its own conversation, so it knows nothing of the crashed run unless its prompt carries the exported state. This is the same idea the cookbook describes for memory: notes persisted outside the context window let an agent keep critical context that would otherwise be lost across context resets. You implement the storage, so you decide what the export contains.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Context degradation only matters once the session hits the context window's hard limit, so a larger window solves it.Why is that wrong?
Recall worsens as tokens accumulate, well before the limit. The fix is fewer, higher-signal tokens, not more room.
Covered in What degradation looks like in a long exploration
2.A plain /compact reliably keeps every important fact, so exact values found during exploration are safe once the summary is written.Why is that wrong?
Compaction is lossy. Steer it with focus instructions, and write exact values to a file first so they come back from disk, not from the summary.
Covered in /compact: reclaim space without losing the thread
3.The coordinator should read every file itself during exploration, because a subagent's summary loses detail the coordinator needs.Why is that wrong?
Reading everything in the coordinator floods its context and causes the degradation you are trying to avoid. Delegate specific questions and have subagents return the specific classes and paths.
Covered in Subagent delegation: keep verbose exploration out of the coordinator
4.After a crash, a re-spawned subagent can pick up where the old one stopped without being told anything, because the work was done in the same project.Why is that wrong?
A subagent starts fresh. The coordinator must load the manifest and inject the agent's exported state into the new agent's prompt.
Covered in Crash recovery: state exports and a manifest the coordinator loads on resume
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“it keeps the active context small, because response quality degrades as a conversation grows.”
↩︎ What degradation looks like in a long exploration - 2.https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-toolsSecondary source
“as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases.”
↩︎ What degradation looks like in a long exploration“even before the hard context limit is reached, the agent may be getting less out of each token.”
↩︎ What degradation looks like in a long exploration“the agent regularly writes notes persisted outside the context window, then pulls them back in at later times.”
↩︎ Scratchpad files: findings that live outside the window“the agent tracks progress across complex tasks, maintaining critical context that would otherwise be lost across dozens of tool calls or across context resets.”
↩︎ Scratchpad files: findings that live outside the window“After a reset (a new session, or after compaction), the agent reads its own notes and continues.”
↩︎ Scratchpad files: findings that live outside the window“overly aggressive compaction can lose subtle but critical context whose importance only becomes apparent later.”
↩︎ /compact: reclaim space without losing the thread“You implement the storage backend, so you control what's stored and for how long.”
↩︎ Crash recovery: state exports and a manifest the coordinator loads on resume“as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases.”
↩︎ Key concept“even before the hard context limit is reached, the agent may be getting less out of each token.”
↩︎ Exam trap 1 - 3.https://code.claude.com/docs/en/context-windowOfficial docs
“Re-injected from disk”
↩︎ Scratchpad files: findings that live outside the window“you run /compact, which replaces the conversation with a structured summary.”
↩︎ /compact: reclaim space without losing the thread“run /compact with instructions, like /compact focus on the auth bug fix, before starting a long new task.”
↩︎ /compact: reclaim space without losing the thread“Delegate large reads: send research to a subagent so the file contents stay in its context window, not yours.”
↩︎ Subagent delegation: keep verbose exploration out of the coordinator“The summary keeps what you choose instead of what the automatic pass guesses is important.”
↩︎ Exam trap 2 - 4.https://code.claude.com/docs/en/agent-sdk/subagentsOfficial docs
“intermediate tool calls and results stay inside the subagent; only its final message returns to the parent.”
↩︎ Subagent delegation: keep verbose exploration out of the coordinator“The parent receives a concise summary, not every file the subagent read.”
↩︎ Subagent delegation: keep verbose exploration out of the coordinator“multiple subagents can run concurrently, so independent subtasks finish in the time of the slowest one rather than the sum of all of them.”
↩︎ Subagent delegation: keep verbose exploration out of the coordinator“each subagent runs in its own conversation, which starts fresh unless the subagent is a fork.”
↩︎ Crash recovery: state exports and a manifest the coordinator loads on resume“The parent receives a concise summary, not every file the subagent read.”
↩︎ Exam trap 3“each subagent runs in its own conversation, which starts fresh unless the subagent is a fork.”
↩︎ Exam trap 4 - 5.https://code.claude.com/docs/en/sub-agentsOfficial docs
“Purpose: file discovery, code search, codebase exploration”
↩︎ Subagent delegation: keep verbose exploration out of the coordinator - 6.https://code.claude.com/docs/en/agentsOfficial docs
“A side task would flood your main conversation with search results, logs, or file contents you won’t reference again”
↩︎ Subagent delegation: keep verbose exploration out of the coordinator“Subagents report results back to the conversation that spawned them”
↩︎ Crash recovery: state exports and a manifest the coordinator loads on resume