- In short
- A monolithic context strategy loads all available tool definitions, documents, or data into context up front, regardless of whether a given request needs them. A progressive discovery strategy exposes only a minimal set initially and lets the agent request more detail or additional tools as the task requires. The choice affects both token cost per request and the model's ability to select the right tool from a smaller, more relevant set.
Two ways to put context in front of the model
When an agent has many tools or documents available, there is a design choice about how much of that to place in context, and the exam frames it as monolithic versus progressive. A monolithic strategy loads everything, all tool definitions, all documents, all data, into context up front on every request, whether or not the request needs it. A progressive discovery strategy does the opposite: it exposes only a minimal set initially and lets the agent request more detail or additional tools as the task actually requires. The two strategies sit at opposite ends of a spectrum, and choosing between them is a real architectural decision with cost and quality consequences.
This foundation names the two strategies and the two things the choice affects: token cost per request and the model's tool-selection quality. The later knowledge points quantify the cost and show how to implement the progressive alternative.
- Monolithic vs progressive context strategies
- Two approaches to loading context: a monolithic strategy loads all tool definitions, documents, or data up front on every request, while a progressive discovery strategy exposes a minimal set initially and lets the agent request more as needed. The choice affects per-request token cost and the model's ability to select the right tool from a smaller, relevant set.
Monolithic: everything, every request
The monolithic strategy is attractive because it is simple to reason about: everything the agent might need is already in context, so there is no round trip to fetch more and no discovery step to build. For a small, fixed set of tools or documents, that simplicity is a genuine virtue, the whole set fits comfortably and loading it once per request costs little. The problem is what happens as the set grows. Because monolithic loading puts the entire set in context regardless of what a request needs, its cost and its impact on tool selection scale with the size of the full set, not the size of what any single request uses.
So monolithic is not wrong, it is right for small, stable sets and wrong for large or growing ones. The trap is assuming its up-front simplicity makes it the safe default at any scale, when at scale it becomes expensive and starts to hurt tool selection.
Progressive: minimal now, more on demand
The progressive strategy exposes only a minimal, relevant set initially and lets the agent pull in more as the task unfolds, typically through a search or list step that returns just the relevant subset for the current step. Its cost is one extra round trip to discover or fetch what is needed; its benefit is that every request carries a small, focused context instead of the full catalogue. That keeps token cost tied to what a request actually uses, and it keeps the tool-selection set small and relevant, which helps the model pick the right tool.
The trade is a round trip for a leaner context. For a large or variable set, that trade pays off; for a tiny fixed set, the extra round trip can cost more than monolithic loading would have. So progressive is right for large, growing, variable sets and often unnecessary for small ones, the mirror image of monolithic. Neither is universally better, which is exactly why the scale-based choice is its own skill.
What the exam trips candidates on
Two traps. The first is assuming a monolithic strategy is simpler to reason about and therefore always preferable, ignoring its token cost at scale. The second is assuming progressive discovery always adds unacceptable latency, without weighing that against the cost of a bloated context. The credited answer treats the choice as scale-dependent, monolithic for small stable sets, progressive for large variable ones, rather than defaulting to either.
Worked example
A team is designing an agent that will eventually have access to a large and growing catalogue of tools and reference documents. One architect argues for a monolithic strategy because 'it's simpler, everything is just there,' and dismisses progressive discovery as 'adding a round trip that will slow every request.' Assess both arguments given the catalogue's trajectory.
Both arguments overweight one consideration and ignore the trajectory, which is the pair of traps this knowledge point warns about. Take the monolithic argument first. 'It's simpler, everything is just there' is true for a small, fixed set, but the catalogue here is described as large and growing. Monolithic loading puts the entire catalogue in context on every request regardless of what the request needs, so its token cost and its impact on tool selection scale with the full catalogue size, and they get worse as it grows. The up-front simplicity is real but does not make monolithic the right choice at this scale, which is the first trap, assuming simple-to-reason-about means always preferable.
Now the dismissal of progressive discovery. 'It adds a round trip that will slow every request' names a real cost, the discovery round trip, but weighs it in isolation against nothing. That is the second trap. The round trip has to be weighed against the cost of loading a large, mostly-unused catalogue on every request: the token cost, and the tool-selection degradation from a bloated candidate set. For a large and growing catalogue, a single extra round trip that yields a small, focused per-request context is very likely the better trade, and it keeps costs tied to what each request actually uses rather than to the full set's ever-growing size. So the assessment: given the catalogue's large and growing trajectory, progressive discovery is the stronger fit, and the monolithic simplicity argument and the progressive-latency objection are each half-arguments that ignore the scale that actually decides the choice.
Common misreadings to avoid
Misconception
A monolithic strategy is simpler to reason about, so it is the safe default at any scale.
What's actually true
Misconception
Progressive discovery always adds unacceptable latency because of the extra round trip.
What's actually true
How this shows up on the exam
Expect a scenario with a large or growing tool/document set and an argument for monolithic simplicity or against progressive latency. The reliable reading is that the choice is scale-dependent and affects token cost and tool selection, with neither strategy universally better. This foundation unlocks the token cost of monolithic loading at scale and implementing progressive discovery, relates to tool connections as attack surface and cost, and feeds the scale-based choice capstone.
An agent will have a large and growing catalogue of tools and documents. One architect wants monolithic loading 'because it's simpler' and rejects progressive discovery 'because of the extra round trip.' What is the sounder view?
People also ask
What is a monolithic context strategy?
What is progressive discovery?
How does context strategy affect token cost?
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.