- In short
- Production systems typically combine context strategies rather than picking one: a small stable monolithic prefix at session start, a progressive window carrying recent steps, just-in-time retrieval for content not preloaded, and compaction once early exploration accumulates. Each strategy addresses a distinct dimension of the context problem, so none alone can carry a long-running, evolving workload. Context strategy (how content enters the window) and context sizing (how much fits) are separate decisions that interact but do not determine each other.
Real systems layer, they do not pick
The context strategy spectrum presents four strategies separately for clarity, but the Claude Certified Architect - Professional (CCAR-P) exam wants you to know that production systems almost always combine them. At the apply level, the skill is composing a layered context design where a monolithic prefix, a progressive window, just-in-time retrieval, and compaction each do the job they are suited to, within one long-running workload. Because each strategy addresses a different dimension of the context problem, none alone can carry a system that runs for many turns and evolves as it goes. Layering is the norm, not an advanced option.
- Layering context strategies
- Combining multiple context strategies within one system rather than choosing a single one: a small stable monolithic prefix at session start, a progressive window carrying recent steps, just-in-time retrieval for content not preloaded, and compaction once early exploration accumulates. Each addresses a distinct dimension of the context problem. Context strategy (how content enters the window) and context sizing (how much fits) are separate, interacting decisions.
Four strategies, four jobs
A long-running coding agent is the canonical example of the layering. At session start, a small stable monolithic prefix loads once: the task description and the few files the user explicitly referenced. Because it is stable, it is also ideal for prompt caching, a link picked up in content ordering for cache hit rate. During active work, a progressive window carries recent steps: each tool call, file read, or edit appends to the working context, and what matters most is the latest state the next step needs. When the agent discovers it needs a file it did not preload, just-in-time retrieval fetches the relevant slice from a corpus too large to load up front. And once early exploration has piled up, compaction condenses "what we tried and what we learned," preserving the decisions that carry the work forward while dropping verbatim detail.
The reason all four are needed is that each answers a different question. What does the model need at the start drives the monolithic prefix. What does it need from recent steps drives the progressive window. What might it need to fetch on demand drives the retrieval layer. What earlier material can be compressed without losing decision-relevant detail drives the compaction policy. Remove any one and a dimension of the problem goes unhandled.
Why no strategy stands alone
The layering is not redundancy; it is coverage. Monolithic alone hits the context limit as the conversation grows. Progressive alone has no way to surface code the agent did not initially load. Retrieval alone loses the thread of what has already been tried. And compaction alone has nothing to compact until the other strategies have built up a trajectory worth condensing. That last point is a favourite exam trap: compaction is a downstream strategy that depends on accumulation having already happened, so it cannot be the whole answer to a context problem on its own.
Strategy is not sizing
A separate but easily conflated decision runs alongside the strategy choice: context sizing, how much fits in the window. Context strategy is how content enters the window; context sizing is how much of it there is room for. These interact, a good strategy keeps sizing manageable, but they do not determine each other, and they are decided separately. Treating them as a single decision is where many context-management designs go wrong. You can choose a sensible layered strategy and still size the budget badly, or size well and still layer poorly.
What the exam trips candidates on
The two traps target the two conceptual slips. The first is assuming compaction alone can solve a context problem when nothing has yet accumulated for it to summarize. A scenario will reach for compaction as a first move; the credited reading notes compaction needs a built-up trajectory and pairs it with the strategies that create one. The second is treating context strategy and context-window sizing as the same decision rather than as two decisions that must both be made. A scenario will collapse them; the credited reading keeps how-content-enters and how-much-fits distinct.
Worked example
A long-running coding agent is hitting the context limit late in sessions. An engineer proposes 'just add compaction' as the single fix, and separately assumes that choosing a good strategy will automatically handle how much context fits. Evaluate both moves.
Both moves are partially right and revealingly incomplete.
Compaction is a legitimate part of the answer, but "just add compaction" as a standalone fix runs into the first trap: compaction has nothing to compact until other strategies have built up a trajectory. Early in a session there is little accumulated context to condense, so compaction contributes nothing then; it earns its place only once exploration has piled up. And compaction addresses only the accumulation dimension. The agent also needs a stable monolithic prefix at session start, a progressive window for recent steps, and just-in-time retrieval for files it did not preload. Adding compaction alone leaves those dimensions unhandled, and the limit will still be approached from directions compaction never touches. The right design layers all four so each dimension is covered, and compaction condenses the trajectory the others create.
The second assumption conflates strategy and sizing. Choosing a good layered strategy makes the context more manageable, but it does not by itself decide how much room to budget. Sizing, how large the working budget is, must be set as its own decision: budget for the largest realistic session, retrieved content, working scratch, and margin. A well-layered strategy with a badly sized budget can still hit the limit, and a well-sized budget with poor layering still wastes tokens. Keeping the two decisions separate, and making both, is what actually resolves the late-session limit.
Common misreadings to avoid
Misconception
Adding compaction is enough to solve a context problem on its own.
What's actually true
Misconception
Choosing a good context strategy also decides how much context fits.
What's actually true
How this shows up on the exam
Apply-level questions describe a long-running system and ask how to design its context handling, or offer a single-strategy fix and ask what it misses. The reliable answer layers a monolithic prefix, a progressive window, just-in-time retrieval, and compaction across the workload's dimensions, and treats sizing as a separate decision from strategy.
This knowledge point builds on the context strategy spectrum, connects the stable prefix to content ordering for cache hit rate, and its failure mode, an unlayered monolithic design, is the subject of diagnosing silent context growth.
A long-running coding agent hits the context limit late in sessions. An engineer says 'just add compaction' and assumes a good strategy choice will also settle how much context fits. What is the best correction?
People also ask
Do production systems use one context strategy or several?
How do the four context strategies work together?
What is the difference between context strategy and context sizing?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.