Get to Production Faster with Claude Managed Agents

1. The hidden cost of “just building” an agent

Most teams hit the same wall. Building an agent that demos well takes a weekend. Building one you can hand to real users at scale takes months — and most of that time is not spent on the thing that makes your agent valuable.

Before Claude Managed Agents, teams building on the raw Messages API had to implement every production primitive themselves:

• Context management — deciding when to summarise or compact a long conversation
• Caching — avoiding redundant token processing across turns
• The agent loop — the code that decides when to call a tool, when to reply, when to stop
• Hosting and scaling — containers, failover, health checks
• State durability — making sure a session survives a restart or a hard refresh
• Security — sandboxing tool execution so credentials don’t leak into the model context
• Observability — logging every tool call and model response for debugging

The cruel irony: as models got smarter, the primitives got harder. An agent that could barely write a file in 2023 now navigates a codebase, calls external APIs, coordinates with subagents, and manages its own memory. Every capability you add multiplies the complexity of the harness that hosts it.

Managed Agents is Anthropic’s answer: a purpose-built production harness you can build on instead of building yourself. Teams that adopt it have reached production 10–15× faster than teams that start from scratch.

2. The three-layer evolution

It helps to understand what each layer of the stack is responsible for before you decide where to build.

Messages API gives you complete control and complete responsibility. You make a request, you get a response, you decide what to do next. Perfect for simple one-shot tasks; painful at production scale.

Agent SDK wraps Claude Code — the model that Anthropic uses internally to let an agent interact with a file system. The SDK makes that accessible programmatically. You still own hosting, scaling, and durability.

Managed Agents takes the infrastructure layer off your plate entirely. The agent loop runs server-side on Anthropic’s infrastructure. Sessions survive restarts. Compaction, caching, and tool sandboxing are handled for you. You configure the agent; Anthropic keeps it running.

3. The three core primitives

Every Managed Agent is composed of exactly three things.

Agent — the brain

An Agent is your agent’s persona and capability set. You define:

• Model — which Claude model powers the agent
• System prompt — instructions, constraints, persona
• Tools / MCP servers — what capabilities the agent can invoke
• Skills — higher-level reusable behaviours the agent can call

The Agent definition lives on the server. It has a stable identifier you reuse across sessions. You don’t reinitialise the agent on every request.

Environment — the hands

An Environment is the sandboxed space where the agent’s tool calls actually execute. When the agent decides to run a bash command, read a file, or call a web API, those actions happen inside the environment — not inside the agent loop.

This decoupling is intentional and consequential. More on it in the next chapter.

Session — the binding

A Session ties one Agent to one Environment and gives you a durable conversation. When you create a session you pass:

1. The agent ID
2. The environment ID
3. Any files or resources you want to mount (context the agent can read)

The session maintains state server-side. Hard refresh the browser, restart your laptop, come back the next day — the session is exactly where you left it.

Sessions communicate in events, not request-response pairs. Every user message, every tool call, every model response is an event appended to the session log. This makes resumability trivial and observability natural: you just stream events.

4. Why decoupling the brain from the hands matters

Earlier agent architectures coupled the agent loop and tool execution inside the same process. That made sense when agents were simple: you start a container, the agent thinks and acts inside it, you get a response.

At production scale, this coupling creates three problems:

Latency. Spinning up a fully-equipped container for every new session adds hundreds of milliseconds before the first token. Managed Agents measured a greater than 90% reduction in P95 time-to-first-token after decoupling the agent loop from the execution environment.

Security. If credentials (API keys, database passwords) live in the same container as the agent loop, there is no clean boundary between “what the model sees” and “what the model can act on”. Decoupling lets you encrypt credentials in a separate vault and expose them only to the execution environment — the agent loop never touches plaintext secrets.

Reliability. If a tool-execution container crashes, the agent loop doesn’t need to restart. The event log is intact. You spin up a fresh container and resume exactly where you left off.

A practical note on the execution environment: at Code with Claude London 2026 Anthropic announced “bring your own containers” — you can now run the tool-execution side on your own infrastructure instead of Anthropic’s managed sandbox. This matters when your tools need access to private network resources or when your compliance requirements mandate on-prem execution.

5. Context engineering: the work that remains yours

When you adopt Managed Agents you hand off infrastructure. But one discipline stays squarely with you: context engineering — deciding what information you give the agent and how.

The Managed Agents harness handles compaction and caching automatically, but you still decide:

• Which files to mount when creating a session (logs, runbooks, schema definitions)
• What tools to expose and what data they return
• How rich your system prompt is — a crisp, focused prompt beats a sprawling one even with a capable model
• How to structure tool outputs — the agent’s reasoning is only as good as the data you feed it

