If you’ve ever tried to ship a production-grade AI agent, you know the infrastructure tax arrives fast. You start with a clean loop — call the API, parse the response, run a tool, repeat. Then reality shows up: transient errors that crash the session, credentials living in plaintext, no way to resume a 45-minute task after a network blip, and zero visibility into what the agent actually decided mid-run.
Most teams build all of that themselves. It takes weeks. And they’re still maintaining it when they should be building features.
Claude Managed Agents, launched in public beta on April 8, 2026, is Anthropic’s answer to this. It’s not an SDK you install — it’s a fully hosted runtime where Anthropic manages the execution loop, sandboxing, session persistence, and error recovery. You write the agent logic. They handle everything else.
With 51% of enterprises now running AI agents in production and another 23% actively scaling deployments (Ringly.io, 2026), the execution infrastructure has become the bottleneck. This post gives you the complete picture: a clear decision framework across all three Anthropic tiers, a working PR review bot you can deploy today, real pricing math, and the limitations nobody else is naming.
The Infrastructure Problem Every Agent Builder Hits
Building a notebook demo is easy. Building something that runs reliably on a GitHub webhook 50 times a day is a different problem.
Production agents need:
– State persistence — a session interrupted mid-task should resume, not restart
– Sandboxed execution — code the agent runs shouldn’t be able to touch your host filesystem
– Credential management — GitHub tokens, Slack keys, and API secrets can’t live in the prompt
– Error recovery — transient tool failures shouldn’t kill the whole session
– Observability — you need to know why the agent made a decision, not just that it failed
According to Ringly.io, over 40% of agentic AI projects will be canceled by end of 2027, largely due to failures in observability, access control, and clear escalation paths. That’s not a model quality problem. That’s an infrastructure problem.
Managed Agents collapses all of that into a managed service. The question is whether the trade-offs fit your use case.
The Three-Tier Decision: Messages API vs. Agent SDK vs. Managed Agents
Before writing a single line of code, get clear on what you’re choosing between. Picking the wrong tier means either over-engineering a simple task or hitting a hard wall on a complex one.
Messages API
The lowest level. You send a message, you get a response. When the model calls a tool, you execute it, pass results back, and manage the loop yourself. Maximum control, maximum portability. Right for short, well-defined tasks or when you’re embedding Claude into an existing orchestration framework.
Agent SDK
Formerly called the Claude Code SDK — this is the same runtime that powers Claude Code itself, self-hosted in your own environment. It gives you the full agentic loop, local filesystem access, and the ability to route to Claude via AWS Bedrock, Google Vertex, or Azure. Teams running parallel agents with isolated git worktrees to avoid branch conflicts are typically operating at this tier, where environment isolation is a first-class concern.
Managed Agents
The hosted tier. Anthropic runs the loop. You get sandboxed execution, session checkpointing, credential management, scoped permissions, and tracing — out of the box, no ops required. The trade-off: workloads flow through Anthropic’s infrastructure, and you can’t mix in non-Claude models.
The decision tree:
– Use Messages API if your task is short and well-defined and you’re already managing orchestration.
– Use Agent SDK if you need local file access, private networks, multi-cloud routing, or tighter cost control at scale.
– Use Managed Agents if you’re building a cloud-native agent triggered by external events and you don’t want to operate the runtime.
How Claude Managed Agents Works Under the Hood
Managed Agents is not a drop-in replacement for the Messages API. It uses entirely separate endpoints.
The three core resources:
– /v1/agents — define your agent, its tools, and system prompt
– /v1/environments — provision a sandboxed execution context with attached credentials
– /v1/sessions — start and manage individual agent runs
Every request requires the header anthropic-beta: managed-agents-2026-04-01. This is not optional and doesn’t fall back gracefully.
The execution model is session-based. When a session starts, Anthropic spins up an isolated environment, runs the agent loop, and maintains state across tool calls. Transient tool failures trigger automatic retry. If the session is interrupted, checkpointing resumes from the last stable state.
That last point matters more than it sounds. An agent that restarts from scratch on failure isn’t a reliable production component. Session checkpointing means a PR review 80% complete doesn’t lose its work because of a 30-second connectivity hiccup.
Tutorial — Building a PR Review Bot That Runs Autonomously in the Cloud
A PR review bot is the ideal Managed Agents use case: it’s triggered by an external event (a GitHub webhook), runs for a bounded time, needs to call an external API, and benefits directly from session persistence and error recovery. It’s also a single-model workflow — the contrast with a multi-model agent setup is worth understanding before you commit to either path.
Here’s a working implementation.
Step 1: Define the agent
import anthropic
client = anthropic.Anthropic()
agent = client.agents.create(
name="pr-reviewer",
model="claude-opus-4-5",
system="""You are a senior software engineer reviewing pull requests.
For each PR:
1. Fetch the diff from the provided GitHub URL
2. Analyze for bugs, security issues, and style violations
3. Post structured review comments via the GitHub API
Always cite specific line numbers and explain the why behind each comment.""",
tools=[
{"type": "web_search"},
{"type": "bash"},
]
)
Step 2: Provision a scoped environment
environment = client.environments.create(
name="pr-reviewer-prod",
credentials={
"GITHUB_TOKEN": {"secret_id": "github-token-prod"},
},
permissions={
"network": ["api.github.com"],
"filesystem": "read"
}
)
Note the network allowlist: this agent can only reach api.github.com. It cannot exfiltrate data to an arbitrary endpoint. Building equivalent network sandboxing yourself requires container orchestration expertise most product teams don’t have.
Step 3: Trigger from a webhook handler
@app.route("/webhook/github", methods=["POST"])
def handle_pr_webhook():
payload = request.json
if payload["action"] not in ["opened", "synchronize"]:
return "", 204
pr_url = payload["pull_request"]["html_url"]
diff_url = payload["pull_request"]["diff_url"]
session = client.sessions.create(
agent_id=agent.id,
environment_id=environment.id,
input=f"Please review this pull request: {pr_url}\nDiff: {diff_url}",
metadata={"pr_number": payload["pull_request"]["number"]}
)
return {"session_id": session.id}, 202
The webhook returns immediately. The agent runs asynchronously. Poll the session for results or configure a completion callback.
This is the pattern official docs mostly skip: triggering Managed Agents from an external event rather than from an interactive chat. The async model maps naturally to CI/CD workflows, scheduled jobs, and event-driven architectures. It’s not just for chatbots.
Credentials, Permissions, and Keeping Your Agent Safe
When you attach credentials to an environment, you’re not embedding tokens in the prompt. They’re stored as managed secrets, injected into the execution sandbox at runtime, and never appear in logs or traces.
The permissions model covers two axes:
Network scope — an allowlist of hostnames the agent can reach. An agent that only needs GitHub shouldn’t be able to reach arbitrary endpoints. The allowlist makes this explicit and auditable.
Filesystem scope — read, write, or none. A reviewer reads files. It doesn’t write to your filesystem.
For teams that have spent time building credential injection and network isolation in custom agent infrastructure, this is where Managed Agents’ value becomes concrete. The security boundaries are real, not aspirational.
Observability: Using the Claude Console to Debug Your Agent
The Claude Console provides session-level tracing: every tool call, input/output, per-step latency, and the final result. You can replay any session to understand exactly what the agent reasoned and why it made a specific decision.
For a bot running 50 times a day, this isn’t optional. When a review comment is wrong or a session fails silently, you need the full execution trace — not reconstructed guesses from application logs.
Sessions are searchable by metadata. Tagging sessions with pr_number (as in the example above) lets you pull up the trace for any specific PR review in seconds.
One honest gap: there’s no built-in alerting when session failure rates spike above a threshold. You’ll need to poll session status and wire up your own alerting. This is a real limitation for production operations, and it’s not yet solved.
What Does a Production Agent Cost? A Worked Example
Pricing documentation is thin, so here’s the concrete math.
The rate structure:
– Standard Claude API token rates
– $0.08 per session-hour of active runtime
– $10 per 1,000 web searches
The scenario: 50 PR reviews/day, each taking ~3 minutes of active session time. Average 2,000 input tokens, 500 output tokens per review. No web searches (GitHub API calls run via bash tool).
Monthly math:
– Runtime: 50 reviews × 3 min = 2.5 hours/day × $0.08 = ~$6/month
– Tokens: 50 reviews × 2,500 tokens × 30 days = 3.75M tokens. At claude-opus-4-5 rates, roughly $56–$90/month
– Total: ~$60–100/month for 1,500 PR reviews
For reference: an always-on agent running 24/7 costs roughly $58/month in runtime alone, before any token usage. That’s the baseline for a persistent monitoring agent.
The session-hour model rewards bursty, event-driven workloads. An agent running 3 minutes, 50 times a day is dramatically cheaper than one holding open a persistent session.
Important: there are currently no per-session budget caps. An open-ended task will run until complete or it times out. Set explicit turn limits in your system prompt until budget controls ship.
Honest Limitations and When to Choose the Agent SDK Instead
Managed Agents is genuinely useful. It’s also early. These constraints are real:
Claude-only. You cannot mix in GPT-4o, Gemini, or a local model in the same agent loop. If you’re building a multi-model agent architecture, Managed Agents doesn’t fit that pattern.
No native scheduling. There’s no built-in cron. You’ll wire up an external scheduler — GitHub Actions, AWS EventBridge, a cron job — to trigger sessions on a schedule. You haven’t fully escaped infrastructure, you’ve just reduced it.
No per-session budget caps. Until this ships, prompt engineering is your guardrail for runaway sessions.
Multi-agent coordination is research preview. Coordinated multi-agent sessions are explicitly labeled research preview. Don’t architect a production system around this yet.
All data flows through Anthropic infrastructure. This is the objection that surfaces fastest in enterprise security reviews. If your agents process data subject to HIPAA, strict data residency requirements, or internal compliance mandates, verify before committing. The Agent SDK running in your own VPC is the right answer for those scenarios — and notably, early enterprise adopters like Notion, Rakuten, and Asana have navigated this directly with Anthropic’s team.
Choose the Agent SDK instead when:
– You need local filesystem access or private network services
– You need multi-cloud routing (Bedrock, Vertex, Azure)
– You have data residency or air-gapping requirements
– You’re running high enough volume that $0.08/session-hour makes in-house operation cheaper
Stop Building Infrastructure, Start Shipping Agents
Claude Managed Agents removes the most expensive part of building production agents — the infrastructure you never intended to build. Anthropic’s own testing showed up to a 10 percentage point improvement in task success rates over standard prompting loops, with the biggest gains on complex structured tasks. TechRadar reported Anthropic’s claim of going from prototype to production “in days rather than months.”
The constraints are real. If you need multi-model flexibility, local data access, or air-gapped execution, the Agent SDK is the right path. But for the large class of problems that don’t require any of those things — event-driven, cloud-native workflows like PR reviews, onboarding automations, or scheduled analysis tasks — paying $0.08/session-hour to skip state management, sandboxing, and observability plumbing is a straightforward trade.
Pick the right tier for your constraints, model your pricing against expected volume, and deploy the PR review bot above as a starting point. The agent infrastructure is handled. Ship the agent.