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 is the answer by default.
Take a swimming school's booking assistant. Nearly every message books a lesson, checks the timetable or takes fees. Gala entries, certificates, the accident-report procedure and the policy library come up a few times a term.
The Monolithic Economics
Loading everything upfront is the simplest architecture, and for a small, stable surface the best one. It needs a single round trip and no discovery machinery. Prompt caching makes the stable prefix nearly free after the first request. Three booking tools alone need nothing more.
The costs arrive with scale. A large multi-server tool catalogue takes a meaningful share of the window before any work happens. Tool selection accuracy degrades as the catalogue grows (objective 3.1's capability bloat, at estate scale). Attention over everything loaded degrades as the window fills (Domain 2's context rot). Past a point, capability added monolithically subtracts performance, and rot and cost arrive well before the window limit. Loaded whole, gala tools crowd the booking tools on every 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. An estate of skills carries almost no per-request cost until used.
- Deferred tool loading puts the catalogue behind search: only discovered tools' schemas enter context, which holds selection accuracy 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: keep lightweight identifiers, load content as questions arise.
Discovery has its own price: extra round trips, more moving parts, and discovery logic that must itself be reliable. A tight interactive latency budget tolerates fewer hops. A parent waiting for a lesson slot feels each one.
Four Decision Cues
- Surface-to-slice ratio. A large surface of which each request uses a small slice favours discovery; a small surface used whole favours the monolith.
- Frequency. Capability used in nearly every session belongs upfront, where the cache pays for it; the long tail belongs behind discovery.
- Latency. Each discovery hop is a round trip; tight interactive budgets cap how many the path affords.
- Stability. Stable content upfront compounds with caching; volatile content upfront churns the cache and belongs behind discovery instead.
The Hybrid Is Usually the Answer
The balanced design keeps a small, stable, hot core monolithic and cached: the few tools and instructions nearly every request uses. The long tail sits behind discovery: tool search for the catalogue, skills for procedures, retrieval for knowledge. This is also the vendor-documented default: keep the handful of most-used tools loaded, defer the rest. The school caches its booking, timetable and fees tools. Everything else waits behind tool search, a skill or retrieval. Booking stays fast, and the tail costs almost nothing until used.
In the exam
The guide tests evaluating progressive discovery against a monolithic context strategy. Stems supply the four cues. Most stems that supply all four key the hybrid. A stem naming a tight SLA is naming discovery's cost. When a stem names both a large surface and a tight latency budget, the hybrid is the option that addresses both.
Capacity Is Not a Strategy
"The window is big enough, so load everything" is this objective's seductive distractor. The keyed answer reasons from the four cues, never from what fits.
The current catalogue-size and context-saving figures are dated snapshots in the Domain 3 quick reference.
Exam Traps
Loading everything upfront because the context window is big enough to hold it
Rot and cost arrive before the limit does: recall over loaded content degrades as the window fills, selection degrades with catalogue size, and every request pays for capability it never touches. Capacity is not a strategy.
Choosing a pure strategy where the stem gives hybrid cues
A hot core plus a long tail keys core-upfront-and-cached with the tail discovered. All-monolithic ignores the tail's cost on every request; all-progressive spends the latency budget on hops the hot core never needed.
Capping the agent's tool count permanently when the requirement says the surface must grow
A cap dressed as 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 buys round trips for nothing — 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 hide: 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 line is where the four cues become an 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 where it gets paid — the design is not done until the arithmetic closes.
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