CCAR-P · module 3 of 7 · 19% of the exam

Integration

Covers the 8 official objectives: tool/agent capability bloat evaluation; auth/authz security-gap analysis; accuracy-latency trade-offs; observability at scale; RAG pipeline design (chunking/indexing); retrieval strategy matched to data/query shape; connection protocol selection (MCP vs API/CLI vs agent-to-agent); progressive discovery vs. monolithic context.

Two official sample themes live here: least-privilege tool configuration and (shared with Domain 4) RAG retrieval as first suspect after a document refresh.

Objective: Evaluate tool/agent configuration for capability bloat

• Core concept: Every tool/permission granted to an agent is attack surface and cognitive load, whether or not it's ever used maliciously. "Capability bloat" = granting more tools/scopes than the task requires, which increases blast radius on prompt injection, misfires, and confusion (more tools = harder for the model to pick the right one, and more surface for a compromised/hallucinating call to do damage).
• Anthropic-platform specifics:
  • Least-privilege tool configuration is an official sample theme — expect this directly. In the Managed Agents toolset (agent_toolset_20260401), the correct pattern is default_config: {enabled: false} + configs: [{name: "read", enabled: true}, ...] — an explicit allowlist, not "enable everything, disable the risky one." Enabling the full toolset and then disabling bash still leaves write/edit active if the task only needed read.
  • permission_policy (always_allow vs always_ask) is a second, independent lever from enable/disable — a tool can be enabled but gated behind human confirmation for higher-risk operations (e.g., bash set to always_ask while read/grep stay always_allow).
  • Custom tools are the tightest scope of all — you define exactly what the model can call and what your code does with the input; prefer a narrow custom tool over a broad bash grant when the actual need is a single well-defined action (see agent-design.md → "Bash vs. dedicated tools": promote to a dedicated tool when you need to gate, render, audit, or parallelize).
  • Tool search (tool_search_tool_regex/_bm25) reduces bloat at the context level (only relevant schemas load) but does not reduce bloat at the permission level — a deferred-loading tool is still callable once discovered. Don't confuse "not in context yet" with "not authorized."
• Decision heuristic: When a scenario asks "what tools should this agent have," the right-sized answer is always the minimum set for the stated task, explicitly enumerated — never "the full toolset, disable what's risky." A distractor that "adds monitoring/logging around a bloated toolset instead of narrowing it" is a compensating-control trap: it doesn't fix the actual over-privilege.

Objective: Analyze authentication and authorization requirements to identify security gaps

• Core concept: Authn (who is this) and authz (what can they do) are separate concerns in agent architectures, and secrets must never enter the sandbox where model-generated code executes.
• Anthropic-platform specifics:
  • Vaults are the first-class credential mechanism for Managed Agents — MCP credentials (mcp_oauth with auto-refresh, or static_bearer) keyed by server URL, and environment_variable credentials keyed by env-var name for non-MCP APIs/CLIs. The sandbox sees only an opaque placeholder; the real secret is substituted at egress, after the request leaves the sandbox — so even a prompt-injected or hallucinated cat of the env var can't exfiltrate it.
  • environment_variable credentials additionally take a networking.allowed_hosts scope and an injection_location (header/body) — narrowing where a secret can be sent is a second, independent security control from whether it can be sent. A credential with allowed_hosts unset (unrestricted) is a broader grant than one scoped to the specific API host.
  • Two networking layers must both allow a host — the credential's allowed_hosts and the environment's own networking.allowed_hosts (for limited environments). Missing either layer means the secret-substituted request simply fails; this is a common "why isn't my agent's API call working" root cause.
  • GitHub repo access via github_repository resources routes authorization_token through an Anthropic-side git proxy — the token never touches the container filesystem, only git/GitHub REST calls against that repo are authenticated.
  • When vault credentials don't fit (self-hosted sandboxes don't yet support environment_variable credentials), the fallback is a custom tool executed host-side — your orchestrator holds the real credential and never hands it to the sandbox, responding to agent.custom_tool_use with user.custom_tool_result.
  • Anti-pattern: embedding API keys directly in the system prompt or user messages as a workaround — these persist in session event history and are retrievable via the API for the life of the session. This is a durable leak, not a one-time exposure.
