Akshay Parkhi's Weblog

I Built an Agent in 5 Minutes: Anthropic Managed Agents vs AWS AgentCore + Strands

9th April 2026

A side-by-side look at two very different bets on what “agent infrastructure” should mean.

Disclosure: I work at AWS. I tried to keep this honest. AgentCore has genuine strengths, but the developer experience gap on day one is real. Pretending otherwise doesn’t help anyone choose the right tool.

The 5-minute agent

I just built a Competitor Analysis Agent in the Claude Console. Total time: under five minutes. Here’s the entire build:

1. Click “New Agent”
2. Name it: Competitor Analysis Agent
3. Pick model: claude-opus-4-6
4. Paste a system prompt describing the job (“research what competitors do better, identify gaps, deliver structured reports to ClickUp...”)
5. Enable built-in tools (bash, read, write, web_search, web_fetch)
6. Connect ClickUp MCP server
7. Hit save → agent is Active

That’s it. No code. No container. No IAM role. No deployment. The agent gets all of this from a form:

• its own per-session sandbox
• a file system
• internet access
• the entire Claude Code-style toolset
• a third-party integration

Now let me show you what the same thing looks like in AWS Bedrock AgentCore Runtime + Strands.

The two philosophies

	Anthropic Managed Agents	AWS AgentCore + Strands
Mental model	“Here’s a hosted agent harness. Configure it.”	“Here’s a serverless runtime. Bring your agent.”
What you write	A system prompt	Python agent code + Dockerfile + IaC
Agent loop	Managed by Anthropic	You write it (or use Strands/LangGraph/CrewAI)
Sandbox	Per-session container, auto-provisioned	microVM (Firecracker), you configure
Model lock-in	Claude only	Any model (Bedrock, Anthropic, OpenAI, local)
Time to “hello world”	Minutes	Hours to days

Anthropic decided agents should be a product. AWS decided agents should be a platform. Both bets are reasonable. They produce very different developer experiences.

Building the same agent on AgentCore + Strands

To recreate my Competitor Analysis Agent on AgentCore, here’s roughly what I’d do:

Step 1 — Write the agent code (Strands)

# competitor_agent.py
from strands import Agent, tool
from strands_tools import shell, file_read, file_write, http_request
from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@tool
def clickup_create_task(list_id: str, name: str, description: str) -> dict:
    """Create a task in ClickUp."""
    # ... wire up ClickUp REST API with token from Secrets Manager
    ...

@tool
def web_search(query: str) -> str:
    """Search the web."""
    # ... wire up Tavily / Serper / Brave API
    ...

agent = Agent(
    model="us.anthropic.claude-opus-4-6-20260101-v1:0",
    system_prompt="You are a competitive intelligence analyst...",
    tools=[shell, file_read, file_write, http_request, web_search, clickup_create_task],
)

@app.entrypoint
def invoke(payload):
    return agent(payload["prompt"])

if __name__ == "__main__":
    app.run()

Step 2 — Containerize

FROM public.ecr.aws/docker/library/python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
EXPOSE 8080
CMD ["python", "competitor_agent.py"]

Step 3 — Build for ARM64 and push to ECR

aws ecr create-repository --repository-name competitor-agent
docker buildx build --platform linux/arm64 -t competitor-agent .
docker tag competitor-agent:latest <acct>.dkr.ecr.<region>.amazonaws.com/competitor-agent:latest
docker push <acct>.dkr.ecr.<region>.amazonaws.com/competitor-agent:latest

Step 4 — Deploy to AgentCore Runtime

agentcore configure --entrypoint competitor_agent.py
agentcore launch

…then you also:

• Configure an IAM execution role
• Configure Secrets Manager for the ClickUp token
• Configure observability
• Decide on a memory backend
• Configure Identity if you want OAuth

Time check: half a day if you did it before. Two days if you didn’t.

What you actually get for that effort

This is the honest counterpoint. AgentCore isn’t slower because AWS is bad at developer experience. It’s slower because you get a different product.

Capability	Managed Agents	AgentCore
Sandbox isolation	Per-session container	Per-session microVM (Firecracker) — stronger isolation, up to 8-hour sessions
Memory size	5 GiB RAM, 5 GiB disk	Configurable, up to several GB
Model choice	Claude only	Any: Bedrock, Anthropic, OpenAI, local Llama, fine-tuned
Agent framework	None — you use Anthropic’s loop	Strands, LangGraph, CrewAI, LlamaIndex, Pydantic AI, your own
Identity & OAuth	Vaults (MCP credentials)	Full AgentCore Identity — OAuth providers, workload identity
Observability	Event stream + token usage	Full AgentCore Observability with OpenTelemetry, CloudWatch, traces
Memory service	Built-in auto-compaction	Standalone AgentCore Memory service with semantic recall
Browser automation	Not yet first-class	AgentCore Browser Tool (managed headless Chrome)
Code interpreter	Built-in via bash + Python	AgentCore Code Interpreter as separate service
Gateway / tool catalog	MCP servers per agent	AgentCore Gateway — converts APIs/Lambdas to MCP, central tool registry
Multi-tenancy	Workspace-scoped	IAM-scoped, fits AWS org structures
Cloud lock-in	Anthropic 1P only	AWS native

The pattern is clear: AgentCore is a Lego set. Managed Agents is a finished toy.

Pricing — the real divergence

This is where the philosophies appear in your bill.

Managed Agents

• Tokens at standard Claude rates (Opus 4.6: $5/$25 per MTok)
• $0.08 per session-hour, only while session is running
• Idle time = free (important for chat / long-lived sessions where users think)
• File storage, vaults, environments, agents themselves: free
• The session-hour fee includes container hours, so there is no double charge

