Progressive Discovery vs Monolithic Context Strategy.

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.

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.