What you need to know
Integration choices sit at two levels: how your code talks to Claude (the build-time interface) and where the traffic goes (the delivery route). The exam tests both, and especially the cases where two options look interchangeable but are not.
Build-time interfaces
| Interface | What it gives you | Choose it when | Trade-off |
|---|---|---|---|
| Direct API | Raw HTTP requests and responses | You need full control, or a new feature is not in the SDK yet | You build retries, streaming and tool plumbing yourself |
| Client SDKs | The same API with typed, language-native helpers | The default for embedding Claude in a product | Your code still owns any loop or orchestration |
| Agent SDK | A managed agent loop: iteration, tool execution, termination | Claude must act over many turns inside your own application | Less control over each individual turn |
| MCP | An open protocol for exposing tools, resources and prompts from a server | The same tools must be reachable from several Claude clients | An extra protocol layer to run and debug |
| Claude Code | An agentic coding tool for engineers | The user is a developer working in a codebase | Not a backend for a customer-facing product |
Two distinctions come up again and again:
- MCP and the Agent SDK are different layers. MCP is how tools are exposed; the Agent SDK is the loop that decides when to call them. They are often used together.
- MCP versus plain tool use. If the tools live inside one product, define them directly with tool use. MCP earns its extra layer when the same tools must serve several clients (Claude Code, Claude apps, an internal portal).
Agent-to-agent
Sometimes one agent hands work to another: an orchestrator delegating to specialist subagents in the same system, or two separately owned agents exchanging tasks. Inside one system, treat it as the orchestration design from lesson 1.4, with structured results and shared trace IDs. Across organizational boundaries it is an integration contract: define the message format, authenticate both sides, limit what each agent may ask the other to do, and log every exchange.
Delivery routes
The same models are available directly from Anthropic and through major cloud platforms (for example Amazon Bedrock, Google Cloud Vertex AI and Microsoft's catalogue). Feature availability and model release timing can differ by route, so check before committing.
| Pull towards | Route |
|---|---|
| Newest features first, no cloud commitment | Anthropic's API directly |
| Existing cloud agreement, identity, network and billing on that cloud | The matching cloud platform |
| Regulated data (healthcare, government, data residency) | Whichever route is covered by the required agreement and authorization for the exact configuration |
In the exam
Integration questions name the user, what Claude must do, and a constraint. Map them: one request and one response points to the API or an SDK; multi-turn action inside your product points to the Agent SDK; tools shared across clients point to MCP; developers in a codebase point to Claude Code. Then check the delivery route against compliance and procurement. Distractors swap layers (MCP instead of an agent loop) or ignore an approved-vendor constraint.
Check your understanding
A bank wants its internal loan portal to let Claude investigate a case over several steps, calling five internal services. Only this portal will use the tools. What fits best?
Show answer
Answer: D. Multi-turn action inside the bank's own application is the Agent SDK's job. With one consumer of the tools, MCP adds a layer without reuse.
A company's ticketing tools must be usable from Claude Code by engineers and from Claude apps by support staff. What is the best way to expose them?
Show answer
Answer: C. Several clients sharing the same tools is exactly the case MCP was designed for. Copying definitions duplicates work and drifts.
Which TWO statements are correct?
Show answer
Answer: A, C. MCP and the Agent SDK are complementary layers, and procurement or compliance constraints come before technical convenience. The client SDKs leave orchestration to your code, and availability can differ by route.
Apply it: Map Quillstone's integrations
Quillstone has four AI initiatives: Claude Code for engineers, a CI bot that reviews every pull request, an incident-diagnosis agent inside the internal developer portal, and the in-product assistant for bank customers. Several of them need the same internal tools (service catalogue, logs search, deployment history).
- Choose the build-time interface for each initiative with a one-line reason.
- Decide where MCP belongs and where it does not.
Why: MCP is justified by sharing, so you have to know which tools are shared. - Name one constraint that could change the delivery route, using the case facts.
Show model answer
1. Interfaces
| Initiative | Interface | Reason |
|---|---|---|
| Engineers' coding work | Claude Code | Developers working in repositories |
| CI pull request review | Client SDK from the CI job | One request per pull request, response posted as a review |
| Incident-diagnosis agent in the portal | Agent SDK in the portal's backend | Multi-step investigation inside Quillstone's own application |
| In-product assistant for banks | Client SDK (or Agent SDK if it must act over several steps) behind Quillstone's product | Customer-facing; Claude Code is the wrong shape |
2. MCP. The service catalogue, logs search and deployment history are used by Claude Code and by the incident agent, so expose them once as internal MCP servers. The in-product assistant's tools (a bank's own accounts and reports) are used only by the product, so define them directly with tool use; they must also never be reachable from engineers' tools.
3. Delivery-route constraint. Source code may only go to vendors approved under Quillstone's SOC 2 vendor process, and the banks may require their data to stay with an approved cloud or region. Either can decide the route before any technical preference does.