• Decision heuristic: "The model needs to call an authenticated third-party service" → vault credential (MCP or environment_variable) scoped to the minimum host set, never a prompt-embedded secret, and prefer a host-side custom tool over sandbox-visible credentials for anything highly sensitive.

Objective: Evaluate accuracy-latency trade-offs and justify configuration decisions

• Core concept: More reasoning/verification/tool calls generally raises accuracy at the cost of latency and token spend; the architect's job is picking the point on that curve the business SLA actually requires, and justifying it with a number, not a vibe.
• Anthropic-platform specifics:
  • Effort level (low→max) and model tier (Haiku→Opus/Fable) are the two primary latency/accuracy dials; adaptive thinking adds variable latency in exchange for better reasoning on hard sub-problems, but a "when in doubt respond directly" instruction can rein in over-triggering of thinking on easy inputs.
  • Fast mode (Opus 4.8/4.7 only, beta) trades a pricing premium for up to ~2.5x output tokens/sec — the correct lever specifically when the bottleneck is generation speed at a fixed model/effort, not when the bottleneck is reasoning depth.
  • Self-verification loops (evaluator-optimizer workflow, or Managed Agents Outcomes with a graded rubric) trade extra round-trips for materially higher correctness on generated artifacts — justified when the cost of a wrong answer (re-work, compliance failure, user-facing error) exceeds the extra latency/token cost.
  • Batches API is the extreme latency-tolerant end (up to 24h, 50% cost) — correct only when the SLA has no real-time requirement.
• Decision heuristic: A scenario stating a hard latency SLA (e.g., "must respond in under 2 seconds") should steer you toward a smaller model, lower effort, and fewer verification round-trips — not toward "add more checks to be safe," which is a plausible-but-inferior answer that ignores the stated constraint.

Objective: Analyze observability challenges and select monitoring strategies at scale

• Core concept: At scale, ad hoc print/manual inspection doesn't work — you need structured, queryable signals: token usage, cache hit rate, tool-call success/failure, latency percentiles, and (for agents) session-level traces.
• Anthropic-platform specifics:
  • Every response carries usage (input/output/cache tokens) and _request_id — log both; _request_id is what you hand Anthropic support when debugging a specific failure.
  • Managed Agents sessions have a live Console trace URL per session, plus a full event stream (span.model_request_start/end carry model_usage, agent.thread_context_compacted signals compaction events) — this is the built-in observability surface for agentic work, versus rolling your own logging for a raw API loop.
  • Webhooks (session.status_*, vault_credential.refresh_failed, etc.) are the push-based alternative to polling for state-change monitoring at scale — thin, HMAC-signed payloads; fetch the resource for full state on receipt.
  • cache_read_input_tokens == 0 across repeated requests is itself an observability signal for a caching regression, not just a cost issue.
  • Rate-limit response headers (retry-after, x-ratelimit-remaining-*) are the correct signal to drive backoff/alerting, not guessing at a fixed sleep interval.
• Decision heuristic: "How do we know if this agent fleet is healthy" → aggregate usage/cache metrics + webhook-driven state monitoring + _request_id-tagged logs, not spot-checking individual transcripts.

Objective: Design a RAG pipeline with appropriate chunking and indexing strategies

• Core concept: RAG pipeline quality is set upstream of the LLM call — by how documents are chunked and indexed — not fixed downstream by prompting.
• Anthropic-platform specifics/general RAG architecture knowledge applicable to Claude:
  • Chunk size is a trade-off: too small loses context needed to answer (a fact split across two chunks retrieves incompletely); too large dilutes relevance (a huge chunk containing the answer buried among irrelevant text scores lower and wastes context tokens once retrieved). Chunking strategy should follow document structure (headings/sections) over fixed-size splitting where the source has natural structure.
  • Indexing choice depends on data shape: dense vector embeddings for semantic/natural-language similarity; sparse/keyword (BM25-style) indexing for exact-term/code/ID lookups where semantic similarity is the wrong signal; hybrid indexing when both matter.
  • Claude's own code execution / dynamic filtering in web search/fetch (_20260209 tool variants) is a related pattern — Claude writes and runs filtering code over retrieved results before they reach context, which is a form of retrieval-quality improvement orthogonal to the vector store itself.
  • Citations (citations: {enabled: true} on document blocks) let a RAG answer point back to exact source locations — a design choice for traceability/compliance, not a chunking decision, but often paired with well-chunked documents so citation boundaries are meaningful.
