Entry Points, Build-Time Interfaces, and Delivery Routes: The Third Axis of Connection

Everything covered so far in this task statement — MCP, direct API/CLI, agent-to-agent — answers one question: mechanically, how does Claude reach a given capability? There is a second, related, but genuinely distinct question the exam also expects an architect to be able to answer: mechanically, how does a request reach Claude *at all* — and once it does, which vendor relationship actually serves the model call underneath it? Conflating these two questions is a common and costly mistake, because the constraints that decide the second question are often organizational and contractual, not technical, and they can override an otherwise-correct answer to the first.

Three Layers, Not One

It helps to think of the full path from a human (or another system) to an inference result as three distinct layers stacked on top of each other, each answering a different question:

The first two layers are the ones this course has already spent the most time on: an entry point like Claude Code is built using a build-time interface — the Agent SDK, in Claude Code's case, or the direct API/SDKs/MCP for a custom application. What hasn't been named explicitly yet is the third layer, and it's the one that determines something the first two layers don't: *which company's infrastructure, compliance boundary, and billing relationship the request actually runs through.* Two organizations can build the identical entry point on the identical build-time interface and still end up on completely different delivery routes — and for some clients, the delivery route is the single most consequential decision in the entire integration, because it's inherited from a decision the client made long before this project existed.

The Four Delivery Routes

The Deciding Question Is Never "Which Model Is Best"

The model itself — Haiku, Sonnet, Opus — is identical in raw capability regardless of which delivery route serves it. That's precisely why this is easy to get wrong: an architect focused only on model tier and build-time interface can correctly design everything else about an integration and still hand the client an unusable answer, because the delivery route decision was never made explicit as its own step. The deciding question for delivery route is the same shape as the reuse-and-maintenance question that decides MCP vs. direct API/CLI, just aimed at a different layer: *which cloud/vendor relationship does this client already have compliance, billing, and identity commitments to — and does routing through that relationship save more than it costs?*

Microsoft Foundry: A Full Worked Scenario

Microsoft Foundry deserves special attention because it's the delivery route most often underweighted by architects who default to thinking in AWS/GCP terms. Consider a mid-size regional insurance carrier — call it Meridian Mutual — with roughly 4,000 employees, all of them already on Microsoft 365 E5 licensing, with every employee identity, group membership, and conditional-access policy managed in Azure AD (Entra ID), and an existing enterprise agreement with Microsoft covering the bulk of the company's cloud spend. Meridian wants to build an internal claims-adjuster assistant: an application, built on top of Claude, that helps adjusters draft coverage determinations by pulling policy documents and prior claim history.

On pure model capability, calling Anthropic directly and calling Claude through Microsoft Foundry produce identical answers from identical models — there is no capability difference to adjudicate. But three non-model factors make Foundry the right delivery route for Meridian specifically, and none of them would show up if the architect only asked "which model tier do we need":

• Identity integration. Meridian's IT security team requires every application touching claims data to authenticate through the company's existing Azure AD conditional-access policies — MFA enforcement, device-compliance checks, and the same group-based access rules that already gate every other internal tool. Building on Foundry means the claims-adjuster assistant inherits that identity fabric automatically; building against the Anthropic direct API would mean standing up a parallel authentication path with its own key management, its own audit trail, and its own gap in the conditional-access net IT already trusts.
• Procurement and billing consolidation. Meridian's enterprise agreement with Microsoft already has claims-and-usage-based cloud spend flowing through a single consolidated invoice that finance reconciles monthly against a pre-negotiated committed-spend discount. Routing Claude usage through Foundry means it lands on that same invoice, under that same discount structure, with no new vendor contract for procurement to negotiate from scratch. Calling Anthropic directly would mean a brand-new vendor relationship, a new invoice finance has never seen, and a new set of terms legal has to review — real friction with a real dollar and time cost, even though the model itself is unchanged.
• Compliance boundary inheritance. Meridian's existing Microsoft enterprise agreement already covers the data-handling, audit, and retention commitments its compliance team negotiated for the rest of its Azure footprint — including the specific commitments that satisfy its state insurance regulators. Routing claims data through Foundry means that data stays inside the compliance boundary the regulators have already reviewed and approved; routing it to a different vendor means asking compliance to re-review a materially different data-handling arrangement before the assistant can go live, which can add months to a launch timeline that has nothing to do with the quality of the underlying model.

Notice what's absent from all three reasons: nothing about Claude's accuracy, reasoning quality, or feature set. That's the point. For Meridian, Foundry isn't the *technically superior* delivery route — it's the *organizationally correct* one, because the deciding factors are identity integration, procurement consolidation, and compliance boundary inheritance, not model quality. An architect who recommends the Anthropic direct API here because "it's simpler" or "it gets new features first" has optimized the wrong variable — they've solved a problem Meridian didn't have (model capability) while creating three the client does have (a new auth path, a new vendor contract, and a compliance re-review).

Common Exam Trap: Collapsing Three Layers Into One

The most common mistake is collapsing entry point, build-time interface, and delivery route into a single decision — treating "just use the API" as a complete answer without ever asking which CSP relationship the client actually needs underneath it. This is the same shape of error as reflexively reaching for the most familiar or most technically elegant integration option elsewhere in this domain (Task Statement 3.5's MCP-vs-direct-API/CLI trap is the closest sibling) without first asking what the client's existing constraints — regulatory, organizational, or contractual — actually require. "Use the direct API" can be exactly right for a startup with no existing cloud commitments and exactly wrong for an enterprise whose compliance, billing, and identity are already deeply entangled with one specific cloud provider. The exam tests whether you ask the delivery-route question explicitly, as its own step, rather than assuming build-time interface and delivery route are the same choice.