Your Agent Blew the Context Window: Decompose Before You Overflow

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

▶ Watch on YouTube & subscribe to The Stack Underflow

An agent has been running for forty minutes. It has read a dozen files, called eight tools, and accumulated a transcript longer than a novella. Then the next API call fails — or worse, it doesn’t fail, it just quietly starts forgetting the thing you told it three steps ago. The context window filled up mid-task, and now the agent is either broken or lying to you about how much it remembers. This is one of the most common failure modes in long-running agentic systems, and it’s exactly the kind of “what breaks and what do you do about it” question the Claude Certified Architect exam likes to ask.

The one-sentence version: When a long-running agent overflows the context window, the first lever is compaction — summarizing or pruning the history to buy room without losing the thread — not a bigger model, not deleting the system prompt, and not starting over.

The question

A long-running agent overflows the context window mid-task. What is the first lever to reach for?

• A) Bigger model
• B) Summarize/compact the history
• C) Delete the system prompt
• D) Restart the task

Pause here and pick an answer before you scroll further.

The answer

B — summarize or compact the history.

The context window is not infinite, and it is not free. Every message, every tool call, every tool result sits in that window as a line-item competing for the same finite budget. When a long task overflows it, the problem isn’t that the agent needs more raw capacity thrown at it — the problem is that the history line-item has grown unbounded while the task is still in progress. The fix that addresses that specific failure is compaction: collapse the accumulated turns into a shorter summary that preserves the state the agent still needs (what’s been done, what’s left, key facts discovered) and drop the verbatim transcript that got it there.

Here’s the budget, drawn as it would be on the exam’s mechanism diagram:

CONTEXT WINDOW — FIXED BUDGET
┌───────────────────────────────────────────────────┐
│ [system prompt]  [tools/MCP]  [retrieved docs]     │
│ [history ─────────────────────────────────────▓▓▓▓]│ ← overflowing
│ [memory]                                           │
└───────────────────────────────────────────────────┘
                              │
                              │  compact / summarize
                              ▼
┌───────────────────────────────────────────────────┐
│ [system prompt]  [tools/MCP]  [retrieved docs]     │
│ [history — compressed summary ──]  ← room reclaimed│
│ [memory]                                           │
└───────────────────────────────────────────────────┘

Rule: the window is a budget. Compaction buys room without
losing the thread — it does not touch the task, the tools,
or the system prompt.

The mechanism is targeted. You are not solving “the agent doesn’t have enough intelligence” (that’s what a bigger model would fix) and you are not solving “the task is unrecoverable” (that’s what a restart implies). You are solving “the history line-item outgrew its allocation,” and the direct fix for an oversized history line-item is to shrink the history line-item — via a running summary, a rolling window of the most recent turns, or pruning stale tool outputs that are no longer relevant to the remaining steps. Everything else about the run — the goal, the tools available, the system prompt — stays intact.

Why the other options fail

• A) Bigger model. A larger context window from a bigger model just raises the ceiling — it doesn’t change the trajectory. An agent that accumulates unbounded history at a fixed rate per step will eventually overflow any window, it just takes longer. Bigger model also means bigger cost per token processed, so you’re paying more to delay the same failure rather than fixing it. This is the classic distractor: it feels like “more resources solves resource exhaustion,” but the resource here isn’t compute, it’s an unmanaged growth pattern.
• C) Delete the system prompt. The system prompt is usually one of the smallest line-items in the budget, and it’s the one carrying the agent’s role, constraints, and tool-use conventions. Deleting it reclaims almost no room and actively breaks the agent’s behavior — you’d get tokens back at the cost of the agent no longer reliably following its own instructions. This distractor tests whether you understand which line-item is actually the problem; the system prompt was never the one overflowing.
• D) Restart the task. Restarting throws away everything the agent has already learned and verified mid-task — the very state compaction is designed to preserve. On a long-running task, that’s expensive in wall-clock time and in re-doing tool calls that already succeeded. Restart is sometimes the last resort if the transcript is genuinely corrupted or the agent has drifted off-goal, but it’s never the first lever — you reach for it after cheaper fixes (compaction, pruning, decomposition) have been tried.