• Decision heuristic: A RAG accuracy problem traced to "the right document wasn't retrieved" is a chunking/indexing problem (fix upstream); a problem traced to "the right document was retrieved but the model ignored/misused it" is a prompting/context-window problem (fix downstream). Don't apply a prompting fix to a retrieval-layer problem.

Objective: Apply retrieval strategies matched to data shape and query pattern

• Core concept: No single retrieval strategy is universally correct — match the strategy to what the data looks like and how it's queried.
• Anthropic-platform specifics:
  • Structured/tabular data with precise lookup queries (exact IDs, dates, numeric filters) → traditional DB query / keyword search, not semantic vector search (semantic similarity is the wrong tool for exact-match lookups).
  • Unstructured prose with fuzzy/conceptual queries ("what's our policy on X") → dense vector semantic retrieval.
  • Frequently-changing/live data → retrieval must hit a fresh source at query time (or a frequently-reindexed store); a stale cached/pre-embedded index is a common root cause when "new" information doesn't show up in answers.
  • RAG retrieval as first suspect after a document refresh is an official sample theme (also tagged in Domain 4): when documents are updated/replaced and answers stay stale, the first investigation step is checking whether the index was refreshed and retrieval is actually pulling the new version — not immediately assuming a model/prompting regression. This is the classic "compensating control" trap: tweaking the prompt to "try harder" instead of fixing the actual stale index.
• Decision heuristic: When a scenario says "we updated our docs but the agent still gives old answers," the best-answer investigation step is to verify the retrieval pipeline is re-indexing and pulling from the updated source — a prompt tweak or a bigger model is a plausible-but-inferior distractor that doesn't address root cause.

Objective: Evaluate connection protocols and select the appropriate integration mechanism (MCP, API/CLI, agent-to-agent)

