AWS Strands Agents: The Model-Driven Agent Framework and What It Commits You to Operating

AWS Strands Agents is an open-source SDK for building AI agents in Python and TypeScript, launched by AWS in May 2025 and taken to 1.0 on July 15, 2025. A Strands agent is a model, a system prompt, and a list of tools — usually three lines of code — and the model itself runs the loop: it plans, calls tools, reflects, and decides when it is done. Adoption has been quick: 25 million downloads in the SDK's first year, a release most weeks (Python v1.45.0 as of late June 2026), and production workloads inside Amazon Q Developer and AWS Glue.

That is the what. What follows: which multi-agent pattern fits which job, how the MCP integration works, what the Amazon Bedrock AgentCore path costs, where Strands beats LangGraph and the OpenAI Agents SDK and where it loses — and the operations bill you sign the day you standardize on it.

The Core Bet: The Model Drives, You Do Not Draw the Graph

Every agent framework makes one structural bet. LangGraph's bet is that the developer should draw the control flow: nodes, edges, explicit state. Strands bets the other way — that current models plan and pick tools well enough that most of that scaffolding is wasted effort. You hand the model a prompt and a toolbox; Strands runs the loop, executes whatever tool the model picks, appends the result to context, and repeats until the model says done.

The practical consequence is code volume. A working Bedrock-backed agent with a handful of tools is genuinely a few lines, and the demo-to-deployable gap is smaller because there is no graph to grow. AWS cited Amazon Q Developer, AWS Glue, and VPC Reachability Analyzer as internal production users on launch day.

The trade is control. When the model drives, the path through a task is a probability distribution, not a flowchart. For research, triage, and ops assistants, that is fine and often better. For a loan-approval pipeline where step 4 must always follow step 3, it is a liability — which is exactly why Strands grew deterministic patterns on top of the loop.

One boundary early: Strands is the build option. How teams should work with agents is methodology, covered in our AI-DLC writeup; buying packaged agents instead of a framework is the territory of Claude Cowork for the enterprise.

Strands Agent Multi-Agent Patterns, Mapped to Real Decisions

The 1.0 release shipped four multi-agent primitives — agents-as-tools, handoffs, swarms, and graphs — plus support for the Agent2Agent (A2A) protocol. The docs today organize multi-agent work into five concepts: agents-as-tools, swarm, graph, workflow, and A2A. They compose: a graph node can be a swarm, a swarm member can carry other agents as tools. Here is each with a when-to-use verdict; for the framework-neutral taxonomy behind them, see our guide to multi-agent orchestration patterns.

Agents-as-tools: the manager and the specialists

A specialist agent is wrapped as a callable tool and handed to an orchestrator, which routes to it like any function — pass the agent straight into the tools list, or use .as_tool() for custom names and descriptions. Verdict: the default starting point for hierarchical delegation, like a triage agent fronting a billing specialist and a technical one. Cheap to reason about, easy to test each specialist alone.

Swarm: autonomous handoffs on a shared task

A swarm is a flat team with shared working memory; any member can hand control to the most suitable peer, with a summary of completed work and context for the recipient. Verdict: use it when the route through the problem is unknowable up front — open-ended research, incident investigation. Avoid it where you must explain the path afterward; the first swarm transcript we reviewed in anger took three engineers an afternoon to reconstruct.

Graph: deterministic routing when the process is the point

A graph is a developer-defined flowchart of agents with conditional edges. Approvals, quality gates, compliance checkpoints. Verdict: reach for it whenever an auditor might ask "why did the agent do X after Y." It is Strands conceding that sometimes the LangGraph bet is right — as one pattern, not the whole framework.

Workflow: a DAG packaged as one tool

A workflow is a predefined task graph (a DAG) executed as a single, non-conversational tool. Verdict: use it for the boring, stable pipelines inside an otherwise dynamic agent — fetch, transform, summarize, file.

Handoffs and A2A: humans and other people's agents

The handoff primitive also covers escalation to a human with conversation context preserved — the pattern nobody demos and every production deployment needs. A2A extends the idea across organizational boundaries: A2AServer exposes a Strands agent over the open protocol with an auto-generated agent card, and A2AAgent consumes a remote agent as if it were local. Verdict: A2A matters when agents are owned by different teams or vendors; if all your agents live in one repo, skip it for now.

Strands MCP Integration: The Tool Story That Sets the Framework Apart

Tools are where agent frameworks rot. Every internal API needs a hand-written wrapper, the wrappers drift, and two years later the tool layer is its own unowned codebase. Strands' answer is to make the Model Context Protocol the primary way tools reach an agent — in the core SDK, in both languages, not as an add-on.

How a Strands agent consumes an MCP server

