Progressive Discovery vs. Monolithic Context
CoreChoose progressive discovery over monolithic context for large integrations · Difficulty 3/5
Explanation
There are two fundamentally different ways to give an agent what it needs to know about an environment, and the choice between them determines how well an integration scales.
Two Approaches
| Approach | Description | Tradeoff |
|---|---|---|
| Monolithic context | Front-load everything — all tools, all schemas, all docs — into the context window up front | Simple, but bloats context, raises cost, and invites context rot; most of it is unused on any given request |
| Progressive discovery | Expose a lean surface and let the agent fetch detail *on demand* (list resources, then read the one it needs; discover tools as required) | Keeps the window lean and scales to large tool/resource sets |
When Each Fits
For large integrations, Progressive Discovery is the scalable pattern: it lets an agent operate against hundreds of tools or a large document/resource catalog without paying the context cost of loading all of it on every turn. Monolithic context is acceptable only when the full set is small and stable — a handful of tools that rarely change is fine to load up front; a catalog of hundreds is not.
Why This Matters
This mirrors the general context-curation discipline applied elsewhere in agent design: keep the context window lean, and pull in detail only when it is actually needed for the task at hand. The same reasoning that argues against dumping an entire corpus into context for RAG (task statement 3.3) argues against dumping an entire tool/resource catalog into context here.
Key Takeaways
- Monolithic context front-loads all tools/schemas/docs, bloating context and inviting context rot
- Progressive discovery exposes a lean surface and fetches detail on demand
- Progressive discovery scales to large tool/resource sets; monolithic context is acceptable only when the full set is small and stable
- This mirrors the context-curation discipline applied elsewhere in agent and RAG design
Glossary Terms
The application-controlled MCP primitive. The host application determines what data to provide to Claude by reading resources. Resources are identified by URIs and can be text, JSON, binary data, or template-generated content. Claude reads but does not autonomously request resources.
The practice of actively reducing a conversation's token footprint so it fits within the model's context window without silent truncation. Encompasses multiple strategies — rolling window eviction, progressive summarization, external storage with retrieval, and prompt caching — each with different loss profiles and complexity trade-offs. Understanding this menu of options, and knowing what must never be compressed, is a core Domain 5 skill.
An agent-environment interface design where a lean surface is exposed up front and the agent fetches additional detail on demand, rather than front-loading every tool, schema, and document into context (monolithic context). Progressive discovery is the scalable pattern for large integrations; monolithic context is acceptable only when the full set is small and stable.
Related Concepts