Atlas Whoff

Posted on Apr 16

Claude Managed Agents: What Actually Changed for Builders (April 2026)

#ai #anthropic #claude #agents

Claude Managed Agents: What Actually Changed for Builders

On April 8, 2026, Anthropic shipped Claude Managed Agents into public beta. If you missed the announcement — it's legitimately the most significant developer API change since tool use launched.

Here's what's different, what you actually get, and the 3 patterns that matter.

What Changed

Before Managed Agents, building a Claude-powered agent meant:

You own the conversation loop
You serialize/deserialize tool calls manually
You handle retries, context window management, and state
You wire your own memory layer

With Managed Agents, Anthropic hosts the agent loop. You define tools, a system prompt, and optionally a memory spec. The API handles:

Multi-turn orchestration server-side
Automatic tool dispatch + result injection
Session persistence (30-day default TTL)
Token-efficient context compaction built in

import anthropic

client = anthropic.Anthropic()

# Create a managed agent
agent = client.agents.create(
    name="support-agent",
    model="claude-sonnet-4-6",
    tools=[search_tool, ticket_tool],
    system="You are a support agent...",
)

# Start a session
session = client.agents.sessions.create(agent_id=agent.id)

# Send a message — Claude handles the loop
response = client.agents.sessions.message(
    agent_id=agent.id,
    session_id=session.id,
    message="My order hasn't arrived",
)
print(response.content)

That's it. No manual tool dispatch loop.

The 3 Patterns That Matter

1. Stateful Sessions Replace Conversation Arrays

The old pattern was passing a growing messages array on every call. Sessions fix this. The session object is the state. You send a message, you get a response. Anthropic handles what goes in the context window.

This is huge for long-running agents. A customer support thread that spans 40 turns no longer blows your context window.

2. Tool Definitions Are Agent-Level, Not Call-Level

Previously, tools were defined per API call. With Managed Agents, tools are registered on the agent at creation. This means:

Tool schemas are validated once at agent creation time
You catch schema errors in CI, not at runtime
Tool versioning maps cleanly to agent versioning

3. Session Memory Is a First-Class API

You can read and write session memory directly:

# Write facts to session memory
client.agents.sessions.memory.set(
    agent_id=agent.id,
    session_id=session.id,
    key="user_plan",
    value="enterprise",
)

# Claude automatically has access to this in context

This replaces the DIY pattern of prepending memory strings to system prompts.

What's Still Manual

Managed Agents doesn't do everything. You still own:

Routing: deciding which agent gets a message
Human-in-the-loop gates: pausing for approval before destructive actions
Cross-agent handoffs: passing context from one agent to another
Your tool implementations: the actual functions that tools call

Should You Migrate?

For greenfield agents: yes, use Managed Agents from day one.

For existing production agents: evaluate migration cost against the benefits. The biggest wins are for agents with long sessions (support, coding assistants) and agents where context management is currently a pain point.

For single-turn completions: stick with the standard Messages API. Managed Agents adds overhead you don't need.

The Pricing Note

Managed Agents charge the same per-token rates as standard API calls. The session infrastructure (storage, orchestration) is currently free during beta. Expect usage-based pricing for storage and session-minutes when it exits beta.

The full API reference is at docs.anthropic.com/agents. The managed agent SDK examples in the official repo are worth reading — especially the customer support and coding assistant templates.

Building something with this? Drop what you're building in the comments.

DEV Community