What you need to know
Lesson 2.4 compared context strategies for data. This task applies the same choice to an agent's capabilities: its tools, its procedures and the knowledge it may need. Should all of it be in the context from the first turn (monolithic), or should the agent find and load what it needs as it goes (progressive discovery)?
The two strategies
| Monolithic | Progressive discovery | |
|---|---|---|
| How | Every tool definition, instruction and reference document is loaded up front | The agent starts with a short index and loads details when the task calls for them |
| Strength | Simple, predictable, nothing to look up, easy to cache | Scales to large capability sets; the context stays focused |
| Weakness | Cost and clutter grow with every capability added; selection accuracy drops | An extra step to find things; the agent can fail to discover what it needs |
| Fits | Small, stable capability sets; short tasks that use most of what is loaded | Large or growing tool and procedure libraries; long-running agents |
Mechanisms for discovery
- Skills. Only each Skill's name and short description sit in the context. When a task matches, the agent reads the full instructions, and only then any scripts or reference files inside the Skill. Dozens of procedures stay available at almost no standing cost.
- Tool search. Instead of sending hundreds of tool definitions, the agent gets a search capability and loads the few relevant tools for the current step.
- Just-in-time retrieval. The agent holds lightweight references (file paths, document IDs, queries) and fetches content when it needs it, the way a person uses a file system rather than memorizing it.
- Subagents. A subagent explores in its own context and returns a condensed result, so the main agent never carries the raw material.
What makes discovery work
Discovery fails silently when the agent cannot tell what exists. Descriptions and names carry the load: each Skill's description must say clearly when to use it; each tool's name and summary must be findable by the words a task would use. Test discovery itself in evaluations: given a task, did the agent find and load the right capability?
In the exam
Scenarios describe an agent whose context is dominated by tool definitions or procedures, slow or expensive session starts, or wrong-procedure errors as the library grows. The answer moves rarely used capabilities behind discovery (Skills, tool search, just-in-time retrieval, subagents) and keeps the always-loaded part small. When the capability set is small and stable, the answer is the simple monolithic load, often with caching.
Check your understanding
An agent can use 300 internal tools, but any single task needs about five. What is the best approach?
Show answer
Answer: B. With hundreds of tools and a handful used per task, loading on demand keeps the context focused and selection accurate. Caching makes the clutter cheaper but leaves it in place.
Why do Skills scale to many procedures without filling the context window?
Show answer
Answer: A. Skills use progressive disclosure: the description is always present, the full instructions and files load only when relevant.
An internal agent has six tools and short, stable instructions, and every task uses most of them. Which TWO choices fit?
Show answer
Answer: B, C. A small, always-used capability set is the monolithic case. Discovery would add a step and a failure point, while caching makes the repeated prefix cheap.
Apply it: Slim Quillstone's Claude Code setup
During a pilot, Quillstone's platform team gave every engineer the same Claude Code setup: 18 MCP servers enabled globally, and a 25,000-token shared instruction file with coding conventions for all three languages, the release procedure, the incident runbook, the migration guide and the security checklist. Engineers report slow starts and Claude applying the Java conventions in Python services.
- Sort the content into "always loaded" and "discover when needed".
- Decide how each part is delivered: project instructions, Skills, per-project MCP servers or something else.
Why: the right mechanism keeps the standing context small without hiding anything. - Say how you will test that discovery works.
Show model answer
1. Sort
| Content | Always or on demand |
|---|---|
| Universal conventions (commit format, branch rules, "never read secrets") | Always |
| Language-specific conventions | Always, but only for that repository's language |
| Release procedure, migration guide | On demand |
| Incident runbook | On demand |
| Security checklist | On demand, but also enforced by CI |
2. Delivery
- A short organization-wide instruction file with the universal conventions.
- Each repository's own project instructions with only its language's conventions, which fixes the Java-in-Python problem.
- Skills for the release procedure, migration guide, incident runbook and security checklist, each with a precise "use this when..." description.
- MCP servers enabled per project: the logs and deployment-history servers for service repositories, the catalogue server everywhere, the rest only where needed.
3. Testing discovery. A small evaluation of typical tasks ("prepare the release for service X", "migrate this module to the new logging library") checking that Claude loads the right Skill and only the relevant MCP tools, plus measuring starting context size before and after.