Skip to content
Domain 3
19%

Quick Reference: Domain 3 — Integration

Durable versus dated. Every named figure, limit, status code, and protocol version on this page is a snapshot as of mid-2026, and all of them move: prices change, thresholds get re-benchmarked, spec revisions supersede each other. The selection logic does not move. Learn the reasoning, treat the numbers as illustration, and re-verify anything you plan to quote against the live documentation.

Capability Bloat (3.1)

Least privilege applied to agent capabilities. Every tool the role never needs costs twice: attack surface (if it is wired, the capability exists) and context weight that, in a large catalogue, degrades tool selection. Evaluate from the role's task list, never from the platform's capability list.

The control ladder, best to worst:

Offered controlCategoryWhat it cannot do
Remove or scope the toolEliminationNothing — the risk stops existing
Confirmation promptCompensatingGuards a capability that should not exist
Audit loggingDetectiveFinds abuse after the damage
System-prompt prohibitionInstructionConstrains behaviour, not capability
A larger modelIrrelevantModel tier has nothing to do with authorisation scope
  • The guide's own Domain 3 sample keys removal, and plants logging, a confirmation prompt, and a bigger model as its three distractors. Name the category and the elimination is mechanical.
  • Consolidate what survives. Overlapping or vaguely-purposed tools confuse selection even when each is individually justified. Namespace related tools under common prefixes.
  • Mid-2026 snapshot: tool selection accuracy degrades once a toolset exceeds 30–50 available tools; a typical five-server catalogue (GitHub, Slack, Sentry, Grafana, Splunk) consumes roughly 55k tokens of definitions before any work begins. Anthropic's documented triggers for deferring the catalogue instead: 10 or more tools, definitions above 10k tokens, or aggregated MCP servers (200+ tools). Standard non-deferred loading remains the right call below 10 tools, when every tool is used on every request, or when definitions total under 100 tokens.

Authentication and Authorisation Gaps (3.2)

Authentication answers who is calling; authorisation answers what they may do. Most planted gaps are authorisation gaps wearing an authentication costume, so MFA and SSO options are distractors whenever the stem describes an over-broad scope. Analysis method: list the hops (user → client → agent → each tool → each downstream system), then ask at every hop who the far side believes is calling and what that identity can reach. The gap is wherever effective privilege exceeds the requesting user's legitimate need.

  • Confused deputy: one over-privileged service account serving many users. Fix by propagating the authenticated user's identity onto every tool call and scoping each read and write to that user. Attribution into the audit trail comes free with it.
  • Secrets never meet the model. Prompts are logged, cached, and echoable, so a credential in model-visible context is published. Store in a secrets manager, inject at the tool boundary, scope to the minimum resource and lifetime. On discovery of a leak: rotate first, then move the privileged call behind a backend the client cannot bypass.
  • Token passthrough is forbidden, not discouraged. The MCP authorisation specification requires servers to accept only tokens valid for their own resources, and forbids accepting or transiting any others. Passthrough breaks audience validation, corrupts attribution, bypasses controls keyed to the token, and lets a stolen token travel.
  • Mid-2026 snapshot: HTTP-transport MCP servers authenticate with OAuth 2.1 (draft-ietf-oauth-v2-1-13); servers must implement protected resource metadata (RFC 9728) and clients must send the resource indicator (RFC 8707) plus PKCE. stdio servers take credentials from the environment rather than following the authorisation spec at all.
  • Status codes worth recognising: 401 Unauthorized (authorisation required or token invalid, carrying WWW-Authenticate: Bearer resource_metadata="..."), 403 Forbidden (error="insufficient_scope" plus the scope needed for the operation), 400 Bad Request (malformed authorisation request). Scopes start minimal and elevate incrementally through step-up authorisation.

Accuracy–Latency Trade-offs (3.3)

Two numbers, held at once. Latency is a sum, so decompose before touching anything: time-to-first-token and generation length per model call (thinking included), each retrieval and reranking stage, each serial tool round-trip, each loop iteration. Only genuinely independent calls parallelise.

LeverBuysCostsWrong when
Smaller model tierLatency, costUnmeasured accuracyDownsizing without re-running evals
Fewer input/output tokensLatency, costContext or detailThe trimmed content was load-bearing
StreamingPerceived latency onlyNothingThe consumer is a parser or batch job
Cached stable prefixCost and time-to-first-tokenNothing, when the prefix is stableVolatile content sits in the prefix
Reranking, verificationMeasured accuracyLatency on every request it runsApplied blanket where only a subset is high-stakes
  • Value- or risk-based routing is the recurring keyed answer: the expensive path for the high-stakes subset, a fast path for the bulk. It holds the SLA and the quality bar together rather than trading one away.
  • The justification names both numbers, with a source for each: traces supply the p95, evals supply the accuracy bar. "Faster is better" is not a justification.
  • Mid-2026 snapshot: cache reads bill at 0.1× base input price on most models, roughly 90% off, which documents the cost side of the caching win precisely (as of October 2026, Opus 5.5 and Sonnet 5.5 read at 0.05×, Fable 5.1 and Mythos 5.1 at 0.025×). The latency side is documented only as improved time-to-first-token, with no published percentage, so measure your own path rather than quote a figure. Anthropic's latency guidance likewise gives an order (model choice, then token trimming, then streaming) and no percentages. Domain 2 owns the full cache mechanics: write multipliers, TTLs, and minimum cacheable prefix lengths.