The concept behind it

This question is really about context engineering as capacity planning, and it generalizes well past this one scenario.

Think of the context window as a fixed-size budget with several competing line-items: the system prompt, the tool/MCP definitions, any retrieved documents (RAG), the conversation history, and anything pulled from long-term memory. Every one of those is finite, and on a long-running agent, history is the line-item that grows during the run — it’s the only one actively accumulating turn over turn. That’s why it’s almost always the first place to look when a budget overflows mid-task.

There are three related levers worth knowing apart, because the exam (and real production systems) will test whether you reach for the right one:

Compaction and decomposition solve different shapes of the same underlying problem. Compaction is the in-flight fix — you’re already mid-task, the window is full, and you need to reclaim room without derailing the agent. Decomposition is the architectural fix — instead of letting one agent accumulate an ever-growing transcript across a task that was always going to be long, you split the work into smaller units up front (subagents, a pipeline of stages, a plan-then-execute pattern) so no single context ever needs to hold the whole history. In practice, well-designed long-running agents use both: decomposition to keep individual sub-tasks bounded, and compaction as the safety valve for whichever sub-task still runs longer than expected.

The pattern to remember for the exam: identify which budget line-item is actually overflowing, then apply the fix that targets that line-item — not a fix that targets a different part of the system. A bigger model targets compute capacity. Deleting the system prompt targets the wrong line-item entirely. Restarting throws away the very state you’re trying to preserve. Only compaction targets the thing that’s actually growing.

FAQ

Does compaction lose information the agent might need later? It can, which is why compaction should preserve a structured summary — key facts, decisions made, remaining sub-goals — rather than blindly truncating the oldest messages. A naive “drop the first half” approach risks cutting the original task instructions or an early constraint the agent still needs. A good compaction step is closer to “write a status report of everything so far” than “delete old messages.”

Is compaction the same thing as prompt caching? No. Prompt caching reuses a stable, unchanging prefix (system prompt, tool definitions) across repeated calls to save cost and latency — it doesn’t shrink a growing history. Compaction actively reduces the size of the history line-item itself. They’re complementary: cache the stable parts, compact the growing part.

When should I decompose instead of just compacting? If you find yourself compacting the same agent’s history repeatedly within a single task, that’s a signal the task itself is too large for one continuous run. At that point, decomposing into sub-tasks or sub-agents — each with its own bounded context — is the more durable architectural fix, rather than relying on compaction as a recurring patch.

What actually triggers a context overflow in practice? Most commonly: a long tool-use loop where every tool result (file contents, API responses, search results) gets appended to history verbatim, with nothing ever pruned. A single large file read or a chatty tool that returns pages of JSON can consume a disproportionate share of the budget in one turn.

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.

Where this fits in the CCA series

This is question 6 of 10 in the Domain 1 (Agentic Architecture & Orchestration, ~27% of the exam) practice set. If context budgeting is new territory, back up to RAG vs Context Engineering for the fuller picture of what fills that window in the first place, and to MCP Explained on One Diagram for how tools occupy their own slice of it.

Within Domain 1, this question sits next to a few closely related failure modes: The Agent Loop Explained covers what happens when tool results aren’t fed back into context at all, Why Your Agent Loops Forever covers the missing-exit-condition failure that can itself cause runaway history growth, and When Two Agents Disagree, Who Decides? covers the orchestration pattern that decomposition often relies on. For exam logistics (Pearson VUE, $125, retakes, 60 questions / 120 minutes, pass threshold 720/1000, five domains — verify on Anthropic’s official pages before you sit the exam) and the full five-domain map, start with the Claude Certified Architect (CCA) Exam Guide.

Browse all tutorials for the rest of the series.