Comparisons / AWS Bedrock AgentCore
AWS Bedrock AgentCore vs Building from Scratch
Bedrock AgentCore is AWS's managed runtime for production agents, launched in July 2025. It is *not* a framework you import — it is the platform that runs your agent code (Strands, LangGraph, CrewAI, or anything else). It packages five managed services: Runtime (sandboxed execution), Memory (short + long term), Identity (OAuth + secrets), Gateway (tools as APIs), and Observability (traces, metrics).
The verdict
AgentCore is for **production AWS deployments** where you want to skip the runtime, memory, identity, and observability work and pay AWS to do it instead. It is framework-agnostic — bring Strands, LangGraph, CrewAI, or your own. For non-AWS teams, prototypes, or anything where you want to see what the agent is doing, plain Python on Lambda or a container is simpler.
| Concept | AWS Bedrock AgentCore | Plain Python |
|---|---|---|
| Runtime | Sandboxed, low-latency container per session, up to 8h, MicroVM-isolated | AWS Lambda or Fargate or a Cloud Run container — you wire timeouts and isolation |
| Memory | Managed short-term + long-term memory with semantic recall and namespacing | DynamoDB or Postgres + an embedding API + a vectors table you maintain |
| Identity | OAuth flows, AWS IAM, Secrets Manager integration, per-user credential vending | Roll your own with Auth0, Cognito, or Secrets Manager + a token vending lambda |
| Gateway | Turn any API or Lambda into an MCP-compliant tool with one config | Implement the MCP server protocol per tool (~50 lines each) |
| Observability | OpenTelemetry traces, per-step LLM call costs, error grouping in CloudWatch | OTel SDK + a backend (Honeycomb / Grafana / Datadog) you run yourself |
| Browser | Managed isolated browser tool for agent web actions | Playwright in a container with auto-shutdown after N minutes |
What AgentCore does
AgentCore is the managed half of AWS's agent stack (the framework half is Strands, but AgentCore runs anything). It provides five services that production agents need but that aren't fun to build:
- Runtime: a sandboxed, MicroVM-isolated container per session, supporting long-running agents (up to 8 hours) with low cold-start latency. Sessions are isolated from each other so one user's agent can't see another's state.
- Memory: short-term (in-session) and long-term (cross-session, vector-recalled) memory with namespacing per user.
- Identity: OAuth 2.0 inbound, AWS IAM and Secrets Manager outbound, per-user credential vending. Solves the "how does the agent authenticate to Slack on this user's behalf" problem.
- Gateway: turn any API endpoint or Lambda into an MCP-compliant tool. Removes the per-tool MCP server boilerplate.
- Observability: OpenTelemetry traces of each LLM call, per-step cost attribution, error grouping. Hooks into CloudWatch.
It's intentionally framework-agnostic — you point AgentCore at your agent code (Strands, LangGraph, plain Python) and it provides the runtime layer underneath.
The plain Python equivalent
Each AgentCore service maps to infrastructure work you'd otherwise own: Runtime is Lambda or Fargate plus session isolation. Memory is DynamoDB or Postgres plus an embedding API plus a vector table. Identity is Cognito or Auth0 plus Secrets Manager plus a token-vending Lambda. Gateway is per-tool MCP server implementation (the protocol is small but adds up across many tools). Observability is the OTel SDK plus a Honeycomb or Datadog backend you operate.
For a single-agent prototype, all of this is overkill — you don't need MicroVM isolation for one user, you don't need long-term memory for an MVP, you don't need identity vending if there's no user-specific OAuth. The full set of capabilities lives on the production-at-scale side of the line. If your agent is python agent.py on a laptop, building any of this from scratch is wasted effort.
When to use AgentCore
AgentCore makes sense when you're shipping agents to many users on AWS and the operational concerns (isolation, identity, observability, memory at scale) become real problems. The MicroVM isolation is genuinely hard to reproduce — you cannot trivially run untrusted user-driven agent code in shared containers safely. The OAuth + Secrets Manager identity flow alone saves weeks if your agent needs to act as a user against external services.
It's also a sensible choice if you're already standardized on AWS and want to consolidate: one platform for the agent runtime, the memory store, the auth boundary, and the observability pipeline. Pricing is pay-as-you-go, which is friendly for prototypes-to-production transitions.
When plain Python is enough
If you're not on AWS, AgentCore doesn't apply — it's an AWS service, full stop. If you're prototyping or running a single-user agent, AgentCore's services solve problems you don't have yet. Plain Python on a laptop or a small Lambda is the right place to start.
Most agents in early production are simpler than their deploy story suggests. The time to graduate to AgentCore (or any managed agent runtime) is when you've felt the pain — a session leaked state to another user, an OAuth token was hardcoded, observability is print(). Adopt it then. Building on top of AgentCore from day one is fine if you're certain that's the destination, but it removes your ability to see and modify what's happening at the runtime layer, which is where most novel agent bugs live.
Frequently asked questions
What is AWS Bedrock AgentCore?
AgentCore is AWS's managed runtime for production agents, launched July 2025. It is framework-agnostic — you bring your agent code (Strands, LangGraph, CrewAI, or plain Python) and AgentCore provides Runtime (sandboxed execution), Memory (short + long term), Identity (OAuth + secrets), Gateway (APIs as MCP tools), and Observability (traces + cost attribution). Pay-as-you-go on AWS.
AgentCore vs Strands — which do I use?
Both. Strands is the SDK you write your agent code with; AgentCore is the platform that runs it. They're designed to pair. You can also run AgentCore with LangGraph, CrewAI, or plain Python — Strands isn't required. Choose Strands as the framework if you want a thin Python SDK; choose AgentCore as the runtime if you're deploying on AWS and want managed isolation, memory, identity, and observability.
Do I need AgentCore to run agents in production?
No. Plain Python on Lambda, Fargate, or a Cloud Run container works fine for many production agents. AgentCore earns its place when the operational layer becomes real — multi-user session isolation, OAuth-based external API access, long-term memory across sessions, observability across hundreds of agent invocations. For single-user, single-tenant, single-purpose agents, the managed services are overkill.