Observability at Scale (3.4)

Non-determinism breaks anecdote debugging: the same input can produce different outputs, so a re-run proves nothing in either direction. The trace is the unit of observability.

  • Trace fields, per request: prompt version, model id, retrieved context, tool calls and their results, token usage, cost, latency, response, and a correlation id stitching pipeline stages or loop iterations into one record.
  • Two tiers at scale: cheap aggregates on every request (latency percentiles, token spend, error and refusal rates, tool-failure rates); expensive full payloads on a sample plus every detected failure. Nobody reads a million traces, and logging everything forever fails on cost and on privacy at once.
  • Quality is not an infrastructure metric. A hallucinating system is "up". Automated scoring of sampled production traffic, calibrated against Domain 4's formal evals, is what makes answer quality alertable.
  • Alert on tail percentiles, not means. A stable mean hides a doubled p99, and the tail is who files tickets. Drift shows up first in token spend per request, refusal rate, tool-failure rate, and input-length distribution.
  • Mid-2026 snapshot of the platform instruments: /v1/organizations/usage_report/messages takes bucket_width of 1m, 1h, or 1d (defaults 60/24/7 buckets, maxima 1,440/168/31), and groups or filters by api key, workspace, model, service tier, context window, inference geo, and — in beta — speed. /v1/organizations/cost_report is daily buckets only, in USD. Data typically appears within 5 minutes of request completion, and sustained polling is supported at once per minute. Both need an Admin API key (sk-ant-admin01-...), unavailable to individual accounts; Claude Enterprise organisations use the Analytics API instead.

RAG Pipeline Design (3.5)

Stages with failure modes: ingest → chunk → embed → index → retrieve → (rerank) → generate. Generation quality is capped by retrieval quality, so grounding failure upstream surfaces as hallucination downstream. Diagnosis runs the pipeline backwards.

  • Chunking is a trade-off, not a setting. Too small strips the context a passage needs; too large dilutes relevance and pays for padding. Respect document structure (sections, headings, tables) with modest overlap, rather than fixed character counts.
  • Contextual retrieval prepends a brief, chunk-specific explanation situating each chunk in its document before embedding, attacking the root cause: chunks that lost their context at the boundary.
  • Index hybrid by need: embeddings for meaning, keyword/BM25 for exact identifiers (part numbers, error codes, clause references defeat pure vector search), metadata filters to narrow before similarity ranks.
  • Freshness is an operational property. A refresh triggers re-embed and re-index atomically; the embedding-model version is pinned identically for corpus and queries, because a mismatch degrades silently; retrieval recall on a labelled set is monitored so index breakage alerts instead of surfacing as user complaints. Measure retrieval separately from generation, or failures cannot isolate to a stage.
  • Mid-2026 snapshot of Anthropic's published contextual-retrieval benchmark: contextual embeddings cut the top-20-chunk retrieval failure rate by 35% (5.7% → 3.7%); adding contextual BM25 takes it to 49% (→ 2.9%); adding reranking takes it to 67% (→ 1.9%). The reference configuration retrieves the top 150 chunks and reranks down to the top 20. One-time contextualisation costs about $1.02 per million document tokens. And below roughly 200,000 tokens (about 500 pages) the whole corpus fits in a cached prompt, which is faster, cheaper, and has no retrieval failure mode at all.

Retrieval Strategy Matching (3.6)

Match on two axes, then apply the tiebreaker: name the failure that matters most (staleness, missed recall, wrong precision, latency) and pick the cheapest strategy whose failure mode is acceptable.

