CCAR-P - Integration (19% of the exam) - Section 3.8

Evaluate progressive discovery vs. monolithic context strategy.

Deciding whether to load everything a system might need into context up front or to let the model discover tools, documents and instructions progressively as a task requires them. Candidates should weigh context cost and distraction against the risk that something needed is never discovered.

progressive disclosuremonolithic contextcontext costtool and resource discovery

Practice question for this objective

Free sampleIntegrationhard

A cloud software company is building an internal platform assistant for 2,000 engineers that must act across 180 tools spread over 14 internal services. Last quarter's tickets show that 40 percent of tasks touch three or more services, and that most tools are needed by fewer than one task in a hundred, though every tool is needed by some task. With all 180 definitions loaded on every request, the prototype picks the wrong tool on 11 percent of turns and exceeds the cost ceiling per task set by finance. The platform lead requires that rarely used tools stay reachable within the same conversation as the rest of the task. What should the architect recommend?

ALoad only the 30 most used tools and retire the other 150, sending long-tail requests to a ticket queue for the owning service team.
BSplit the assistant into 14 service-specific agents behind a router that sends each request to the single agent owning that service.
CExpose a search over the tool catalogue that returns matching definitions on demand, and test on a task set that needed tools are found. Correct
DKeep every definition loaded and move to a more capable model tier, so tool selection improves across the full catalogue of 180 tools.

For a large catalogue where any tool may be needed but few are needed per task, use on-demand tool discovery and verify that discovery finds what tasks need. Loading every definition up front spends context on tools that almost no task uses and gives the model more options to confuse, which drives both the cost overrun and the wrong-tool rate. Searching the catalogue on demand keeps the starting context small while leaving every tool reachable, and evaluating discovery recall guards against the trade-off of progressive discovery, which is that a needed capability might not be found.

Why A is wrong: Pruning to frequently used tools is the right move when tools are genuinely unneeded, and it cuts both cost and confusion. Here every tool is needed by some task, so retiring 150 of them breaks the requirement that rarely used tools stay reachable within the conversation.

Why B is wrong: Specialised agents each hold a small tool set, which improves selection and lowers cost, so this is a credible design. It fails the stated workload: 40 percent of tasks span three or more services, and routing each request to a single service agent leaves those tasks without the tools they need in one conversation.

Why C is correct: Discovering tools progressively keeps only a small search capability in the starting context, which reduces cost and the number of competing definitions behind wrong-tool choices, while every tool remains reachable in the same conversation. Measuring discovery recall on representative tasks addresses the main risk of the pattern, that a needed tool is never found.

Why D is wrong: A stronger model can choose more accurately among many tools, which makes this attractive. It addresses the wrong layer and moves cost the wrong way: all 180 definitions are still sent on every request, so the per-task ceiling is breached by more, and the distraction from irrelevant definitions remains.

See more CCAR-P practice questions, answers explained.

Exam traps in Integration

Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-P bank for this domain.

The discovery tool's search backend is slow to locate protocols, so every lookup stalls the conversation while the index is scanned
Why it is wrong: A slow retrieval backend is a frequent cause of added latency in tool-based designs, so it is worth considering. It is wrong because the handler completes in a median of 110 milliseconds, far too little to explain a rise of more than five seconds, and a slow backend would not raise input token counts.
Add an output filter that masks any string matching the key's format before replies are shown to users or written to the transcript archive.
Why it is wrong: This is tempting because it blocks the exact leak the red team demonstrated. It is wrong because the key still sits in the system prompt, which forms part of every retained transcript, and masking content written to the archive conflicts with the requirement to keep transcripts unaltered.
Adopt the registry so the incident agent shares one discovery mechanism with the internal assistant and new tools need no prompt change.
Why it is wrong: Platform consistency and easier tool onboarding are real benefits, which is why this appeals. It optimises for the wrong goal: with most tools used in nearly every session, the agent would pay extra discovery steps on almost every incident, increasing time to first useful answer for a negligible token saving.

Examworthy is not affiliated with or endorsed by Anthropic. Original, blueprint-aligned practice material only.