Your Scratchpad Vanished on Compaction: Persisting Agent State

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 52)

▶ Watch on YouTube & subscribe to The Stack Underflow

An agent runs long enough that its context window fills up. You compact — summarize the history, drop the raw transcript, free up room — because that’s the correct first lever for an overflowing window. The agent keeps going. And then it starts re-doing work it already finished, contradicting a decision it already made, or asking a question it already answered three steps ago. Nothing crashed. Compaction did exactly what it was supposed to do. The problem is that the agent’s own scratchpad — the running notes it was keeping about what it had tried, decided, and ruled out — lived only inside the context window, and compaction doesn’t know a scratchpad note from any other line of history. It got summarized or dropped along with everything else. This is the scenario Q9 of the Domain 5 practice set is built around, and it’s a distinction that trips up a lot of people who understand compaction in the abstract but haven’t drawn the line between “in the window” and “durable.”

The one-sentence version: A scratchpad kept only inside the context window is not memory — it’s a draft that compaction is free to discard; anything the agent must remember past a compaction boundary has to be written to storage that lives outside the window and gets explicitly read back in.

The question

Your agent’s scratchpad notes get lost when the context is compacted. Fix?

• A) Never compact
• B) Persist the scratchpad across the context boundary (external memory/state)
• C) A bigger window
• D) Repeat the notes every turn

Pause here and pick an answer before you scroll — the point of these practice questions is reasoning through the mechanism, not pattern-matching the letter.

The answer

The correct answer is B. The fix is to persist the scratchpad across the context boundary — write it to external memory or state that survives compaction, and re-read it back into the window on the turn that needs it. The mechanism underneath this is a simple but easy-to-miss distinction: a context window is volatile with respect to any operation that rewrites it, and compaction is exactly that kind of operation. It summarizes or discards the transcript to reclaim room. If the scratchpad’s only copy exists as text inside that transcript, it has no special protection — the compaction step has no way to know “this part is working memory the agent needs later” versus “this part is disposable back-and-forth.” Everything in the window is just tokens to a compaction step unless you’ve architected it otherwise.

The fix is to stop treating the in-context scratchpad as the source of truth and instead treat it as a cache of something durable. The actual scratchpad — the notes, the intermediate conclusions, the “already tried X, ruled out Y” ledger — gets written to a store that exists independently of the context window: a file, a key-value store, a database row, a memory API. That store survives the compaction event because compaction never touches it; compaction only rewrites what’s inside the window. On the next turn, the agent (or the harness wrapping it) reads the relevant slice of that external state back into the fresh, post-compaction window.

BEFORE COMPACTION                                  AFTER COMPACTION

┌─────────────────────────────┐                    ┌─────────────────────────────┐
│ CONTEXT WINDOW                │                   │ CONTEXT WINDOW (rebuilt)      │
│  system prompt                │                   │  system prompt                │
│  turn 1..40 raw history        │─ summarize ─────▶│  compacted summary of history │
│  scratchpad (in-context only) │  ✗ WIPED           │  (scratchpad notes: gone)     │
└─────────────────────────────┘   never written       └─────────────────────────────┘
                                    anywhere else

            ── vs ──                                                ── vs ──

┌─────────────────────────────┐                    ┌─────────────────────────────┐
│ CONTEXT WINDOW                │                   │ CONTEXT WINDOW (rebuilt)      │
│  system prompt                │                   │  system prompt                │
│  turn 1..40 raw history        │─ summarize ─────▶│  compacted summary of history │
│  scratchpad ── also written ──┼──┐                 │  scratchpad ── read back in  │
└─────────────────────────────┘  │                 └─────────────────────────────┘
                                    ▼                                ▲
                          ┌───────────────────┐                     │
                          │ EXTERNAL STORE      │  survives the      │
                          │ (file / db / kv /   │  compaction event ─┘
                          │  memory API)        │  untouched
                          └───────────────────┘

Rule to internalize: working state that must survive compaction lives in memory, not the window. The window is a scratch surface the agent draws on for the current turn; anything that needs to outlast a rewrite of that surface needs its own storage, plus explicit logic to write to it and explicit logic to read from it. Persistence isn’t automatic just because something was true a few turns ago.

Why the other options fail

• A) “Never compact.” This “fixes” the symptom by removing the mechanism that was working correctly. Compaction exists because the window is finite and a multi-step task will eventually overflow it — refusing to compact just trades a lost-scratchpad problem for a guaranteed hard overflow later in the same run. It also doesn’t address the actual defect, which is that the scratchpad has no durable home; the moment you introduce any compaction later, or hit a session boundary, or the process restarts, the same notes vanish again.
• C) “A bigger window.” A larger window buys more room before compaction becomes necessary, but it doesn’t change what happens the moment compaction (or a session restart) does occur. The scratchpad is still living only inside the window with no external copy — you’ve postponed the failure, not fixed the mechanism. Every sufficiently long-running agent eventually needs compaction or a new session regardless of window size, and an unpersisted scratchpad fails the same way at whatever point that happens.
• D) “Repeat the notes every turn.” Re-stating the scratchpad in every message keeps it near the “recent” end of the window, which sounds like it dodges the lost-in-the-middle problem — but it doesn’t solve durability, it just delays the failure and adds cost along the way. The notes still exist only inside the window; the next compaction event summarizes or drops them exactly as before, notes-repeated or not. It also burns tokens every single turn re-sending information that hasn’t changed, which is the same anti-pattern that prompt caching exists to fix for large stable blocks — except here it’s actively wasteful because the content keeps growing as the scratchpad accumulates more entries.