The mechanics, as documented: the MCPClient class connects to an MCP server over stdio, Streamable HTTP, or SSE, discovers the tools the server publishes, and exposes them to the agent with no custom integration code. It drops straight into the Agent constructor and behaves as a context manager — connection setup, tool calls, and cleanup are scoped to a with block, and calls outside that block fail loudly rather than leak.

The multi-server story is the part that ages well. The Python client supports tool filtering and name prefixing, so an agent can mount three MCP servers with overlapping tool names and see exactly the tools you chose from each. The first time we pointed a Strands agent at an internal MCP server, the tool plumbing we had budgeted a week for mostly did not exist — discovery did it.

Where MCP-native stops being a checkbox

Honesty requires saying MCP support is no longer rare — the OpenAI Agents SDK has built-in MCP tool calling, and LangGraph consumes MCP servers through adapters. The difference is emphasis. In Strands, MCP is the assumed tool distribution mechanism, which changes organizational behavior: teams publish capabilities once as MCP servers, and every agent — Strands or otherwise — consumes them. Ten agents each mounting five MCP servers is exactly the fan-out that makes centralized auth, discovery, and audit worth having — the MCP gateway problem, and it arrives faster than teams expect.

From Laptop to AgentCore: The Production Path

A Strands agent is plain code, so it deploys anywhere Python or Node runs — the docs cover Lambda, Fargate, App Runner, EKS, and plain containers. But the path AWS has clearly invested in is Amazon Bedrock AgentCore, GA since October 13, 2025 in nine regions. This is where the framework decision turns into an infrastructure decision.

Runtime and its siblings

AgentCore Runtime is a serverless runtime purpose-built for agents: long-running sessions, session isolation, no servers to manage. Around it sit Gateway (turns APIs and Lambda functions into MCP-compatible tools), Memory (managed short- and long-term context), Identity (brokers credentials so agents call AWS and third-party services without hand-rolled token storage), and Observability (metrics and traces across all of it). Built-in Browser and Code Interpreter tools ship alongside; Policy and Evaluations entered preview in December 2025. Worth underlining: AgentCore is framework-agnostic — it runs LangGraph, CrewAI, and OpenAI Agents SDK workloads too — and model-agnostic. For the main non-AWS alternative, see AWS AgentCore vs Azure AI Foundry; for where it sits in the broader platform decision, Bedrock vs SageMaker covers the control plane.

What it costs to run

AgentCore is consumption-billed with no upfront commitment. Figures below verified on the AgentCore pricing page as of July 2026 — model tokens are billed separately by your provider:

One detail worth noticing: agents spend 30 to 70 percent of a session waiting on model and tool I/O, and AgentCore does not bill CPU during that idle time — far cheaper than keeping a container warm.

Models: Bedrock by default, not by requirement

Strands defaults to Bedrock but is not locked to it. The docs list more than a dozen official model providers — Anthropic direct, OpenAI, Google, Mistral, Ollama, llama.cpp, SageMaker endpoints, and a LiteLLM adapter reaching most of the rest — plus roughly ten community providers. Developing against Ollama on a laptop and shipping against Bedrock in production is a supported, documented path, not a hack.

Strands vs LangGraph vs the OpenAI Agents SDK

One-line verdicts:

• Control flow: LangGraph, when the process must be explicit and durable.
• Speed to a working agent: Strands and the OpenAI SDK tie, both far ahead of LangGraph.
• Ecosystem gravity: the OpenAI SDK inside an OpenAI-committed shop — its hosted tools (computer use, voice) have no Strands equivalent.
• AWS alignment: Strands, without contest — same vendor for SDK, runtime, and default model plane.

The honest summary: these frameworks are converging on each other's features. The durable differences are the default control-flow bet and the ecosystem each assumes. Pick the one whose defaults match your stack, not the longest feature list.

The Platform Bill: What Choosing Strands Commits You to Operating

Here is the section the launch-week explainers do not write. A framework is maybe 15 percent of a production agent platform. Standardize on Strands and you have chosen how agents get built; you have not yet chosen how they get observed, evaluated, gated, or governed — and all four bills come due before the first serious incident.

• Observability. Strands emits OpenTelemetry traces natively, which is genuinely good — but a trace with nobody watching is a log file with better marketing. You still need a backend, retention, and someone who can read an agent trajectory and say whether it was healthy. See agent observability for what that means beyond APM, and LLM observability for the trace layer underneath.
• Evaluation. The SDK ships zero evals. A swarm that resolves 84 percent of tickets this month can quietly drop to 70 after a model update, and nothing in the framework will tell you. Trajectory-level scoring — did the agent take a sane path, not just produce a plausible answer — is its own discipline, covered in AI agent evaluation and testing.
• Gateway. Ten Strands agents each mounting MCP servers means credentials, allowlists, and audit trails multiplying fast. AgentCore Gateway handles tool fronting inside AWS; the broader control point — one place where every agent's outbound tool access is authenticated, authorized, and logged — is the agent gateway layer.
• Registry. Once agents call agents — agents-as-tools internally, A2A across teams — someone must answer what agents exist, who owns each, and what each may touch. That inventory question is the agent orchestration layer, and it is easier to stand up at three agents than at thirty.