Data shapeNative strategyWhy not the alternative
Live structured (databases, catalogues, records)Query tool against the system of recordEmbedded rows are stale on indexing and structure-blind
Narrative documents (policies, manuals)Semantic retrieval over chunked textNo query language exists to hit precisely
Code and rigid formatsStructure-aware or agentic searchExact symbols and cross-references defeat similarity
Small and stable, high valueCached prompt, no retrievalA pipeline with no beneficiary
Query patternCue in the stemNative strategy
Exact lookupAn identifier: part number, error code, clauseKeyword or filtered search
Conceptual"Summarise", "what is our policy on"Semantic retrieval
Multi-hop / exploratoryComparison across documents, unknown pathAgentic retrieval: search, read, refine, search again
Recall-critical"Must not miss a relevant document"Hybrid search plus reranking
  • Mixed designs are keyed more often than pure ones. One estate routinely runs an API tool for the live lookup, semantic retrieval for the manual, and agentic retrieval for the cross-document comparison.
  • Agentic retrieval spends latency and tokens to buy precision no single query can reach: justified for exploratory and comparative work, prestige spending on a lookup a metadata filter would answer in one hop.
  • Mid-2026 snapshot: recall-critical corpora justify hybrid plus reranking on the numbers above (the 67% failure-rate reduction is the stacked configuration), and the 200,000-token / ~500-page boundary is where "no retrieval at all" stops being an option.

Integration Mechanisms (3.7)

Count the consumers, then ask whether the far side reasons. The keyed answer follows the consumer pattern in the stem, never the sophistication of the mechanism.

MechanismSelection cueWrong when
MCP serverCapability reused across surfaces, teams, clientsOne consumer, no sharing ambition
Direct API/SDKOne application, its own loop, full controlA second surface or team appears
Headless (SDK or CLI)Pipelines, CI, cron — a script parses the outputA human interactive surface is the consumer
Agent-to-agentThe counterpart reasons and decides for itselfThe counterpart executes a fixed operation
  • MCP collapses M×N to M+N. Build the server once, and every client connects. Invert the cue and it inverts the answer: a server for a single consumer is standing infrastructure and auth surface bought for no reuse.
  • Transports are deployment topology, not protocol choice. "We need HTTP so we cannot use MCP" is planted confusion.
  • Mid-2026 snapshot: the current MCP protocol revision is 2026-07-28. Revision ids are YYYY-MM-DD strings that only advance on a backwards-incompatible change. Two standard transports are defined: stdio (newline-delimited messages over a client-launched subprocess's standard streams) and Streamable HTTP (each message an HTTP POST to one endpoint, replies as a JSON object or a request-scoped SSE stream). The protocol version travels in _meta.io.modelcontextprotocol/protocolVersion and is mirrored into the MCP-Protocol-Version header on Streamable HTTP; an unsupported version comes back as UnsupportedProtocolVersionError. Revisions 2025-11-25 and earlier are the initialize-handshake era and need the documented backward-compatibility path. Deprecated features stay in the specification at least 12 months (or 90 days under the expedited-removal exception) before they may be removed.

Progressive Discovery vs Monolithic Context (3.8)

Two postures, neither correct by default. Monolithic loads everything upfront: one round trip, no discovery machinery, and a stable prefix the cache makes nearly free. Progressive discovery loads capability on demand and pays in round trips and moving parts.

Four decision cues:

  • Surface-to-slice ratio. Large surface, small per-request slice favours discovery; small surface used whole favours the monolith.
  • Frequency. Capability in nearly every session belongs upfront where the cache pays for it; the long tail belongs behind discovery.
  • Latency. Every discovery hop is a round trip, and dependent hops serialise. A tight interactive budget caps how many the path affords.
  • Stability. Stable content upfront compounds with caching; volatile content upfront churns the cache.

The hybrid is usually the keyed answer: a small, stable, hot core loaded and cached, with tool search for the catalogue, Skills for procedures, and retrieval for knowledge behind it. "The window is big enough, load everything" is the seductive distractor, and capping the surface abandons a stated growth requirement rather than architecting for it.

  • Mid-2026 snapshot, the threshold the lesson defers to: Anthropic documents that Claude's ability to pick the right tool degrades once you exceed 30 to 50 available tools, and names the triggers for reaching for tool search: 10 or more tools, definitions over 10k tokens, selection accuracy dropping as the toolset grows, aggregating multiple MCP servers (200+ tools), or a library that grows over time. Standard tool calling suits fewer than 10 tools, every tool used on every request, or definitions under 100 tokens in total.
  • Mid-2026 snapshot, tool search: cuts definition context by over 85%, loading only the 3–5 tools a request needs. Deferred definitions stay out of the system-prompt prefix, so prompt caching survives. The limits worth knowing: keep your 3–5 most-used tools non-deferred; at least one tool must have defer_loading: false, or the request fails 400 ("All tools cannot be deferred"); up to 10,000 deferred tools per request; each search returns up to 5 tools by default; regex patterns cap at 200 characters, BM25 queries at 500. A deferred tool cannot also carry cache_control (another 400), so put the cache breakpoint on a non-deferred tool.
  • Mid-2026 snapshot, Skills progressive disclosure: metadata (name plus description) always loaded at roughly 100 tokens per Skill, the SKILL.md body under 5k tokens on trigger, bundled resources nothing until read, and scripts contributing only their output. name caps at 64 characters, description at 1,024.