Domain 3 – Integration (19%) – Highest weight

• Detect and prevent capability / tool bloat
• Authentication & authorisation gap analysis
• Accuracy vs latency configuration decisions
• Observability strategies at enterprise scale
• RAG pipeline design (chunking, indexing, retrieval strategy matched to data shape)
• Connection protocol selection: MCP vs direct API/CLI vs agent-to-agent
• Progressive discovery vs monolithic context loading

CCAR-P Domain 3 · Task 3.1

What You Need to Know

Least privilege = agent gets only the tools its role needs. Capability bloat = every tool beyond that. Removal beats mitigation every time.

Every Unnecessary Tool Costs Twice

1. Security — if wired, the capability exists (prompt prohibition does not remove it)
2. Performance — every tool definition consumes context; selection degrades past a documented threshold

Start From the Role’s Task List

Judge configuration from the role’s task list, never from the platform’s capability catalogue. Build a few thoughtful tools for specific high-impact workflows.

Removal Beats Mitigation

Offered control	Category	What it cannot do
Audit logging	Detective	Finds abuse after damage
Confirmation prompt	Compensating	Adds friction to a capability that should not exist
System-prompt prohibition	Instruction	Constrains behaviour, not capability
Removing the tool	Elimination	The risk no longer exists

Consolidate What Survives

Overlapping/vague tools confuse selection. Consolidate into fewer clearly described, task-scoped tools with common prefixes.

Exam Traps

• Adding audit logging or confirmation prompt to a tool the role never needs
• Relying on system-prompt prohibition to prevent use of a wired capability
• Choosing a larger model to fix an over-privileged configuration
• Wiring the full platform catalogue “so the agent can handle anything”

Practice Scenario

Internal HR agent can read/update employee records, generate letters, export payroll. Exists solely to answer employees about their own leave balances. Best risk-reducing change?

Build Exercise: Tool-Surface Audit With Least-Privilege Justification (25 min)

CCAR-P Domain 3 · Task 3.2

What You Need to Know

Authentication = who is calling. Authorisation = what may they do. A security gap exists wherever effective privilege exceeds the requesting user’s legitimate need.

The Confused Deputy

Agent serves many users through one over-privileged service account → any user can potentially reach anything the account can.

Fix: identity propagation — tool calls carry the authenticated user’s identity; every read/write is scoped to what that user may reach.

Secrets Never Meet the Model

Prompts are logged, cached, and can be echoed. Credentials in model-visible context are published. Secrets belong in a secrets manager, injected at the tool boundary. After a leak: rotate first, then move the privileged call behind a backend the client cannot bypass.

Token Passthrough Is Forbidden

MCP explicitly forbids accepting a client’s token and forwarding it downstream. Harms: breaks audience validation, destroys attribution, circumvents rate limits, lets stolen tokens travel. Each hop authenticates for itself with its own scoped credential.

Attribution Is Architecture

Every tool invocation should land in the audit trail with user attribution (who asked, which tool, which resource). Shared API keys across users/environments = no attribution + maximum blast radius.

Key Concept: Trace the whole chain. Effective privilege is measured at every hop.

Exam Traps

• Adding MFA/SSO when the gap is over-broad scope or shared credential
• Logging all agent calls as the fix for a structural privilege problem
• Forwarding the user’s token downstream “to keep the design simple”
• Securing the client-to-agent link when the gap sits at the agent-to-downstream hop

Practice Scenario

Customer-service agent answers account questions. Calls internal accounts API with a single service credential that can read ALL customer records. What change addresses the actual gap?

Build Exercise: Identity-Chain Map, Hop by Hop (30 min)

CCAR-P Domain 3 · Task 3.3

What You Need to Know

Every integration has a latency requirement (e.g. p95) and a quality requirement. The skill is holding both at once.

The Budget Is a Sum

Latency terms: TTFT + generation, retrieval/rerank, tool round-trips, agent-loop iterations. Serial chains multiply; only independent calls parallelise. Find the dominant term first (traces).

Accuracy Levers Pull the Other Way

More context, reranking, verification, reasoning, bigger model — each adds latency. Spend selectively: verify high-value items, fast-path the rest. Never delete a control tied to a named requirement.

Streaming and Caching

• Streaming improves perceived latency for interactive humans; total generation time unchanged. Irrelevant to machine consumers/parsers.
• Prefix caching is a double win (cost + TTFT) for stable prefixes.

