ZetrixwebFirst: do you actually need an agent?
Before choosing how to build one, check whether the task actually needs an agent at all. Four questions decide it: is the task genuinely multi-step and hard to fully specify in advance (versus "extract the title from this PDF," which isn't), does the outcome justify the added cost and latency, is Claude actually capable at this specific task type, and can errors be caught and recovered from. A "no" on any of these means a single API call or a simple code-orchestrated workflow is the right tier - not an agent, and not any of the four options below.
The two questions that actually separate the four options
Once you've confirmed you need an agent, four distinct build paths exist, and two independent questions separate them: who supplies the harness (the loop plus context management), and who supplies the deployment (the infrastructure it actually runs on).
Manual loop
You write the tool-call loop yourself, using only the tools you define. Maximum control, no dependency on a helper library - the right call when you need a control flow the standard helpers don't fit.
Tool Runner
A thin helper that drives the loop for you over tools you define - no built-in tools, no filesystem access, you still host the compute. The most common choice for a custom-tool business agent.
Managed Agents
Anthropic runs the loop and hosts a per-session sandbox where tools execute - the only option that supplies both harness and deployment. Right for persisted configs, scheduled runs, and long sessions.
Claude Agent SDK
Claude Code packaged as a library - built-in file, bash, and web tools plus the full harness, but you still host and deploy it. Fits a batteries-included coding or filesystem agent on your own infrastructure.
Not sure which of these four fits your specific automation? Talk to us about an agent architecture review before committing engineering time to the wrong one.
Where each one actually wins
| Situation | Best fit |
|---|---|
| Custom business tools, no beta dependency, full control over the loop | Manual loop |
| Custom-tool agent without hand-writing the loop - the common case | Tool Runner |
| Want Anthropic to run the loop and host the workspace; persisted/versioned configs; scheduled agents | Managed Agents |
| Batteries-included coding/filesystem agent, running on your own infra | Claude Agent SDK |
Why this choice is expensive to get wrong
Each path has a different operational shape: who patches the harness when Anthropic ships a new capability, where logs and observability live, how a human-approval step gets inserted, and what a scheduled or long-running session actually requires. Starting with a manual loop and discovering six months in that you actually need scheduled, persisted sessions with a hosted sandbox means rebuilding the deployment layer, not just tweaking code. The architecture decision belongs at the start of scoping, not after the first prototype is already in production.
A pattern worth naming: harness-only vs. harness-and-deployment
The manual loop, the Tool Runner, and the Claude Agent SDK all leave hosting and deployment to you - they differ only in how much of the harness they write for you. Managed Agents is the one option that takes deployment off your plate too, running both the loop and the per-session sandbox on Anthropic's infrastructure. That single distinction - who hosts the compute the agent actually runs on - is usually the deciding factor once a team has a real production timeline rather than a prototype to ship.
Key takeaways
- Confirm you actually need an agent first: multi-step complexity, justified value, model capability, and recoverable errors - a "no" on any means stay at a simpler tier.
- Four build paths exist: manual loop, Tool Runner, Managed Agents, and the Claude Agent SDK - separated by who writes the harness and who hosts the deployment.
- The manual loop, Tool Runner, and Agent SDK are all harness-only - you host and deploy regardless of which one you pick.
- Managed Agents is the only option that also supplies hosted deployment - the right fit for scheduled, persisted, or long-running sessions.
- Pick the architecture during scoping, not after a prototype ships - switching later usually means rebuilding the deployment layer, not just the code.