What You Need to Know
An agent needs tools, procedures and reference knowledge in context. There are exactly two ways to load them. Monolithic context loads everything upfront. Progressive discovery loads each piece on demand. A hybrid uses both. Neither way is the answer by default.
This lesson uses one made-up example throughout: a supermarket chain's customer assistant for online orders. Nearly every message tracks an order, changes a delivery time or refunds a missing product. The assistant can also use about 150 other tools from many servers (loyalty cards, the pharmacy, recipes), a product-recall procedure and a policy library. Customers rarely need those.
The Monolithic Economics
Loading everything upfront is the simplest architecture. For a small, stable surface (all the tools, procedures and knowledge an agent can use), it is the best one. It needs a single round trip and no discovery logic. Prompt caching makes the stable prefix (the start of the prompt that does not change) nearly free after the first request. Three order tools alone need nothing more.
The costs appear with scale. A large tool catalogue from many servers takes a meaningful share of the window before any work starts. Tool selection accuracy degrades as the catalogue grows (objective 3.1's capability bloat, at large catalogue sizes). Attention over everything loaded degrades as the window fills (Domain 2's context rot). After a certain point, capability that you add monolithically reduces performance. Context rot and cost appear well before the window limit. If the supermarket chain loads all 150 rarely used tools upfront, they take space in the window on every order request.
Progressive Disclosure, Several Mechanisms
Progressive discovery is one principle with several mechanisms:
- Skills load in stages: name and description always, the full instruction body only when triggered, bundled resources only when read. A large set of skills carries almost no per-request cost until used.
- Deferred tool loading uses search to find tools in the catalogue. Only the schemas (the full definitions) of discovered tools enter context. This keeps selection accuracy steady at catalogue sizes that would degrade a monolithic load.
- Agentic exploration and retrieval (objectives 3.5 and 3.6) extend the same idea to knowledge. The agent keeps lightweight identifiers and loads content as questions arise.
Discovery has its own cost: extra round trips, more components, and discovery logic that must itself be reliable. A tight latency budget for interactive use tolerates fewer hops (discovery round trips). A customer who waits for an order status notices each hop.
Four Decision Cues
- Surface-to-slice ratio. A large surface where each request uses a small slice favours discovery. A small surface that is used whole favours monolithic context.
- Frequency. Capability that nearly every session uses belongs upfront, where the cache lowers its cost. Capability that is rarely used belongs behind discovery.
- Latency. Each discovery hop is a round trip. A tight latency budget for interactive use limits the number of hops on the path.
- Stability. Stable content upfront benefits more and more from caching. Volatile content upfront keeps the cache changing and belongs behind discovery instead.
The Hybrid Is Usually the Answer
The balanced design keeps a small, stable, hot core monolithic and cached. The hot core is the few tools and instructions that nearly every request uses. The long tail is the many capabilities that are rarely used. It stays behind discovery: tool search (the search that deferred tool loading uses) for the catalogue, skills for procedures, retrieval for knowledge. This is also the default that the vendor documents: keep the handful of most-used tools loaded, and defer the rest. The supermarket chain caches its order-tracking, delivery and refund tools. Everything else stays behind tool search, a skill or retrieval. Order requests stay fast, and the tail costs almost nothing until the assistant uses it.
In the exam
The guide tests how you evaluate progressive discovery against a monolithic context strategy. Questions supply the four cues. In most questions that supply all four, the right answer is the hybrid. A question that names a tight SLA names the cost of discovery. When a question names both a large surface and a tight latency budget, the hybrid is the option that addresses both.
A Big Enough Window Does Not Decide the Strategy
"The window is big enough, so load everything" is this objective's tempting wrong option. The right answer is based on the four cues, never on what fits.
The Domain 3 quick reference has dated snapshots of the current catalogue-size and context-saving figures.
Exam Traps
Loading everything upfront because the context window is big enough to hold it
Recall over loaded content degrades as the window fills, selection degrades with catalogue size, and every request pays for capability it never uses. Decide by surface-to-slice ratio, frequency, latency and stability, not by whether it fits.
Keeping every tool and runbook in the prompt and relying on a cache breakpoint to make it cheap
Caching makes the prefix cheaper, not smaller. All the loaded content still occupies the window and dilutes attention on every request. Cache the hot core and put the long tail behind discovery.
Capping the agent's tool count permanently when the requirement says the surface must grow
A cap that looks like discipline abandons the stated requirement instead of architecting for it. Discovery exists precisely so a growing surface need not cost the whole catalogue per request.
Deferring everything, including the tools nearly every session uses
The vendor guidance itself keeps the few most-used tools loaded. Forcing the hot core through search adds round trips with no benefit. The cache would have served it at almost no cost.
Practice Scenario
An enterprise copilot must eventually reach 200+ internal tools and a large policy library. A typical request uses 2 to 3 tools and a handful of policy passages; the interactive SLA is tight; five core tools appear in nearly every session. Which context strategy fits?
Build Exercise
Capability-Loading Plan for a Growing Agent
What you'll learn
- How to inventory a capability surface across tools, procedures, and knowledge
- How to measure the four cues: slice ratio, frequency, latency budget, stability
- How to partition a surface into a cached core and a discovered tail
- How to verify the design against its SLA and its growth trajectory
- Take an agent whose capability surface will grow — or design one — and inventory the surface: tools, skills or procedures, and reference knowledge
Why: The strategy is decided per component, and components are easy to miss: procedures and knowledge are part of the surface even when only tools get counted.
You should see: A three-column inventory (tools, procedures, knowledge) with rough sizes.
- Measure or estimate the four cues: per-request slice versus total surface, usage frequency per capability, the latency budget, and the change rate of each component
Why: The cues are the whole decision — a strategy chosen before measuring them is a preference, not a design.
You should see: Four figures or honest estimates, with the hot capabilities (used in nearly every session) explicitly flagged.
- Partition the surface: the hot stable core that loads upfront and caches, versus everything that sits behind discovery — tool search for the catalogue, skills for procedures, retrieval for knowledge
Why: The hybrid is the usual answer, and the partition is the step where the four cues decide the architecture.
You should see: Two lists: a small cached core with a justification per entry, and the discovered tail with its mechanism per component.
- Count the discovery round trips a typical request now makes and check the sum against the interactive SLA; move anything that breaks the budget into the core or behind caching
Why: Discovery has a latency price, and the SLA is the limit it must fit — the design is not done until the total latency fits the SLA.
You should see: A per-request hop count, a latency estimate, and a pass or fail against the SLA with any moves noted.
- Write the growth test: at double the tool count and double the knowledge base, which per-request numbers change — and confirm the answer is almost none
Why: The point of the hybrid is that the surface scales without every request paying for it; the growth test is the proof.
You should see: A short paragraph naming which figures move at double scale (the discovered tail) and which hold (the core, the per-request slice, the SLA).
Sources
- Agent Skills overview — Anthropic
- Tool search tool — Anthropic
- Effective context engineering for AI agents — Anthropic
- Prompt caching — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 3 — Anthropic
- CCAR-P Exam Guide v1.0 - Domain 3 — Anthropic