Justification Names Both Numbers

“Meets the stated p95 while holding the measured mis-route rate.” One-sided justifications are distractors.

Exam Traps

• Dropping verification in a compliance/safety-critical workflow to hit latency
• Offering streaming as the latency fix for a machine consumer or batch pipeline
• Running expensive verification on every request when only a subset is high-stakes
• Parallelising a chain where step B consumes output of step A

Practice Scenario

Claims-triage: must respond within 2s p95 and must not mis-route high-value claims. Current path: retrieve (600ms) + rerank (400ms) + large-model classification with verification (1.8s). Best change that meets both?

Build Exercise: Decompose a Latency Budget Against Its SLA (35 min)

CCAR-P Domain 3 · Task 3.4

What You Need to Know

LLM systems break anecdote debugging: non-deterministic, so a single re-run proves nothing. A green uptime dashboard says nothing about answer quality.

The Trace Is the Unit

Capture per request: prompt version, model id, retrieved context, tool calls + results, tokens, cost, latency, response. Correlation ids stitch multi-stage pipelines into one record.

Two Tiers at Scale

1. Cheap aggregates on every request — latency percentiles, token spend, error/refusal/tool-failure rates
2. Expensive full payloads on a sample + every detected failure — sampling rates, retention, redaction are architecture decisions

Quality Is Not an Infrastructure Metric

Uptime/error/latency can all be green while the system produces rubbish. Quality needs its own signal: automated evaluation on sampled production traffic, scored against a calibrated rubric/judge.

Drift Shows in Cheap Signals

Token spend per request, refusal rates, tool-failure rates, input-length drift. Alert on tail percentiles, not averages.

Exam Traps

• Adding more uptime/latency alerting when support reports wrong answers
• Debugging by re-running the input a few times
• Persisting full prompts/outputs for every request indefinitely
• Tracing single calls without correlation ids in a multi-stage pipeline

Practice Scenario

Document assistant: 200k requests/day, five-stage pipeline. Support reports it sometimes makes things up; engineering sees green dashboards. Need to find where each invented answer starts and how often, without waiting for users. What to build?

Build Exercise: Design the Observability Plan for One Pipeline (40 min)

CCAR-P Domain 3 · Task 3.5

What You Need to Know

RAG stages: ingest → chunk → embed → index → retrieve → (rerank) → generate. Generation quality is capped by retrieval quality.

Chunking Is a Trade-off

Too small → strips needed context. Too large → dilutes relevance. Structure-aware chunking (sections, headings, tables) with modest overlap outperforms fixed-size splitting.

Contextual Retrieval

Prepend a brief, chunk-specific explanation situating each chunk in its document before embedding. Restores context lost at the chunk boundary. Measurably cuts retrieval failures.

Index for How It Will Be Asked

• Exact strings / identifiers → BM25 / keyword
• Conceptual queries → embedding search
• Identifier-heavy corpora → hybrid (embeddings + keyword)
• Metadata filters narrow the candidate set before similarity ranks

Freshness Is Operational

• Refresh triggers re-embed + re-index atomically
• Pin the embedding-model version everywhere
• Monitor retrieval quality (recall on labelled set)
• Evaluate retrieval separately from generation

Refresh signature: quality breaks immediately after a content refresh, model and latency unchanged → investigate retrieval/indexing first.

When RAG Is Not the Answer

A corpus small and stable enough for the cached prompt is faster and cheaper served whole.

Exam Traps

• Model upgrade when answers went wrong right after a document refresh
• Retrieving more chunks to fix a stale/broken index
• Tuning chunk size without measuring where retrieval fails
• Evaluating the pipeline only end-to-end

Practice Scenario

Support knowledge base of 40k articles. After bulk content migration, answers cite outdated procedures confidently; latency and model unchanged. What first?

Build Exercise: RAG Pipeline Design Dossier (45 min)

CCAR-P Domain 3 · Task 3.6

What You Need to Know

Retrieval strategy rests on two axes: data shape and query pattern. Then name the failure that matters most and pick the cheapest strategy whose failure mode is acceptable.

Data Shape Axis

Shape	Native strategy
Live structured (DB, catalogues, accounts)	Query tool against system of record
Narrative documents (policies, manuals)	Semantic retrieval over chunked text
Code / rigid text	Structure-navigating retrieval
Small & stable	Cached prompt (no retrieval)

