Ways to build and host a Claude agent

1.Four ways to build a Claude agent

Every Claude agent runs the same cycle. Claude gets a prompt, asks for tool calls, gets the results back, and keeps going until it answers with no tool call. That cycle is taught in [The tool-use (agentic) loop](lesson:8.1). The build options differ in how much of that cycle you write yourself, which tools are already there, and where the agent runs.

At one end is the Client SDK, which calls the Claude API directly. You write the tool loop yourself, or you hand it to the client SDK's beta tool runner, which drives the loop while you still define and run every tool. That control is the point: the Messages API is described as best for custom agent loops and fine-grained control, so a custom harness belongs here.

The Agent SDK is the middle option. It is a Python or TypeScript library that runs the Claude Code binary inside a process you operate. Claude Code is Anthropic's agent for working from a terminal, with built-in tools to read, edit and write files and to run commands; the SDK reuses its loop and tools as a library. You get Claude Code's loop already built, along with its built-in tools, permissions, sessions, hooks, subagents and MCP support, and you never write the loop yourself. The Claude Managed Agents service sits at the far end: Anthropic hosts the harness, and you configure it through the Claude API.

Each option wins in a different situation. Pick the Client SDK when the loop itself is the product, for example when you need a custom stopping rule or your own way of trimming context. Pick the Agent SDK when you want a working coding-style agent inside your own service this week. Pick Managed Agents when the work runs for minutes or hours and you would rather not run the sandbox, the tool-execution layer or session storage yourself.

Sources12

2.Claude Managed Agents: agent, environment, session, events

With Managed Agents, configuration replaces most of your code. You do not build an agent loop, a tool-execution layer or a runtime. You describe the agent, and Anthropic's harness runs it, with prompt caching and compaction built in. Four concepts cover the whole service.

These are the four concepts:

- Agent: the model, system prompt, tools, MCP servers and skills. You create it once and reference it by ID across sessions. - Environment: where sessions run, either an Anthropic-managed cloud sandbox or a self-hosted sandbox on your own infrastructure. - Session: one running agent instance inside an environment, doing a specific task. - Events: the messages between your application and the agent, such as user turns, tool results and status updates.

At runtime you start a session that points at an agent and an environment. You send user messages as events, and Claude runs tools on its own while it streams results back over server-sent events. Event history is stored on the server, so you can fetch it in full later. While the agent works you can send more user events to steer it, or interrupt it to change direction.

The service fits long-running execution, stateful sessions with persistent filesystems, and recurring runs on a cron schedule through scheduled deployments. That statefulness has a cost. Sessions store conversation history, sandbox state and outputs on Anthropic's side, so Managed Agents is not currently eligible for Zero Data Retention or HIPAA BAA coverage. You can still delete sessions and uploaded files through the API.

Sources2

3.Your process, Anthropic's cloud, or your sandbox

There are three places an agent can run, and the question that separates them is which side runs the loop and which side runs the tools. With the Agent SDK, both happen in your process. You deploy it like any other service, in a container or on serverless infrastructure, and you store sessions in your own backend if you need them to persist.

Managed Agents runs tools in Anthropic-managed cloud sandboxes by default. Anthropic handles network egress controls, file and repo mounting, and the sandbox lifecycle. A self-hosted sandbox keeps the orchestration on Anthropic's side but runs the tools on your infrastructure. The files the agent reads and writes, the processes it starts and the network it can reach all stay under your control. Tool inputs and outputs still go back to Anthropic's control plane, because that is where Claude runs. Skills and memory store contents are copied into your sandbox for the session. Memory stores are the agent's memory files, which Anthropic keeps; on your side, the SDK worker downloads them to /mnt/memory/ and syncs the agent's changes back to the store.

Self-hosting earns its operational cost in three cases: the data cannot leave your network boundary, the agent has to reach internal services that are not publicly routable, or the work has to run under your own compliance and audit controls. Locking down what a sandboxed process can reach is covered in [Runtime sandboxing against exfiltration](lesson:7.1). If none of those cases apply, the cloud environment means less infrastructure for you to run.

Sources324

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A self-hosted sandbox means the whole agent, model calls included, runs inside your infrastructure.Why is that wrong?

   Only tool execution moves to your host. Orchestration stays with Anthropic, and tool inputs and outputs still go to Anthropic's control plane.

   Covered in Your process, Anthropic's cloud, or your sandbox

2. 2.Managed Agents can be used for a workload that requires Zero Data Retention.Why is that wrong?

   Managed Agents stores session history, sandbox state and outputs on the server by design, so it is not currently eligible for ZDR or HIPAA BAA coverage.

   Covered in Claude Managed Agents: agent, environment, session, events