Integration
Eight objectives, 19% of the marks — the heaviest domain on the exam, with RAG pipeline design called out by name in the official guide. Integration is where a design meets production reality: tools with too much power, credentials with too much scope, latency budgets set by wishful thinking, retrieval pipelines that break when the corpus changes. This page covers the eight objectives in exam-guide order, with the decision tables the scenarios are written against.
Integration is the domain where the professional tier shows its teeth: every objective is a production failure the industry has already lived through. An agent with tools it never needed. A credential that let a helper act as the user it served. A latency budget that assumed the model call was the only cost. A RAG pipeline that served stale chunks after a document refresh with nobody the wiser. The exam’s scenarios are these systems at the moment of decision, and every one of them has a wrong answer that sounds diligent.
01Capability bloat: least privilege for tools
The official sample question for this domain is the thesis: a support agent that can read tickets, draft replies, issue refunds and delete accounts, used by staff who only ever read and draft. The right answer is to remove the refund and deletion tools entirely — not log them, not wrap them in confirmation dialogs, not hope a bigger model follows instructions more obediently. That is least privilege applied to agent configuration: every capability an agent holds is attack surface and accident surface, and the controls the exam distinguishes are real but second-best — logging is a detective control (it tells you what went wrong after), confirmation prompts are compensating (they depend on a tired human reading carefully at 4pm), while removal is the only answer that eliminates the risk.
The audit the objective asks for is a discipline: list every tool with its blast radius (read? write? spend? delete? external side effect?), map each to the role that genuinely needs it, and cut what the map cannot justify. Two exam-ready corollaries. Tool quality beats tool quantity: twenty overlapping tools make the model’s choice harder and the failure modes stranger than five well-separated ones with clear descriptions. And scope narrow enough to verify: a tool that can “update the customer record” is harder to govern than three tools that each change one field — the exam calls the first capability bloat even when the count is small.
02Authentication and authorization: finding the gaps
Agents break the assumptions traditional auth was built on, and the exam wants you to find where. The two questions to run over any scenario. Who is authenticated? An agent acting with its own service identity is a different principal from one acting on behalf of a user — and the difference decides what its actions should be allowed to touch. Delegation without scoping is the classic gap: the agent borrows the user’s full permissions to do a narrow job, so the narrow job inherits the user’s entire blast radius. What enforces authorization — and at which layer? Prompt instructions are advice; tool-layer and gateway policy are enforcement; the database’s own grants are the last line. A scenario whose enforcement lives only in the prompt has a gap the exam expects you to name.
The gap patterns worth memorising, because scenarios are written directly against them: over-broad credentials (a read-only summariser holding read-write keys to the whole system of record); missing token scoping (long-lived tokens where short-lived, narrowly scoped exchanges exist); the confused deputy (an agent acting for user A with authority granted by configuration meant for user B); and unvalidated inbound identity (an MCP server or tool endpoint trusting whatever the caller claims). The professional answer shape is always the same: name the layer where enforcement actually sits, scope to the task, prefer short-lived narrowly-scoped credentials, and audit what the agent can reach — not what it was told to reach.
03Accuracy–latency trade-offs
The objective has two verbs: evaluate and justify. Any of these levers trades one against the other, and the exam hands you a scenario, a constraint (“interactive, users wait”), and asks which lever and why. The levers: model tier (smaller is faster and cheaper, with an accuracy ceiling you must have evaluated); retrieval depth k (more retrieved chunks can raise recall and slow the prompt and dilute attention — more context is not monotonically better); reranking (a second pass that reorders candidates by relevance — accuracy up, one more hop of latency); thinking budget (reasoning improves hard answers at the direct price of time-to-answer); and streaming (which improves perceived latency without touching the underlying work). Justify means quantify: “p95 under four seconds at 92% accuracy on the live sample, versus six seconds at 94% — the SLA says four, so we take the reranker off the hot path and batch it.” That sentence is an exam answer assembled.
| Lever | Accuracy effect | Latency effect | Use when |
|---|---|---|---|
| Smaller model tier | Down on hard cases — eval first | Down, often sharply | Volume lanes with evaluated headroom; interactive paths near their SLA |
| Retrieval depth (k) | Up to a point, then dilution | Up with every chunk | Tune against the eval; more is a hypothesis, not a virtue |
| Reranking pass | Up on precision | One extra stage | Retrieval quality is the bottleneck and the budget tolerates a hop |
| Extended thinking | Up on multi-step reasoning | Materially up | Answers must follow from reasoning; not for extraction or routing lanes |
| Streaming output | None on quality | Perceived time-to-first-token down | Any interactive surface; costs nothing else |
04Observability at scale
At pilot scale you read the logs when something feels wrong. At production scale the system must tell you — which is why this objective pairs “challenges” with “strategies”. The minimum per-request record the exam expects you to design: the input (or its digest, privacy permitting), the output, the usage object (input tokens, output tokens, cache reads and writes — billing and debugging ground truth), latency (and where it went), tool calls made and their results, and errors with their retry/fallback behaviour. Around it: correlation IDs that follow one logical task across orchestrator, retrieval, model and tools; structured logs machines can query rather than prose humans must grep; and metrics that answer the standing questions — p95 latency (the tail is the user), error rate by class, cost per task, cache-hit rate, and quality scores from whatever live-sampling eval you built in Domain 4.
The “at scale” part is its own design problem: volume forces sampling (log every request’s metadata, a sample of full payloads), retention tiers (hot for days, sampled for months — with privacy rules from Domain 5 applied to what you keep), and dashboards that page on symptoms users feel, not on internal counters. The exam’s trap here is the observability gap disguised as diligence: systems that log everything and can answer nothing, because nobody planned what question the logs were for. Design backwards from the incident you will eventually have: “RAG went stale after a corpus refresh” must be answerable from what you record — retrieval scores over time would have shown the step change.
05Designing the RAG pipeline
Retrieval-augmented generation is this domain’s named centrepiece, and the exam treats it as a pipeline of design decisions, each a scenario waiting to happen. The stages, in order:
Collect and clean source documents: formats, duplicates, access controls carried through (a document a user cannot read must not be retrievable for them — a Domain 5 question wearing a Domain 3 costume), and a change log so you know what moved.
Split documents into retrieval units. The decision: small chunks retrieve precisely but lose surrounding context; large chunks carry context but blur relevance and cost tokens. Structure-aware splitting (headers, sections) beats fixed character windows almost everywhere.
Turn chunks into vectors and index them — dense vector index for meaning, keyword/BM25 for exact terms, metadata (source, date, owner, ACLs) for filtering. Hybrid beats either alone on most real corpora.
At query time: expand the question if needed, fetch top-k candidates, ideally filter by metadata first so retrieval respects access and freshness.
A relevance pass over candidates — more expensive, materially more precise; a latency-budget decision (the table above).
Assemble context and question into the prompt, generate with citations grounded in the retrieved chunks, and refuse when retrieval came back thin — “answer only from what you were given” is the instruction; refusing on empty retrieval is the behaviour worth designing.
| Chunking strategy | How it works | Strengths | Watch for |
|---|---|---|---|
| Fixed-size windows | Every N characters/tokens, some overlap | Simple, predictable | Cuts mid-thought; sections lose their headers; the exam’s “naive default” |
| Structural / recursive | Split on document structure — headings, sections, paragraphs — with size caps | Chunks carry meaning and their headers; the usual right answer | Needs parsers per format; degrade gracefully on messy sources |
| Semantic | Split where embedding similarity drops — topic boundaries | Chunks are topically coherent | Extra processing cost; overkill for well-structured documents |
| Document-level / parent-child | Retrieve small precise chunks, generate with their larger parent context | Precision at retrieval, context at generation — often the best of both | Index design is more work; token budget for parent blocks |
06Retrieval strategy matched to data shape
“RAG” names one strategy — semantic vector search — but the objective is broader: match the retrieval mechanism to the data’s shape and the query’s pattern, and the exam will offer you vector search where a lookup belonged. The matching table:
| Data shape / query pattern | Right strategy | Why |
|---|---|---|
| Exact identifiers — order numbers, SKUs, accounts, dates | Keyword/BM25 or structured lookup with metadata filters | Embeddings blur exactly the tokens that must match exactly; “find invoice 40-2217” is a lookup, not a similarity question |
| Meaning-based questions over prose — “what’s our policy on remote work?” | Dense vector retrieval over embedded chunks | The vocabulary of question and answer differ; similarity is the right primitive |
| Mixed corpora, mixed questions | Hybrid: dense + keyword, then rerank | Real traffic contains both shapes; single-strategy loses whichever half it cannot serve |
| Fresh operational data — stock, status, balances | Tool/API call at generation time | Anything indexed is already stale; live lookups are the only fresh truth |
| Small stable corpus (fits the window) | Long context, no retrieval | Under a few dozen documents, putting them in the prompt — cached — beats building and maintaining a pipeline |
07Connection protocols: MCP, API/CLI, agent-to-agent
The objective names three integration mechanisms, and the exam asks you to choose between them and justify the choice. The decision logic: when you control both ends and the need is narrow, call the API directly (or wrap it in a CLI) — fewest moving parts, full control, no protocol overhead. When the consumer changes — many clients, multiple hosts, third-party systems exposing tools, resources and prompts — the Model Context Protocol is the standard: one server describes its capabilities; any MCP-capable host discovers and uses them; transports are stdio for local processes and HTTP for remote services. When what you are connecting is not a system but another agent — independent, possibly cross-team or cross-vendor, with its own harness and lifecycle — agent-to-agent protocols apply, and the design questions become capability discovery between peers and trust boundaries between owners.
08Progressive discovery vs monolithic context
The last objective is the quiet one that ties the domain together: when a task needs knowledge, do you put it in the context up front (monolithic — everything the model might need, one prompt) or let the model fetch what it needs as it works (progressive discovery — tools, MCP resources, Skills, retrieval on demand)? Monolithic is predictable: the same information is always present, behaviour is easier to test, and caching can carry the stable bulk — but it is expensive on every request, goes stale when the world moves, and hits the window ceiling. Progressive is economical and fresh: context carries an index of what exists, and the details load on demand — the Skills model from Domain 2, generalised. Its price: more moving parts, an extra failure mode (the fetch fails or fetches the wrong thing), and behaviour that depends on what the model chose to look at — which makes evaluation harder (Domain 4 again).
The discriminating questions, exam-ready: How large is the knowledge, and how often is any given piece needed? (Large and rarely — progressive; small and constantly — monolithic, cached.) How fresh must it be? (Live facts argue for fetch-time retrieval.) How predictable must runs be? (Fixed-context systems are reproducible in a way fetch-dependent ones are not.) And can you observe and evaluate the fetches? (Every hop is telemetry and a possible failure the eval must cover.)
09The traps
- —“Log it instead of removing it.” Detective controls on unnecessary capability are the sample question’s designated wrong answer; elimination beats observation.
- —“The agent inherits the user’s permissions.” Delegation without scoping is the auth gap; borrow the minimum, not the identity.
- —“Latency is the model call.” Retrieval, reranking, tool hops and thinking budgets are all on the clock; budgets set from the model call alone fail on contact with users.
- —“One big index for everything.” Fresh operational data does not belong in an index; exact identifiers do not belong in embeddings; match strategy to data shape.
- —“MCP because it’s the standard.” Indirection is bought with portability you will use; otherwise a direct API is the cleaner answer.
- —“We’ll add observability after launch.” The incidents this domain describes are only diagnosable from data you decided to record months earlier.
A team’s research agent can search the web, read the internal wiki, create tickets in Jira, and merge code to production branches. Researchers only ask it to investigate and write findings. Leadership wants “audit logging on every action” after a near-miss. What is the architect’s strongest recommendation?
- ARemove the ticket-creation and merge-to-production tools from the agent entirely, keep logging on what remains
- BAdd the logging as requested and move on
- CAdd confirmation dialogs before merges
- DMove the agent to a larger model so it follows its instructions more reliably
→Check your answer
Least privilege: the role needs read-and-draft, so write-and-deploy capabilities go — eliminated, not monitored. Logging (B) and confirmations (C) are the named second-best controls; model size (D) does not narrow an authorization scope.
A RAG system suddenly returns confident but incorrect answers. Nothing changed in prompt, model or latency — but the document corpus was refreshed last night. Where do you investigate first?
- AThe model weights changed silently
- BThe temperature setting
- CThe retrieval and indexing step — re-indexing after the refresh, chunk integrity, embedding consistency
- DThe context window size
→Check your answer
The official sample question’s lesson: symptoms that appear exactly when the corpus changed, with model and latency unchanged, point at retrieval — a broken or partial re-index, or mismatched embeddings. The other options do not trigger on a document refresh.
An internal assistant must answer “where is order 88412?” and “what does our refund policy say about gifts?” from the same interface. What is the right retrieval design?
- AEmbed everything — orders and policies — in one vector index
- BKeyword-only search over both corpora
- CLong context: put the order database and the policy manual in the system prompt
- DHybrid: structured lookup with metadata filters for order identifiers, dense retrieval over embedded policy documents
→Check your answer
Data shape decides: exact identifiers want lookup and filtering (embeddings blur the tokens that must match exactly), meaning-based prose wants dense retrieval. One interface, two strategies. Monolithic context (C) cannot hold a live order database, and keyword-only (B) misses the paraphrase gap on policy questions.
You control both the consumer and the target system; the integration is one team’s internal tool with no third-party clients planned. Which mechanism fits?
- AAn MCP server, for standards compliance
- BDirect API integration (or a thin internal CLI), because you own both ends
- CAn agent-to-agent protocol between the consumer and the system
- DPublish the capability to a public tool registry
→Check your answer
MCP’s value is discovery and portability across many consumers; with none planned, protocol indirection is pure overhead. A2A (C) connects independent agents, not a consumer to a system it owns; a public registry (D) adds a trust boundary where none is needed.
A support copilot has a 3,000-page product manual, any page of which might matter to a ticket. Interactive latency matters. Which context strategy fits?
- AMonolithic: put the manual in the system prompt with prompt caching
- BAsk the model to guess from its pretrained knowledge and correct it later
- CProgressive discovery: index the manual, retrieve the relevant chunks per ticket, with metadata filters and a reranker if the latency budget allows
- DHave humans bookmark the fifty most-used pages and paste them in
→Check your answer
Large knowledge, rarely any given piece needed, interactive surface: the progressive pattern. Monolithic (A) prices 3,000 pages onto every request and staleness into every revision; guessing (B) is the hallucination scenario; manual pasting (D) does not scale and quietly rots.
An agent acts for logged-in users across three internal systems. Security review asks how to tighten authorization. Which answer is professionally correct?
- AThe agent uses each user’s full credentials for everything, since the users could do it anyway
- BScope tokens to the task: short-lived, narrowly-scoped credentials per system, enforcement at the tool layer, and the database’s own grants as the last line
- CStrong instructions in the system prompt to only take appropriate actions
- DOne powerful service account, rotated quarterly
→Check your answer
Delegation must be narrower than the user, enforcement must sit in layers outside the prompt, and a single god-account (D) makes every user’s actions indistinguishable and unaccountable. Prompt instructions (C) are advice, not authorization.
Which observability design answers “did retrieval quality drop after last week’s corpus refresh?”
- AFull prompt/response logs kept seven days, then deleted
- BPer-request metrics including retrieval scores and citations, with correlation IDs across retrieval and generation, retained long enough to see the step change
- CAggregate token counts and cost dashboards only
- DA weekly manual review of three sample conversations
→Check your answer
The question is about a quality trend at a point in time: you need retrieval-level signals (scores, hit rates, citations) captured per request, correlated, and retained across the refresh date. Costs alone (C) and casual sampling (D) cannot see it; short retention (A) deletes the evidence.