TLDR
As an agent's tool/skill/knowledge surface grows, an architect chooses between loading everything upfront (monolithic - predictable, but token-expensive) or exposing capabilities on demand (progressive discovery - token-efficient, but dependent on the model finding the right thing at the right time). Anthropic names the monolithic failure mode directly: loading every tool definition into context upfront wastes tokens, increases latency, and degrades model performance at scale.
What it is
As an agent's tool, Skill, or knowledge surface grows past a handful of items, an architect faces a strategic choice with no universally-correct default: load every definition into context upfront (monolithic) or expose capabilities on demand as the task requires them (progressive discovery). Anthropic's own MCP client guidance names this exact tradeoff for tool management at scale - monolithic loading is predictable and has zero discovery-latency risk, but wastes tokens, increases latency, and degrades model performance once a host connects to many servers with hundreds or thousands of tools.
The same pattern recurs across Anthropic's stack, not just MCP. Agent Skills load only metadata (name + description) at startup; the full SKILL.md body and any bundled scripts load only when a task actually matches. Claude Code applies it to MCP tools directly - deferring tool definitions and using a search tool to discover relevant ones on demand, the exact production mechanism behind this repo's own ToolSearch deferred-tool pattern. Anthropic's context-engineering guidance frames it as a general principle: the context window is a public good shared across the system prompt, conversation history, every other Skill's metadata, and the current request - which is the argument for minimal footprint even under progressive discovery.
How it works
Monolithic loading front-loads everything. Every tool/Skill/document definition enters the context window before the conversation starts. The upside is zero discovery risk - the model can never fail to find a capability it can't see, because it can see all of them. The downside compounds with scale: more definitions means more tokens spent on every single turn, higher latency, and degraded reasoning quality as the surface grows, independent of whether that turn ever uses most of what was loaded.
Progressive discovery exposes capabilities on demand. Only a lightweight index (names, descriptions, a search tool) loads upfront; the full content loads only when a task matches. This is how Agent Skills work by design, how Claude Code handles MCP tools at scale, and how Anthropic's context-engineering guidance frames autonomous retrieval generally - letting agents navigate and incrementally discover relevant context rather than front-loading it all.
The tradeoff is reliability for efficiency, not a free upgrade. Progressive discovery is dependent on the model reliably finding and selecting the right deferred item. If it fails to search for or picks the wrong tool, the task fails in a way monolithic loading never would - monolithic can't have a *discovery* failure because there's nothing left to discover. This is why the exam framing treats progressive discovery as a scaling answer, not a universal default.
Scale and volatility are the deciding variables. A narrowly-scoped agent with a small, fixed tool set (say, lookup_order, get_customer, issue_refund, escalate, log_note) has little discovery risk to trade away - loading them all upfront costs a handful of tokens and adds minimal latency. An enterprise agent connected to 40 MCP servers spanning finance, HR, and engineering catalogs is the opposite case: loading every definition would flood the context window before the conversation begins, so it should expose a small meta-tool that searches for relevant tools and defer the rest.
The two strategies compose within one system. Nothing forces an architect to pick one strategy uniformly across an entire agent. A small, stable, frequently-reused core (a few always-needed tools) can be monolithic while a large, volatile long tail (hundreds of optional integrations) is progressively discovered - the real-world answer is often a tiered hybrid, not an either/or vote.
Treating progressive discovery as strictly superior in all cases because it saves tokens. It trades predictable, always-available context for token efficiency at the cost of discovery reliability - if the model fails to search for or select the right deferred tool, the task fails in a way monolithic loading never would. The correct exam answer evaluates the tradeoff against the surface's size and volatility, not a blanket "progressive discovery is always better."
Where you'll see it
40-server enterprise integration agent
Finance, HR, and engineering MCP catalogs expose a search-tools meta-tool; individual tool definitions load only when a task matches, avoiding a context flood at conversation start.
5-tool customer support agent
lookup_order, get_customer, issue_refund, escalate, and log_note load upfront every turn - there's no discovery risk at this scale, so progressive discovery would only add latency.
Decision tree
Is the tool/Skill/knowledge surface large (dozens-thousands) and/or growing or volatile?
Is discovery-failure tolerance low (a missed capability must never silently fail the task)?
Is context-window budget the binding constraint (long conversations, many concurrent Skills/MCP servers)?
Can the surface be tiered into a small stable core plus a large long tail?
Question patterns
6 V2 questions wired to this concept. Tap an answer to check it instantly - you'll see whether it's right and why - then expand the full breakdown for the mental model and all four rationales.
A public-sector assistant prepends 300 pages of procurement, travel, records, and hiring policy to every request. Most users ask about only one policy family, and relevant clauses are being crowded by unrelated text. Which redesign best applies progressive disclosure?
Frequently asked
Showing 2 of 2 questions