None of this is a knock on Strands. It is the going rate for running any agentic AI system in production, whichever framework you pick. The mistake is believing the three-line demo is the total cost.

When Strands Is the Wrong Choice

Say it plainly.

• Your workflows are fixed pipelines with an LLM step in the middle. You need a queue and a model API, not an agent framework. The model-driven loop adds nondeterminism you will spend months constraining back out.
• You are an OpenAI-platform shop using hosted computer use or voice agents. The OpenAI Agents SDK's native integration there is not worth trading for neutrality you will not exercise.
• You have a large working LangGraph estate. Migration buys you different defaults, not a capability you lack.
• Regulators require a provable execution path for every run. Strands Graph gives determinism where you draw it; if the whole system must be auditable step-by-step, graph-first — or no agent at all — is the safer posture.
• You wanted to buy, not build. A framework choice is a hiring and operations choice. If no team will own the platform bill above, packaged agents are the honest answer.

For an AWS-leaning shop building custom agents with a real platform team behind them, though, Strands is currently the strongest default on the board: shortest path from idea to agent, the deepest MCP posture of the three majors, and a managed runtime built for it.

Frequently Asked Questions

What is AWS Strands Agents?

Strands Agents is an open-source SDK from AWS for building AI agents in Python and TypeScript, first released in May 2025 with a 1.0 in July 2025. It is model-driven: the model plans, selects tools, and decides when the task is complete, with Strands handling tool execution in a loop. It passed 25 million downloads in its first year.

Is Strands Agents free, and does it require AWS?

The SDK is open source under the Apache-2.0 license. Amazon Bedrock is the default model provider, but the docs list more than a dozen alternatives — Anthropic direct, OpenAI, Google, Mistral, Ollama, and others — so you can build and run Strands agents with no AWS account. The AWS-managed pieces like AgentCore are optional and consumption-billed.

How does a Strands agent use MCP servers?

The built-in MCPClient connects to an MCP server over stdio, Streamable HTTP, or SSE, discovers its published tools automatically, and exposes them to the agent without custom wrapper code. It runs as a context manager so connection lifecycle is explicit, and the Python client adds tool filtering and name prefixing so one agent can safely mount several MCP servers at once.

What is the difference between Strands Agents and Amazon Bedrock AgentCore?

Strands is the SDK you write the agent with; AgentCore is the managed AWS infrastructure you can run it on — Runtime for serverless execution, plus Gateway, Memory, Identity, and Observability. They are decoupled: Strands agents deploy to Lambda, Fargate, EKS, or any container, and AgentCore runs LangGraph, CrewAI, or OpenAI Agents SDK agents just as well.

Which multi-agent patterns does Strands support?

The current documentation covers five multi-agent concepts: agents-as-tools, swarm, graph, workflow, and the A2A protocol for exposing or consuming agents across platform boundaries. The patterns compose freely — a graph node can itself be a swarm.

Should I choose Strands Agents or LangGraph?

Choose by control-flow default. Strands assumes the model drives and you add determinism only where needed; LangGraph assumes you draw the execution graph — stronger when the process must be explicit, durable, and auditable end to end. For an AWS-centric stack wanting the fastest path to a working agent with first-class MCP support, Strands is the better default.

References

1. AWS Open Source Blog — Introducing Strands Agents, an Open Source AI Agents SDK (May 2025). https://aws.amazon.com/blogs/opensource/introducing-strands-agents-an-open-source-ai-agents-sdk/
2. AWS Open Source Blog — Introducing Strands Agents 1.0: Production-Ready Multi-Agent Orchestration Made Simple (July 2025). https://aws.amazon.com/blogs/opensource/introducing-strands-agents-1-0-production-ready-multi-agent-orchestration-made-simple/
3. Strands Agents documentation — Multi-agent patterns. https://strandsagents.com/docs/user-guide/concepts/multi-agent/multi-agent-patterns/
4. Strands Agents documentation — Model Context Protocol (MCP) tools. https://strandsagents.com/docs/user-guide/concepts/tools/mcp-tools/
5. AWS documentation — What is Amazon Bedrock AgentCore. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html
6. GitHub — strands-agents organization (SDK source, samples, and tools). https://github.com/strands-agents
7. Strands Agents blog — What We Learned from One Year of Building Production Agents (May 15, 2026; source of the 25-million-downloads figure). https://strandsagents.com/blog/what-we-learned-from-one-year-of-building-production-agents/