- In short
- The context strategy spectrum describes how context reaches the model on each call. A monolithic strategy loads everything into a single prompt at once; it suits bounded tasks with predictable input size but silently accumulates toward the window limit across turns. A progressive strategy stages what enters the window, retrieving just-in-time, summarizing across turns, and loading only what the next step needs. Retrieval and compaction are two further strategies that sit between the monolithic and progressive poles.
How context reaches the model is a design choice
Every workload makes a choice, explicitly or by default, about how context reaches the model on each call. The Claude Certified Architect - Professional (CCAR-P) exam frames this at the understand level as a spectrum with two poles and two strategies in between. At one end is monolithic loading; at the other, progressive staging; and retrieval and compaction sit between them. The point of the spectrum is that these are not competing brands to pick one of, but different answers to the question of what enters the window and when, each addressing a different dimension of the context problem. This choice sits on top of the bounded context window, whose hard token limit is exactly what makes the choice consequential.
- Context strategy spectrum
- A spectrum describing how context reaches the model each call. Monolithic loads everything into a single prompt at once, suiting bounded tasks with predictable input but accumulating toward the window limit across turns. Progressive stages context, retrieving just-in-time, summarizing across turns, and loading only what the next step needs. Retrieval (fetching relevant chunks at query time) and compaction (periodically summarizing accumulated context) sit between the two poles.
The monolithic pole
A monolithic context strategy places everything into the prompt at once: the full document, the full conversation history, the full retrieved corpus. Its virtue is simplicity, and it genuinely suits bounded tasks with predictable input size, where you know the content fits comfortably and does not grow. Its danger is what happens over turns: in a conversation, monolithic context accumulates silently, each turn adding to the total, until the window fills. There is no visible signal that this is happening until it surfaces as a cost spike or a truncation, which is the failure mode analysed in diagnosing silent context growth.
The progressive pole
A progressive context strategy stages what enters the window rather than loading it all. It retrieves just-in-time, bringing content in only when the current step needs it; it summarizes across turns so accumulated history is condensed rather than carried verbatim; and it loads only what the next step requires. Most production workloads that run for many turns belong toward this end, because staging is what keeps a long-running conversation from marching into the window limit. The progressive strategy trades a little added machinery for the ability to run indefinitely without accumulation.
Retrieval and compaction in between
Two more strategies sit between the poles. Retrieval (RAG) fetches relevant chunks from an external store at query time, keeping a large corpus out of the window until a specific slice is needed. Compaction periodically summarizes or compresses accumulated context, condensing what has piled up into the decisions and insights that carry the work forward. Each addresses a distinct dimension: retrieval handles content too large to preload, compaction handles context that has already accumulated. Neither is "more advanced" than the others; they answer different questions, which is why real systems combine them, as layering context strategies develops.
What the exam trips candidates on
The two traps are about how you treat the window and the strategies. The first is treating the context window ceiling as a design target to fill rather than a hard limit to budget below. A scenario will size a design to the full window; the credited reading budgets well under it, leaving margin for growth. The second is assuming one strategy is sufficient for a workload rather than considering which dimension of the context problem each strategy addresses. A scenario will pick a single strategy for everything; the credited reading matches strategies to the dimensions the workload actually presents.
Worked example
A team is designing a long-running research assistant that holds multi-turn conversations and needs to consult a large document corpus. They propose a purely monolithic strategy, loading the whole corpus and the entire growing conversation into every call, and they size the design to use the full context window. What is wrong, and how should they think about it?
Two errors, one on the window and one on the strategy.
Sizing the design to fill the full context window treats the ceiling as a target. The window is a hard limit to budget below, not a space to occupy. In a multi-turn conversation the total only grows, so a design that starts at the ceiling has no room for the accumulation that is certain to come, and it will hit the limit in production. The correct posture budgets well under the ceiling, leaving margin for the largest realistic conversation plus retrieved content plus growth.
Choosing a purely monolithic strategy for this workload is the second error. Monolithic suits bounded tasks with predictable input, and this workload is neither: the conversation grows across turns and the corpus is too large to preload. Loading everything every call guarantees accumulation toward the limit and wastes tokens on corpus content most turns will not use. Thinking in terms of the spectrum, the workload presents multiple dimensions: a large corpus (which retrieval addresses by fetching only the needed slice), a growing conversation (which a progressive window addresses by carrying forward only recent state), and, eventually, accumulated exploration (which compaction addresses by condensing it). No single strategy covers all three, so the design should match strategies to those dimensions rather than force one strategy to do everything.
Common misreadings to avoid
Misconception
If the context window is large, you should fill it with as much context as possible.
What's actually true
Misconception
One context strategy, chosen once, is enough for any workload.
What's actually true
How this shows up on the exam
Understand-level questions describe a workload and ask which context strategy fits, or present a single-strategy design and ask what it misses. The reliable answer places the workload on the spectrum, budgets below the window ceiling rather than filling it, and matches strategies to the specific dimensions of the context problem the workload presents.
This knowledge point builds on distinguishing context-related terms and the bounded context window, and it sets up layering context strategies in a single system and the diagnosis of silent context growth.
A long-running research assistant holds multi-turn conversations and consults a large corpus. A team proposes loading the whole corpus and the entire growing conversation into every call, sized to fill the context window. What is the best critique?
People also ask
What is a monolithic context strategy?
What is a progressive context strategy?
Should you fill the whole context window?
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.