Query-Pattern Axis

Pattern	Cue	Native strategy
Exact lookup	Identifier (part #, error code)	Keyword / filtered search
Conceptual	“Summarise”, “what is our policy”	Semantic retrieval
Multi-hop / exploratory	Comparison, unknown path	Agentic retrieval
Recall-critical	“Must not miss a document”	Hybrid + reranking

Selection Method

1. Name the data shape
2. Name the query pattern
3. Name the failure that matters most
4. Pick the cheapest strategy whose failure mode is acceptable

One system can combine multiple strategies. Hybrid is a design answer, not a compromise.

Exam Traps

• Embedding live operational data into a vector store
• Applying one retrieval approach to every data shape
• Deploying agentic multi-hop on a simple latency-budgeted lookup
• Choosing precision/latency-first where no relevant document may be missed

Practice Scenario

Enterprise assistant must answer: current stock of part K-4402 (live ERP), summary of data-retention policy (300-page manual), how clause 14 changed across three supplier contracts (archive). Policy questions in everyday words. Which retrieval design fits?

Build Exercise: Retrieval Strategy Matrix for One Estate (30 min)

CCAR-P Domain 3 · Task 3.7

What You Need to Know

Four mechanisms connect Claude to surrounding systems:

Mechanism	Selection cue	Wrong when
MCP server	Capability reused across surfaces/teams/clients	One consumer, no sharing ambition
Direct API/SDK	One application, full control, custom loop	A second surface or team appears
Headless (SDK/CLI)	Pipelines, CI, cron — script consumes parsed output	Human interactive surface is the consumer
Agent-to-agent	Counterpart reasons and decides for itself	Counterpart executes a fixed operation

MCP Collapses M×N to M+N

Build a server once; any MCP client uses it. Transports: stdio (local subprocess) and streamable HTTP (remote, shared, multi-client). Streamable HTTP is still MCP — transport is deployment topology, not protocol choice.

Agent-to-Agent Test

Does the counterpart reason? Yes → agent. No (fixed, fully-specified operation) → plain tool call.

Key Concept: Count the consumers and surfaces. The impressive mechanism planted where the boring one is right is the signature distractor.

Exam Traps

• Standing up an MCP server for a bespoke single-consumer integration
• Ruling MCP out because deployment needs HTTP (or treating stdio as the only real MCP)
• Delegating to a peer agent whose task is a deterministic fixed operation
• Adding interactive machinery (streaming/chat) to a nightly pipeline job

Practice Scenario

Company needs: (a) ticketing system available in claude.ai, Claude Code, and an API triage service; (b) nightly agent summarising incidents into a report; (c) bespoke invoice-OCR used by exactly one billing pipeline. Which design fits?

Build Exercise: Consumer-Pattern Worksheet for Three Integrations (30 min)

CCAR-P Domain 3 · Task 3.8

What You Need to Know

Two ways to load tools, procedures and knowledge:

• Monolithic — load everything upfront (simplest; best for small stable surfaces; cacheable)
• Progressive discovery — load each piece on demand (Skills, deferred tool loading, agentic retrieval)

Progressive Disclosure Mechanisms

• Skills — metadata always; body on trigger; resources on read
• Deferred tool loading — catalogue behind search; only discovered schemas enter context
• Agentic exploration/retrieval — keep lightweight identifiers; load content as questions arise

Four Decision Cues

1. Surface-to-slice ratio — large surface, small per-request slice → discovery
2. Frequency — nearly every session → upfront (cache); long tail → discovery
3. Latency — each discovery hop is a round trip; tight budgets cap hops
4. Stability — stable content upfront compounds with caching; volatile content behind discovery

The Hybrid Is Usually the Answer

Small, stable, hot core monolithic and cached. Long tail behind discovery (tool search, skills, retrieval). Vendor-documented default: keep the handful of most-used tools loaded, defer the rest.

Key Concept: Capacity is not a strategy. Decide by the four cues, never by “the window is big enough”.

Exam Traps

• Loading everything because the window is big enough
• Keeping every tool/runbook in the prompt and relying on a cache breakpoint
• Capping tool count permanently when the surface must grow
• Deferring everything, including tools nearly every session uses

Practice Scenario

Enterprise copilot must reach 200+ internal tools and a large policy library. Typical request uses 2–3 tools and a handful of passages; 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 (35 min)