Two Roads to Production Agents

Writing an agent loop is a weekend project. Send a prompt and tool definitions to a model, read back stop_reason, execute the tool it asked for, append the result, loop until done. A couple hundred lines. The hard part was never the loop — it's everything that surrounds it once real traffic, real money, and real auditors show up:

• Sandboxed code execution. Agents are dramatically more capable when they can run code. Running model-generated code on your own infrastructure is a security incident waiting to happen.
• Session persistence & streaming. Conversations span minutes, sometimes hours. Events must stream to a UI; state must survive a reconnect.
• Tool integration at scale. Wiring dozens of internal APIs and MCP servers, with auth, without hand-rolling each one.
• Memory. Cross-session recall so the agent stops asking the same questions.
• Identity & secrets. The agent acts on behalf of someone and touches credentialed systems. Who, with what authority, using which secret — and is it logged?
• Multi-agent orchestration. A coordinator delegating to specialist sub-agents, each isolated.
• Observability. Traces, token accounting, and an audit trail an enterprise compliance team will accept.

Both Claude Managed Agents (CMA) and the AWS stack of Strands + AgentCore exist to provide that surrounding scaffolding. They differ fundamentally in who owns it.

Before comparing platforms, it helps to name the seven layers every production agent needs. Both approaches implement all seven — they just draw the ownership boundary in different places.

Claude Managed Agents is Anthropic's batteries-included agent runtime. You declare an agent (model, system prompt, tools, skills), create an environment (a sandboxed Linux filesystem), open a session, and stream events. The reasoning loop, the sandbox, the skill selection, the sub-agent spawning — all run server-side in Anthropic's cloud.

The core primitives

# An agent: identity + model + tools + skills, declared once
agent = client.beta.agents.create(
    model="claude-sonnet-4",
    system=SYSTEM_PROMPT,
    tools=[{"type": "agent_toolset_20260401"}],  # built-in sandbox
)

# An environment: the sandboxed filesystem the agent operates in
env = client.beta.environments.create(config={"type": "cloud"})

# Skills: versioned capability bundles, auto-selected by the model
client.beta.skills.create(display_title="reorder-policy", files=[...])

# A session: one conversation; events stream bidirectionally
session = client.beta.sessions.create(agent=agent.id, environment_id=env.id)
with client.beta.sessions.events.stream(session.id) as stream:
    for event in stream: ...

The AWS path splits the problem into two cleanly separated pieces:

• Strands Agents — an open-source Python SDK that is the agent loop. You define a model, a system prompt, and tools (plain typed Python functions); Strands runs reason → act → observe. Model-agnostic, runs anywhere.
• Bedrock AgentCore — a set of managed, serverless production services you call from your agent: Code Interpreter (sandbox), Memory, Gateway (tools), Identity (secrets), Browser, and Observability. Each is independently adoptable.

The core shape

from strands import Agent, tool
from strands.models import BedrockModel

@tool
def get_stock_level(sku: str, warehouse: str) -> str:
    """Current on-hand quantity for a SKU at one warehouse."""
    return ...  # typed function + docstring IS the tool schema

agent = Agent(
    model=BedrockModel(model_id="us.anthropic.claude-sonnet-4-6", region_name="us-west-2"),
    system_prompt=SYSTEM_PROMPT,
    tools=[get_stock_level, ...],
)

The crucial row is the last one. Everything above it is implementation detail; the data-plane location is the architectural and compliance decision an enterprise actually argues about.

The cleanest way to reason about these stacks is to separate the control plane (how you define and operate agents) from the data plane (where prompts, tool inputs/outputs, code execution, and memory physically live).

For an enterprise in pharma, finance, healthcare, or the public sector, this single distinction frequently decides the platform before any feature comparison happens. "Does customer data leave our AWS account?" has a one-word answer for each stack, and that word is often the whole conversation.

Real workloads decompose into a coordinator and specialist sub-agents. A research coordinator delegates to a web searcher, a document analyst, a synthesizer. An inventory coordinator delegates heavy forecasting to a sub-agent with its own context window.

# declarative — platform handles the rest
callable_agents = [
  {"type": "agent", "id": forecaster_id, "version": v}
]
client.beta.agents.update(
    coordinator_id, callable_agents=callable_agents
)

@tool
def forecaster(sku: str) -> str:
    """Delegate a demand forecast."""
    sub = Agent(
        model=make_model(),
        system_prompt=FORECASTER_SYSTEM,
        tools=[run_python]
    )
    return str(sub(f"Forecast {sku}"))

Memory turns a "goldfish" agent (re-asks everything every session) into a "colleague" (recalls context across sessions).

The AWS stack inherits the entire IAM and VPC apparatus an enterprise already runs. The agent's permissions are ordinary IAM policies; the blast radius is an ordinary role; the network path is an ordinary security group. For a security team, "it's just IAM and a VPC" is reassuring in a way that a separate vendor's access model is not.

• CMA gives you session transcripts and token accounting in the Anthropic console. Excellent for development and debugging; you'll typically mirror events to your own store for long-term audit.
• Strands + AgentCore emits OpenTelemetry traces and CloudWatch metrics, and every underlying API call (Bedrock inference, AgentCore sandbox, Secrets Manager fetch) is captured by CloudTrail automatically. Pair that with versioned artifacts (skills in S3, structured outputs with object lock) and the audit trail is end-to-end inside your account.

Velocity favors CMA early; an enterprise already standardized on AWS often favors the AWS stack for billing consolidation, existing committed-spend discounts, and not adding a vendor to procurement and security review.

Strip away preference and the choice usually reduces to a handful of hard constraints. Walk them in order; the first hard constraint typically decides.

These are not mutually exclusive across a portfolio. A common, sensible progression:

1. Prototype on CMA. Validate the agent design, the prompts, the tool surface, and the evals with minimal infrastructure. Get to a working, measurable agent in days.
2. Keep the logic portable. The agent loop, tool contracts, skills (as markdown), and the eval harness are platform-neutral. Treat the runtime as swappable from day one.
3. Productionize on AWS when a customer constraint demands data-plane ownership. Re-home the same agent design onto Strands + Bedrock + AgentCore inside their account.

The two artifacts that make this migration cheap are a portable eval harness (prove parity after re-homing) and methodology-as-skills (markdown files that move between platforms unchanged). Build those well and the runtime beneath them becomes an implementation detail.

CMA and Strands + AgentCore are not competitors so much as two points on a single spectrum of how much of the surrounding scaffolding you want to own.

The patterns that matter — decomposing a monolith into a lean coordinator, isolating heavy work in sub-agents, treating methodology as versioned skills, sandboxing code execution, and measuring everything with evals — are identical on both. Master the patterns, and the platform becomes a choice you make per customer, per constraint, rather than a religion. That portability is the real engineering asset.