A useful rule of thumb from Anthropic’s Applied AI team: the majority of developer time on top of Managed Agents is spent on context engineering — not on the harness itself. That’s a good sign. It means you’re spending your time on the thing that actually differentiates your agent.

One concrete example: teams building incident-response agents found that giving the agent access to historical runbooks (documented past incident resolutions) dramatically improved its ability to propose correct fixes. The agent’s reasoning quality was gated not by model intelligence but by the richness of the context it could draw on.

6. Beyond the basics: the production feature set

Once you have the Agent/Environment/Session primitives working, a set of advanced capabilities unlock further production scenarios.

Subagents (multi-agent orchestration)

An orchestrator agent can spin up subagents, each with their own context window and tool set. Subagents let you:

• Parallelise independent subtasks (multiple agents working concurrently)
• Isolate context so complex workflows don’t exhaust a single context window
• Specialise — a research subagent, a code-writing subagent, and a review subagent each do one thing well

The key engineering challenge with subagents is communication: the orchestrator needs to pass the right information to subagents and interpret their results correctly. Miscommunication between orchestrator and subagent is one of the most common failure modes in multi-agent systems.

Memory and dreaming

Memory lets an agent accumulate knowledge across sessions — user preferences, past corrections, learned patterns. “Dreaming” is the process by which the agent reviews its memory logs and decides what to consolidate, what to discard, and what to update. This gives you self-improving agents without writing custom memory-management logic.

Outcomes

Instead of defining your agent purely in terms of tools to call, Outcomes let you define a rubric — a description of what a successful result looks like. The agent then determines its own path to that outcome. This shifts you from “tell the agent exactly what steps to take” to “tell the agent what success looks like”, which is often a more robust specification.

Vaults

Vaults provide encrypted credential storage separate from the agent loop. You store API keys, database passwords, and OAuth tokens in a Vault; the execution environment can access them but the agent loop never sees plaintext secrets. Access is configurable per user and per session.

Webhooks and fine-grained permissions

Webhooks let external events (a monitoring alert, a GitHub push, a customer action) trigger session state transitions. Fine-grained permission policies let you restrict exactly which tool calls a session is allowed to make — useful when different agents or tenants need different access levels.

pip install anthropic-managed-agents
cp .env.example .env
# Add your ANTHROPIC_API_KEY to .env

import anthropic_managed_agents as cma

client = cma.Client()

agent = client.agents.create(
    model="claude-opus-4-5",
    system="""You are an SRE agent. When given an incident report, you:
1. Analyse the provided logs and metrics
2. Identify the root cause
3. Propose remediation steps

You have access to: get_metrics, get_recent_deploys, get_diff, fetch_logs.""",
    tools=[
        {"name": "get_metrics", "description": "Fetch time-series metrics for a service"},
        {"name": "get_recent_deploys", "description": "List recent deployments with timestamps and authors"},
        {"name": "get_diff", "description": "Show the code diff for a given deploy SHA"},
        {"name": "fetch_logs", "description": "Retrieve log lines for a time window"},
    ]
)

print(f"Agent ID: {agent.id}")  # save this — it persists

environment = client.environments.create(
    type="anthropic_managed",
    networking={"allowed": ["*"]},  # tighten to specific hosts in production
)

print(f"Environment ID: {environment.id}")

with open("incident_logs.txt", "rb") as f:
    log_resource = client.resources.upload(f, filename="incident_logs.txt")

session = client.sessions.create(
    agent_id=agent.id,
    environment_id=environment.id,
    resources=[log_resource.id],
)

print(f"Session ID: {session.id}")  # durable — survives restarts

def get_metrics(service: str, window: str) -> dict:
    # Replace with your real DataDog / Prometheus / CloudWatch client
    return {"p99_latency_ms": 1420, "error_rate": 0.034, "service": service}

def get_recent_deploys() -> list:
    return [
        {"sha": "abc123", "author": "alice", "timestamp": "2026-05-21T02:14:00Z",
         "message": "refactor: order summary builder"},
    ]

tool_handlers = {
    "get_metrics": get_metrics,
    "get_recent_deploys": lambda: get_recent_deploys(),
}

for event in session.send_and_stream("Debug my incident — P99 latency is 10x baseline"):
    if event.type == "message":
        print(event.content, end="", flush=True)
    elif event.type == "tool_call":
        handler = tool_handlers.get(event.name)
        result = handler(**event.arguments) if handler else {"error": "unknown tool"}
        session.submit_tool_result(event.call_id, result)
    elif event.type == "done":
        print("\n--- Agent finished ---")
        break

# Resume an existing session
for event in session.send_and_stream("What steps did you recommend?"):
    # ... handle events as above

session.delete()