The problem
A team wants to automate support ticket triage. Someone suggests: "let's use Claude Code for this." Another person suggests: "no, this calls for an MCP server." A third believes calling the API directly from the backend is enough. All three might be right — the wrong question is "which tool do I already know best?", whereas the right question is "which surface carries this workload with the lowest possible complexity?"
Claude Code, the Claude Agent SDK, direct Messages API calls, and the Model Context Protocol (MCP) are not sequential layers of the same stack ordered by sophistication. They are surfaces designed for distinct purposes, and choosing the wrong one isn't just "less elegant" — it becomes costlier to maintain, harder to test, or simply fails to meet the core requirement.
The four surfaces and what each solves
Direct Messages API is the foundational layer: one request, one response, stateless between calls unless you explicitly resend conversational context. It is ideal for applications that already manage their own orchestration and only need point-in-time inference — such as a summarization endpoint or a classifier embedded within an existing pipeline.
Claude Agent SDK provides an execution harness around the API: session management, hooks, subagents, and an out-of-the-box tool loop. It is the right choice when an application requires persistent agentic behavior — multi-turn interactions, delegation, and deterministic controls that prompt engineering alone cannot guarantee.
Claude Code is an interactive software development agent powered underneath by the Agent SDK, configured via CLAUDE.md, commands, and Skills. It is built specifically for engineering workflows — not as a runtime engine for building end-user production services.
MCP is not an alternative to the other three — it is an open protocol that standardizes how tools and resources are exposed for any of them to consume. The question is never "Agent SDK or MCP", but rather "should this toolset be exposed as a reusable MCP server, or implemented directly as a function within my application code?"
The criterion: requirements over familiarity
The most common architectural mistake is not a purely technical blunder — it is choosing a surface simply because the team is already comfortable with it. An engineer who spends their day in Claude Code tends to route everything through it, including workloads that should just be a single direct API call in an existing backend service.
The decision framework is simple to state, yet challenging to apply under pressure:
- Does the task require state across multiple turns? If not, the direct API is sufficient — do not add an agent harness for a single one-off call.
- Does the task need tools shared across multiple clients or agents? If yes, it is a prime candidate for an MCP server rather than hardcoded logic.
- Is the task centered on the software development lifecycle itself (code generation, PR reviews, running tests)? That is Claude Code, not a bespoke standalone application.
- Is the task an end-user production application requiring continuous agentic behavior? That is the Agent SDK.
A classic scenario distractor: "using Claude Code to automate a production workload because the team is already proficient with CLAUDE.md". Team familiarity is not a technical requirement — Claude Code was not architected to run headless as an embedded customer-facing production service.
Combining surfaces is often the right answer
Not every scenario resolves into a single surface. A CI/CD pipeline might run headless Claude Code for automated pull request reviews, while the production service being reviewed leverages the Agent SDK with custom MCP servers to query incident histories. Both coexist seamlessly because they solve fundamentally different problems — mistaking this for indecision misses the hallmark of a mature architecture.
Put it into practice
This lesson's lab builds a requirements classifier: given a set of signals about a task (does it need state? does it need reusable tools? is it part of the development lifecycle?), it recommends the optimal surface and explains why — the exact reasoning you will apply in seconds during exam scenarios.