• Core concept: Three integration mechanisms exist at different points on a standardization vs. control spectrum, and picking the wrong one either over-engineers a simple integration or under-standardizes a reusable one.
• Anthropic-platform specifics:
  • MCP (Model Context Protocol) — the standardized way to expose third-party tool capabilities (GitHub, Linear, Slack, etc.) to Claude without hand-rolling each integration. On the Messages API: mcp_servers + mcp_toolset (beta mcp-client-2025-11-20) declares the server; on Managed Agents: mcp_servers on the agent + vault-based credentials on the session. Best when you want a reusable, third-party-maintained integration and the service already has (or you can stand up) an MCP server.
  • Direct API/CLI — a custom tool wrapping a direct HTTP call or shell command. Best when the integration is bespoke/internal, you need full control over the request shape, or no MCP server exists and building one isn't worth it for a single internal use.
  • Agent-to-agent — one agent's output/delegation becomes another agent's input (multiagent coordinator/subagent roster, or one Managed Agents session's output feeding another session). Best when the "integration" is actually delegation to a differently-specialized agent, not a data/API integration at all.
  • MCP tool outputs over 100K tokens are automatically offloaded to a sandbox file with a truncated preview + path — architecturally relevant when designing around large third-party tool responses.
• Decision heuristic: "We need Claude to use GitHub/Linear/Slack the way many teams already do" → MCP (don't hand-roll a custom API wrapper for a solved, standardized integration). "We need Claude to hit our own internal, non-standardized service" → direct API/CLI custom tool. "We need a specialized agent's output to become another agent's task" → agent-to-agent/multiagent, not a tool call at all.

Objective: Evaluate progressive discovery vs. monolithic context strategy

• Core concept: Progressive discovery loads capabilities/context only when relevant (on-demand); monolithic context loads everything up front. Progressive discovery scales; monolithic context is simpler but degrades as the tool/knowledge surface grows.
• Anthropic-platform specifics:
  • Tool search (tool_search_tool_regex_20251119 / _bm25_20251119) with other tools marked defer_loading: true is the canonical progressive-discovery pattern for large tool libraries — schemas are appended to context only when discovered, which also preserves the prompt cache (appending doesn't invalidate the way swapping the tool list does).
  • Skills are progressive discovery for instructions: the short description sits in context by default; the full SKILL.md body loads only when the task calls for it — versus concatenating every possible instruction set into one static system prompt (monolithic).
  • Monolithic context is the right choice at small scale (a handful of tools/short reference material) where the overhead of a discovery mechanism isn't justified — progressive discovery is a scaling technique, not a universal best practice to apply everywhere.
• Decision heuristic: "We have 200 tools but any given task uses 3-5 of them" → progressive discovery (tool search + defer_loading). "We have 5 stable tools every request needs" → monolithic (just declare them all — added discovery machinery would be unnecessary complexity, an over-engineering distractor in the other direction).

How to think through the question

This is the heaviest domain on the exam and the one where the plausible wrong answer is most often a compensating control: something that observes, logs, or works around a problem instead of removing it.

Signal words to look for

Reasoning procedure

1. Write down what the agent actually has to do in this scenario, then enumerate the minimum tool and permission set that covers it. Reject any option phrased as enable the full set and turn off the dangerous one.
2. If a secret appears anywhere, ask where it lives at rest and at egress. The answer is never the system prompt, because prompts persist in session history and stay retrievable.
3. If a latency or accuracy constraint is stated numerically, apply it as a filter over the options before judging which one is technically most elegant.
4. For a retrieval question, classify two things before choosing: the shape of the data and the shape of the query. Mismatching those is this domain's signature distractor.
5. For a stale answer after a content update, check re-indexing and retrieval before touching the prompt or the model.
6. For an integration mechanism, ask whether the target is standardized and reused by many, bespoke and internal, or actually another agent, and pick accordingly.
7. Before settling, check whether your chosen option removes the problem or merely watches it. Prefer the one that removes it.

Worked example

A code review agent needs to read a diff and post review comments on a pull request. The team gives it a broad shell tool so it can run any git or network command it needs, and adds audit logging of every command it runs. A reviewer asks whether this is acceptable.

Start from the stated need: read a diff, post comments. That is two well defined actions.

Now measure the grant against it. A broad shell tool is enormously wider than two actions, and it hands the harness nothing but an opaque command string, so the harness cannot gate one action and allow another, cannot render a confirmation that means anything, cannot audit at the level of intent, and cannot tell a parallel safe read from a destructive write. The audit logging is the tell: it is a compensating control layered over an over-privileged design, and it detects rather than prevents.

The correct shape is a narrow custom tool for posting a comment, read access for the diff, no shell grant at all, and a human confirmation policy on anything consequential that remains. Notice also that deferring a tool from context is not the same as withholding authorization: a deferred tool is still callable once discovered, so tool search is a context optimization and not a permission control.

Exam traps (Domain 3)

• Compensating controls instead of the root fix: enabling a broad toolset then adding monitoring/audit logging around it, instead of narrowing the toolset to least-privilege in the first place.
• Prompt-tweak-first after a document refresh: treating stale RAG answers as a prompting/model problem and trying to "instruct it to look harder," instead of first verifying the retrieval index was actually refreshed.
• Semantic search for exact-match queries: recommending vector/semantic retrieval for structured/exact-ID lookups — a plausible-but-inferior distractor because it "sounds like RAG" but is the wrong tool for the data shape.
• "Add more verification steps" under a hard latency SLA: ignoring a stated latency constraint in favor of an accuracy-maximizing answer that would blow the SLA.
• Credentials placed in the prompt/system message "for simplicity": a durable-leak security gap — the correct answer is always a vault/host-side-custom-tool pattern.
• Building custom MCP-equivalent plumbing for a standardized integration: over-engineering when a ready MCP server already covers the need.
• Applying progressive discovery to a small, stable tool/context set: unnecessary complexity when monolithic context is simpler and sufficient at that scale.