The names in this area sit at different layers and get read as alternatives. What makes an application agentic in the first place comes first; the choice between frameworks goes deeper than this level needs. This card is the one framework AWS publishes.
Flash card
Strands Agents: the open-source AWS framework for building agentic AI in code, where you declare the model, the tools and a prompt, and the model plans the steps rather than you writing the control flow.
- It is model-driven. You do not write an if-then chain that says look up the subscription, then check the delivery record, then decide. You describe the job in a prompt, hand the model a set of tools, and the framework runs the loop where the model picks a tool, reads the result, and decides what to do next until the job is done. Tool usage is the mechanism; the plan is produced at run time by the model rather than at build time by you.
- It is open source and it is a library, so it runs wherever your Python runs: on a laptop while you are still working the prompt out, in an AWS Lambda function, in a container on Amazon ECS, or on the Amazon Bedrock AgentCore runtime. Nothing about the agent definition changes when it moves between those, which is why where an agent runs is a separate decision from what it is written in.
- It speaks the Model Context Protocol [MCP], the common protocol for connecting an agent to external systems. A tool exposed over MCP is reachable by any MCP-speaking agent, so an internal delivery-lookup server gets written once instead of being re-integrated for each agent that needs it.
- It is the code-first option next to Amazon Bedrock Agents, which is the console-and-configuration option. Both produce an agent that calls tools. Strands Agents puts the agent definition in a source file, so it goes through version control, code review and the test suite alongside the rest of the application, and a change to the system prompt shows up in a diff.
- Being a framework rather than a service, it brings no runtime, no memory store and no identity handling of its own. Those are what Amazon Bedrock AgentCore adds: session isolation, memory that survives across turns and conversations, a gateway that turns existing APIs into tools, and identity for an agent acting on somebody’s behalf. Framework describes the agent, runtime runs it.
Pick it when
Pick it when the team wants the agent behaviour written, versioned and tested like application code, when the tool usage is over internal services somebody has to wire up anyway, and when the agent may end up hosted somewhere other than where it started. A team already comfortable in Python gets an agent out of it faster than it gets one out of a console.
It's the wrong answer when
It is the wrong answer for a team that wants to build without writing code, where Amazon Bedrock Agents configured in the console fits better, and for a business analyst who wants answers over the organisation data, where Amazon Quick fits better. It is also not a production runtime, not an orchestration layer for several agents talking to each other, and not the thing that decides which model you use.