Four ways to build a Claude app

There are four ways to put Claude in a product, and the exam cares that you can tell them apart. This is design-domain material, worth more than any syntax question, and the distinctions are genuinely subtle.

The useful axis is how much of the loop you are still holding. At one end you write every turn yourself; at the other, execution has left your infrastructure entirely. Everything else follows from where on that axis you land.

The four shapes

Client SDK. You call the Messages API. You get back stop_reason: "tool_use", you execute the tool, you append the result, you call again. The loop is yours. Maximum control, maximum code, and every retry, timeout and budget check is something you wrote.

Tool Runner. client.beta.messages.tool_runner loops over tools you define. You still own the tool implementations; you stop owning the plumbing that shuttles results back in. It is the smallest step up from the raw SDK and the one people underrate.

Claude Agent SDK. The docs describe this one as Claude Code as a library. Python and TypeScript only. It is not a loop helper, it is the whole harness: the agent, its tooling, its file access, its behaviour, packaged so you can embed it. If you want the thing that Claude Code is, without building the thing that Claude Code is, this is it.

Managed Agents. Server-hosted, behind the beta header managed-agents-2026-04-01, billed at 0.08 dollars per session-hour on top of token costs. And the line the docs draw explicitly: it is a separate product from the Agent SDK.

How to actually pick

Three questions, in this order.

Do you need to intervene between turns? Approval gates, per-user spend caps, audit logging of every tool call, custom retry on a flaky internal service. If yes, you want the loop in your hands, which means Client SDK, or Tool Runner if the intervention fits its hooks. A harness that hides the loop hides the place your logic needs to go.

Are your tools the interesting part, or is the agent? If the value is in five well-defined functions against your own systems, Tool Runner. If the value is an agent that explores a repository and decides what to do, the Agent SDK already contains that behaviour and rebuilding it is months you do not have.

Who runs it? Managed Agents moves execution server-side, which changes your operational story completely: no long-running process of your own, and a per-session-hour charge instead. That is a real trade, not a free upgrade, and the trade is worth naming out loud in a design review.

Note the unit on that charge, because it is unusual. Per session-hour means a session that sits idle for forty minutes waiting on a slow downstream service costs the same as forty minutes of hard work. Your latency profile is now a line item.

The trap in the question

Exam questions in this area usually describe a requirement and ask which approach fits. The distractor is almost always the more powerful option for a problem that does not need it. A five-tool internal lookup service does not need an agent harness, and picking one because it sounds more capable is exactly the judgement error the design sub-skill is testing.

The other direction is a trap too. If the requirement says "must approve every destructive action before it runs", any answer that hands the loop away is wrong no matter how modern it sounds.