The AWS AI Agent Stack: Strands vs. Bedrock Agents vs. AgentCore
AWS now ships three different things with "agent" in the name — Strands Agents, Amazon Bedrock Agents, and Amazon Bedrock AgentCore — and almost everyone mixes them up. They sound like competitors. They mostly aren't. One is a framework for writing agents, one is a managed service for configuring a simple agent, and one is a platform for running agents in production. Get the mental model right and the choice becomes obvious. Here's the untangling, plus a decision guide.
The one-sentence version
- Strands Agents = how you write the agent (an open-source, code-first SDK).
- Bedrock Agents = a managed, low-code way to define and run a straightforward agent entirely inside AWS.
- Bedrock AgentCore = the production platform to deploy and operate an agent you built in any framework, at scale and securely.
They're layers, not rivals. The most common real-world setup is "write it in Strands, run it on AgentCore" — with Bedrock Agents as the older, simpler managed alternative for well-defined use cases. Let's take them one at a time.
Amazon Bedrock Agents — the managed, low-code original
Bedrock Agents is the original offering: a fully managed, configuration-based service. You define what the agent can do through the console or API — point it at a Knowledge Base for retrieval, attach action groups (Lambda functions as tools), write instructions — and AWS runs the entire agent loop for you. No orchestration code to maintain.
The trade-off is flexibility. Bedrock Agents orchestrates only models hosted in Amazon Bedrock, and the orchestration logic is AWS's, not yours. That's exactly what you want when the workflow is well-defined and AWS-centric, and exactly what gets in the way when you need custom control flow or model/cloud portability.
✅ Reach for Bedrock Agents when: the workflow is well-defined, you're all-in on AWS and Bedrock models, and you want a managed agent with minimal code — a support bot over a Knowledge Base, a form-filling assistant, an internal Q&A agent.
Strands Agents — the code-first, model-agnostic SDK
Strands Agents is AWS's open-source agent SDK (open-sourced in 2025). It's the opposite end
of the spectrum from Bedrock Agents: instead of configuring an agent in a console, you write
it in Python, with a model-driven loop you control. Its hallmark is how little code it takes — the
@tool decorator infers a tool's schema straight from your function signature and docstring, so a
tool definition that took ~25 lines with the raw Converse API drops to about 8. No hand-written JSON schema.
Two properties make Strands the developer favorite:
- Model-agnostic. You're not locked to Bedrock — swap the model for OpenAI, Anthropic direct, or others by changing an identifier. (See our take on choosing models in Grok Build vs. Claude and Gemini.)
- Native MCP. It speaks the Model Context Protocol out of the box, so it plugs into the growing ecosystem of MCP tools and servers.
✅ Reach for Strands when: you want code-level control over orchestration, model or multi-cloud portability, and a fast local dev loop — prototyping a custom agent, or building one whose logic doesn't fit a managed template.
Bedrock AgentCore — the production platform
Here's the one people misread. AgentCore is not a framework and not "Bedrock Agents v2." It's an agentic platform for building, deploying, and operating agents securely at scale using any framework and any foundation model — no infrastructure to manage. AWS is explicit that its services "work together or independently with any open-source framework such as CrewAI, LangGraph, LlamaIndex, and Strands Agents, and with any foundation model" in or outside Bedrock (Claude, Gemini, Nova, Llama, Mistral, OpenAI). It reached general availability in October 2025.
AgentCore is modular — you adopt the pieces you need:
| Service | What it gives your agent |
|---|---|
| Runtime | Serverless execution with true session isolation (each session in its own microVM), fast cold starts, and long-running support — execution windows up to 8 hours — plus MCP and Agent-to-Agent (A2A) protocol support. |
| Memory | Short-term (multi-turn) and long-term (cross-session) memory, shareable across agents. |
| Gateway | Turns your APIs, Lambda functions, and existing services into MCP-compatible tools — and connects to existing MCP servers — in a few lines. |
| Identity | Agent identity and auth that works with existing IdPs (Cognito, Okta, Entra ID, Auth0) — no user migration. |
| Code Interpreter / Browser | Sandboxed code execution, and a managed cloud browser for agents to navigate and extract from web apps. |
| Observability | OpenTelemetry-compatible tracing into CloudWatch — inspect every step, audit outputs, debug bottlenecks. |
| Policy / Evaluations / Registry | Cedar-based guardrails on tool calls, automated agent evaluation, and a governed catalog of agents/tools/MCP servers. |
That microVM session isolation matters: user A's runtime is physically separated from user B's — separate kernel, memory, and network namespace — so there's no cross-session data leakage. This is the kind of platform the AWS DevOps Agent is built on, and it's why AgentCore is the answer when "it works on my laptop" has to become "it runs for thousands of users with audit logs."
✅ Reach for AgentCore when: you're taking an agent to production and need session isolation, long-running execution, persistent memory, governed tool access, identity, and observability — regardless of which framework you wrote the agent in.
So how do they relate?
Think of it as a stack, from "write" to "run":
- Author the agent's logic with Strands (or LangGraph, CrewAI, etc.).
- Or skip authoring for simple cases and configure a Bedrock Agent instead — managed, low-code, Bedrock-only.
- Operate whatever you built on AgentCore — Runtime to host it, Gateway for tools, Memory for state, Identity for auth, Observability to watch it.
"Strands + AgentCore" is the pairing AWS practitioners reach for most: the open-source SDK gives you control over the agent's brain; AgentCore gives you the production body around it. Bedrock Agents stays the quickest path when your needs fit its managed template.
The decision guide
| If you want… | Use |
|---|---|
| A managed, low-code agent, AWS-only, well-defined workflow | Bedrock Agents |
| Code-level control, model/cloud portability, custom orchestration | Strands Agents |
| To run any-framework agents in production — isolation, memory, tools, identity, observability | Bedrock AgentCore |
| The common production path | Strands → AgentCore |
A useful tie-breaker question: "Am I deciding how the agent thinks, or where it lives?" Framework questions (Strands vs. a managed Bedrock Agent) are about the thinking. AgentCore is about where it lives. You'll usually answer both — and they're not the same answer.
The bottom line
The naming makes this harder than it should be, but the model is simple: Strands writes, Bedrock Agents manages, AgentCore operates. Most teams will end up writing in an open framework and running on AgentCore, dropping to Bedrock Agents only when a managed template genuinely fits. Whichever you pick, the agentic discipline is the same one we keep coming back to — the right altitude of control (workflows vs. agents vs. subagents), tight tool scoping (least privilege), and the cloud fundamentals our certification labs are built around. In the next post we put this stack to work — building a real agent with Kiro, MCP, and AgentCore.