- In short
- Progressive discovery can be implemented by exposing a small search or list tool that returns only the relevant subset of tools or documents for the current step, so the agent fetches additional detail on demand rather than receiving the full catalogue up front. The pattern trades one extra round trip for a smaller, more relevant context on every subsequent step, and discovery results should be cached or reused within a session to avoid redundant discovery calls.
How to build the progressive alternative
The monolithic-versus-progressive choice is conceptual; this knowledge point is the implementation. Progressive discovery is built by exposing a small search or list tool, a discovery tool, that, given the current step, returns only the relevant subset of tools or documents for that step. The agent starts with that lean discovery capability instead of the full catalogue, calls it to find what the current step needs, and fetches the detail for just those items on demand. The heavy catalogue never enters context wholesale; only the relevant slice does, and only when asked for.
The exam treats this at the apply level, so you need the mechanism (the search/list tool returning a subset), the trade (a round trip for a leaner context), and the two implementation pitfalls (over-applying it, and forgetting to cache).
- Implementing progressive discovery
- A lazy-loading implementation of the progressive context strategy: expose a small search or list tool that returns only the relevant subset of tools or documents for the current step, so the agent fetches detail on demand rather than receiving the full catalogue up front. It trades one round trip for a smaller per-step context, and discovery results are cached within a session.
The search-or-list tool and the round-trip trade
The core mechanism is a discovery tool that answers 'what do I need for this step' with a small, relevant subset rather than the whole set. When the agent hits a step, it calls the discovery tool, receives the handful of relevant tools or documents, and pulls in their detail, leaving the rest of the catalogue out of context entirely. Every subsequent step carries only what that step needs, which is exactly the lean, relevant context the progressive strategy promises.
The cost is explicit and small: one extra round trip to run the discovery step. That round trip is what buys the leaner context, and for a large or variable catalogue it is a good trade, one discovery call in exchange for not carrying hundreds of unused definitions on every request. The trade is round trip for focus, and it pays off whenever the catalogue is big enough that carrying it all would cost more than the occasional discovery call.
Two implementation pitfalls
The first pitfall is over-applying lazy loading to a set that is too small to justify it. If the whole catalogue is a handful of tools that would fit cheaply in context, adding a discovery round trip on every step can cost more than monolithic loading would have. Progressive discovery earns its round trip only when the set is large or variable enough that the leaner context outweighs the discovery cost; for a tiny fixed set, the round trip is pure overhead. This is the implementation-level version of the scale-based choice: match the pattern to the set size.
The second pitfall is failing to cache or reuse discovery results within a session. If the agent re-runs discovery for the same information it already fetched earlier in the session, it pays the round-trip cost repeatedly for no new information, eroding the benefit the pattern was supposed to deliver. The fix is to cache discovery results within the session and reuse them, so each piece of discovery is paid for once. A progressive design that re-discovers the same subset on every step has quietly turned its one-round-trip trade into a many-round-trip cost.
What the exam trips candidates on
Two traps. The first is implementing lazy loading for a tool set so small that the extra round trip costs more than the monolithic approach would have, applying the pattern where it does not pay. The second is forgetting to cache or reuse discovery results within a session, causing repeated redundant discovery calls that erode the benefit. The credited answer applies progressive discovery to large or variable sets and caches discovery results within the session.
Worked example
A team implements progressive discovery for an agent with a large, variable document catalogue by exposing a search tool that returns the relevant documents for each step. In testing, the agent repeatedly calls the search tool for the same documents it already found earlier in the same session, and latency climbs. Separately, they consider using the same pattern for a different agent that has only four fixed tools. Diagnose both.
The first agent has the right pattern but a missing optimisation, the second pitfall. Exposing a search tool that returns the relevant documents per step is a correct progressive-discovery implementation for a large, variable catalogue, and the leaner per-step context is exactly the benefit. But the agent is re-running the search for documents it already discovered earlier in the same session, so it is paying the discovery round-trip cost repeatedly for information it already has, which is why latency climbs. The fix is to cache or reuse discovery results within the session: once the agent has discovered a document's location or detail, it should reuse that rather than re-searching, so each discovery is paid for once. That turns the pattern's intended one-round-trip-per-new-need trade back on, instead of a redundant-call-per-step cost.
The second agent is a case where the pattern should not be applied at all, the first pitfall. With only four fixed tools, the entire set fits cheaply in context, so a monolithic strategy loads all four at negligible cost and with no discovery round trip. Adding a discovery search step for four fixed tools would impose a round trip on every step to select among a set small enough to just carry, so lazy loading would cost more than monolithic loading and add complexity for no benefit. The diagnosis: fix the first agent by caching discovery results within the session, and do not apply progressive discovery to the four-tool agent, use monolithic loading there because the set is too small to repay a discovery round trip.
Common misreadings to avoid
Misconception
Progressive discovery is a better pattern, so it should be implemented even for a small fixed tool set.
What's actually true
Misconception
Once a discovery search tool is exposed, the implementation is complete.
What's actually true
How this shows up on the exam
Expect a progressive-discovery implementation that either re-discovers redundantly or is applied to a set too small to justify it. The reliable reading is a search/list tool returning the relevant subset, a round trip traded for a leaner context, applied to large/variable sets, with discovery results cached in the session. This knowledge point builds on monolithic vs progressive strategies and the token cost of monolithic loading, relates to retrieval method selection since discovery is itself a retrieval step, and feeds the scale-based choice capstone.
A progressive-discovery agent over a large document catalogue repeatedly re-searches for documents it already found in the same session, and latency climbs. What is the correct fix?
People also ask
How do you implement progressive discovery?
Is lazy loading ever counterproductive?
Why cache discovery results in a session?
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.