The concept behind it

This question is really about a distinction that recurs across Domain 5: context and state are not the same thing, and conflating them is where a lot of “my agent forgot” bug reports come from. Context is what’s currently loaded into the model’s window for this call — transient, rewritable, and subject to compaction, truncation, or a fresh session at any time. State is whatever the system needs to be true across calls, restarts, or compaction events, and it only survives if something explicitly wrote it somewhere durable and explicitly reads it back.

A useful mental test for any piece of information an agent is tracking: “if the window got rewritten right now, would this survive?” If the honest answer is “only if I re-typed it into the summary,” it isn’t state — it’s a draft, and drafts get discarded the moment something needs the room. The fix pattern generalizes past scratchpads specifically: tool-call results the agent will need three steps later, a running plan for a multi-step task, intermediate calculations, user preferences discovered mid-conversation — all of it is subject to the same rule. Decide up front which pieces of working state are load-bearing enough to need a durable home, write them there as they’re produced, and read them back explicitly rather than hoping they survive the next rewrite of the window.

This also reframes what “compaction” should mean architecturally. A good compaction step isn’t just “summarize and hope nothing important got cut” — it’s an explicit checkpoint where the agent (or the harness) flushes anything durable to external storage before the rewrite happens, so the compacted window can afford to be aggressive about what it drops. See The Task Overflowed the Window: Chunking and Decomposition for the mechanics of when and how to trigger that step in the first place. And because persisted state still has to be re-read into a finite window, it competes for the same budget as everything else — see 80% History, 20% Task: Budgeting the Context Window for how to keep recovered state from crowding out the current task.

The failure mode also rhymes with a reliability pattern elsewhere in Domain 5: a scratchpad silently wiped by compaction produces the same shape of bug as a subagent error silently swallowed by a coordinator — a system that keeps behaving confidently while quietly missing information it should have had. If that pattern interests you, see It Failed and Answered Confidently Anyway: Error Propagation in Agents.

FAQ

Is this the same thing as giving an agent “memory”? Yes, in the general sense — persisting a scratchpad outside the context window is one specific application of the broader pattern of external agent memory. The distinction worth keeping straight is scope: a persisted scratchpad is usually scoped to the current task or session (working memory), while long-term memory is scoped across sessions entirely (what the agent knows about a user or project over weeks). Both solve the same underlying problem — the window is not durable storage — at different time horizons.

Doesn’t persisting everything just move the overflow problem to the external store? Not in the same way, because the external store isn’t bounded by the model’s context window — a database row or a file doesn’t have a token limit the way a single API call does. The constraint shifts from “does this fit in the window right now” to “how much of this do I selectively read back in for the current turn,” which is a retrieval problem, not a hard capacity ceiling. You still need to be deliberate about what you re-read (see the budgeting link above), but the failure mode changes from “silently wiped” to “over-fetched,” which is a much easier problem to catch and fix.

Does compaction always wipe unpersisted state, or only sometimes? Treat it as always, for design purposes. Whether a specific implementation summarizes rather than hard-deletes doesn’t change the guarantee you should design around: a summary is lossy by definition, and there’s no contract that a scratchpad note survives summarization intact. If a piece of information matters enough that losing or garbling it would break the task, persist it explicitly rather than trusting the compaction step to preserve it faithfully.

How is this different from lost-in-the-middle? Lost-in-the-middle is an attention problem — the information is still physically present in the window, but the model attends to it weakly because of where it sits. This question is a persistence problem — the information isn’t present in the window at all anymore, because compaction rewrote it away and no copy exists elsewhere. They compound in long-running agents (an under-attended note is one bad compaction pass away from being gone entirely), but the fixes are different: repositioning for lost-in-the-middle, external storage for this one. See It Forgot Your First Instruction: Lost-in-the-Middle and Context Rot for the attention-side mechanism.

Where this fits in the CCA series

This is Q9 of the Domain 5 (Context Management & Reliability, 15% of the exam) practice set. Start with the Claude Certified Architect (CCA) Exam Guide for how all five domains fit together, and if the underlying shift from “just send more context” to deliberate context design is new to you, RAG vs Context Engineering is a useful primer on why this became its own discipline. From here, the rest of the D5 set builds on adjacent mechanisms: It Forgot Your First Instruction: Lost-in-the-Middle and Context Rot, The Task Overflowed the Window: Chunking and Decomposition, and It Failed and Answered Confidently Anyway: Error Propagation in Agents.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

As of mid-2026, the CCA-F exam runs on Pearson VUE, costs $125, and allows retakes — the format is 60 questions in 120 minutes with a passing scaled score of 720/1000 across five domains. Confirm these logistics on Anthropic’s official certification pages before you register, since exam details change.

Browse all tutorials for the rest of the series.