1-hour Opus session, 50K in / 15K out = ~$0.70

AgentCore

• Your model provider bills the tokens (Bedrock or direct)
• Runtime compute: CPU-second + memory-GB-second metering. It accrues whenever the microVM runs
• AgentCore Memory, Identity, Gateway, Browser, Code Interpreter are separate services with their own pricing
• CloudWatch for logs/traces
• ECR for container storage
• Plus the AWS dependencies you add (Secrets Manager, IAM, VPC if used)

The runtime fee tends to be cheap per hour. But you now reason about 5+ line items instead of 2. And idle compute often still bills, depending on how you configure the microVM.

Verdict: Managed Agents is more predictable and almost certainly cheaper for low-to-medium volume. AgentCore wins at scale when you can amortize infra investment across many agents and want fine-grained cost control.

Developer experience compared

Defining a tool

Managed Agents:

{ "type": "agent_toolset_20260401" }

Done. You get bash, read, write, edit, glob, grep, web_fetch, web_search.

Strands on AgentCore:

from strands_tools import shell, file_read, file_write, http_request
# ...and you wire each one into agent.tools=[...]
# Web search is BYO — pick a provider, get an API key, write a tool

Adding a third-party integration

Managed Agents: Connect MCP server in the UI. Drop OAuth credential in a vault. Anthropic auto-refreshes the token.

AgentCore: Pick one of two paths:

• (a) Write a Python tool that calls the API. Store the secret in Secrets Manager. Handle refresh yourself.
• (b) Use AgentCore Gateway to expose the API as MCP. Gateway is great, but it is a separate service to learn.

Streaming events to a frontend

Managed Agents: SSE stream is built in (/v1/sessions/{id}/events/stream). Event types are typed and documented (agent.message, agent.thinking, agent.tool_use, etc.).

AgentCore: The runtime supports streaming, but the event shape is whatever your agent code emits. You design the protocol.

Long-running tasks

Managed Agents: Sessions persist. Idle time is free. Reconnect to the SSE stream from any client. Built-in compaction handles 200K+ context.

AgentCore: Up to 8-hour sessions in a single invocation, and the microVM stays alive. Memory service handles long-term recall across sessions. It can do more, and there is more to configure.

When to use which

Pick Managed Agents when:

• You’re committed to Claude (the best frontier model + you don’t need multi-model)
• You want to ship an agent this week, not next month
• You’re building a chat UI, internal tool, or a customer-facing assistant where simplicity matters
• Your team is small and doesn’t have AWS infra specialists
• You want predictable per-hour pricing with idle = free
• You like the MCP ecosystem and Anthropic-native skills (xlsx, docx, pptx, pdf)
• The use case fits: code assistants, research agents, doc generators, support bots

Pick AgentCore + Strands when:

• You’re already deep in AWS and need IAM/VPC/CloudWatch integration
• You need multi-model flexibility (Claude + Llama + a fine-tuned in-house model)
• You’re running thousands of concurrent agents and infra cost matters
• You need 8-hour continuously-running sessions or unusual memory profiles
• You want OpenTelemetry traces flowing into your existing observability stack
• You need stronger sandbox isolation guarantees (Firecracker microVMs vs containers)
• You’re building a multi-agent platform and need Gateway as a tool registry
• You have a security/compliance team that wants everything in your AWS account

Pick both when:

• You’re prototyping in Managed Agents and migrating to AgentCore for production scale
• You’re A/B-testing the two stacks for the same use case
• Different agents in your company have different requirements

A migration path that actually works

If you start in Managed Agents (you should), here’s how the migration to AgentCore looks if you outgrow it:

1. Lift the system prompt. It works as-is in any framework
2. Replace built-in toolset with strands_tools equivalents (shell, file_read, file_write, http_request) or custom tools
3. Replace MCP servers. Strands has MCP support, and the same MCP server URLs work
4. Replace vaults with Secrets Manager + your own refresh logic (or AgentCore Identity)
5. Replace SSE event handling with whatever streaming protocol your agent emits
6. Replace the session model with AgentCore Runtime invocations
7. Replace output capture from /mnt/session/outputs/ with S3 uploads from your agent code

Nothing in Managed Agents is a one-way door. But the leverage you get from not doing all of this on day one is enormous.

My take

The biggest mistake in agent development today is to start with the heavy framework. You start AgentCore, you write Strands code, you containerize, you deploy. Three weeks later you discover that what you actually needed was a different system prompt and one extra tool.

Anthropic Managed Agents is the closest thing to “prompt → agent” we have. The Competitor Analysis Agent I built in 5 minutes would have taken me a full day in AgentCore + Strands. And 80% of that day would have been infrastructure plumbing that doesn’t matter to the user.

Use Managed Agents to discover what your agent should be. Then graduate to AgentCore if you outgrow it (different model, multi-cloud, custom isolation, multi-agent fleets). The lift isn’t that bad because the agent’s intent (system prompt + tool surface) is the part that survives the migration.

Most teams will never need to graduate. That’s the point. As someone who works on the AWS side, I think that’s fine. The right tool depends on where you are, not which company you support.

TL;DR

	Managed Agents	AgentCore + Strands
Build a useful agent	Minutes	Days
Lock-in	Claude/Anthropic	AWS
Code required	Zero	Python + Docker + IaC
Pricing	Tokens + $0.08/hr running	Tokens + compute + 5 services
Ceiling	High enough for 90% of use cases	Effectively unlimited
Best for	Shipping fast, Claude-native	Multi-model, AWS-native, scale