If you’ve built an AI agent by wiring up a giant if/else state machine, you know how fast that gets brittle. Strands Agents takes the opposite bet: let the model do the planning, and you supply a prompt and a list of tools. It’s an open-source SDK from AWS, released in May 2025 under the Apache License 2.0, and it powers production agents inside Amazon teams like Amazon Q Developer and AWS Glue.
What Strands Agents actually is
Strands Agents is an SDK for building and running AI agents in a few lines of code. You give an agent three things: a model, a system prompt, and a set of tools. The model reads the prompt, decides which tools to call, runs them, looks at the results, and keeps going until the task is done. That cycle is the whole product.
It ships for Python and TypeScript. The name is a nod to the two strands that make up an agent: the model and the tools. AWS open-sourced it after running it internally, so the design reflects production needs, not a demo. Since the preview launch it crossed 150K-plus PyPI downloads and reached a 1.0 release that added multi-agent primitives and Agent-to-Agent (A2A) protocol support.
If you’ve read about other agent SDKs, the shape will feel familiar. Strands sits in the same category as LangGraph and Google ADK, but it leans harder on the model to drive control flow instead of asking you to draw the graph yourself.
The model-driven philosophy vs hard-coded orchestration
Most early agent frameworks asked you to define the workflow up front. You’d build nodes, edges, and conditions, then route the model through them. That works, but every new capability means more graph to maintain.
Strands flips the responsibility. Modern models already plan, chain reasoning, call tools, and reflect on results. So instead of encoding that logic by hand, you describe the goal and hand over the tools. The model figures out the steps.
Here’s the contrast in plain terms:
| Approach | You define | Control flow lives in | Cost of a new capability |
|---|---|---|---|
| Hard-coded orchestration | Nodes, edges, conditions, routing | Your graph code | Edit the graph, retest paths |
| Model-driven (Strands) | Prompt + tool list | The model’s reasoning loop | Add a tool, update the prompt |
The trade-off is real. Model-driven agents are faster to build and adapt, but you give up some determinism. For workflows that must run the same way every time, you can still add structure with multi-agent patterns and hooks. The point isn’t that graphs are wrong; it’s that you reach for them when you need them instead of by default.
A minimal agent
The smallest useful Strands program is short. You import the Agent class, optionally define a tool with the @tool decorator, and call the agent like a function.
from strands import Agent, tool
@tool
def word_count(text: str) -> int:
"""Count the words in a block of text."""
return len(text.split())
agent = Agent(
system_prompt="You are a concise writing assistant.",
tools=[word_count],
)
response = agent("How many words are in this sentence?")
print(response)
The @tool decorator turns a plain Python function into something the model can call. Your docstring and type hints become the tool’s description and input schema, so the model knows when and how to use it. There’s no separate registry to maintain. Calling agent(...) runs the loop until the model decides it’s finished.
Tools and model providers
Tools are how the agent touches the outside world. A tool can be a Python function you wrote, a packaged tool from the community, or an entire Model Context Protocol (MCP) server exposed to the agent.
On the model side, Strands is provider-flexible. The default provider is Amazon Bedrock, and out of the box an agent uses a Claude Sonnet model in the us-west-2 region (the exact default model ID has moved across SDK versions, so check your installed version rather than hard-coding it). You can point it elsewhere:
- Any Amazon Bedrock model that supports tool use and streaming
- Anthropic’s Claude family through the Anthropic API
- Llama models via the Llama API
- Ollama for local development
- Other providers such as OpenAI through LiteLLM
Swapping providers is a model-object change, not a rewrite. The agent loop, your tools, and your prompt stay the same. That makes it practical to develop against a local Ollama model and ship on Bedrock.
Multi-agent and MCP support
A single agent handles a lot, but real systems often need several. Strands 1.0 added primitives for multi-agent applications, including an Agent-as-Tool pattern where one agent calls another agent the same way it calls any tool, and Swarm-style coordination for groups of agents working a problem together. It also supports the A2A protocol, so Strands agents can talk to agents built on other frameworks.
MCP is a first-class citizen. The Model Context Protocol is an open standard for connecting models to tools and data sources. With Strands you can connect to published MCP servers and use their tools directly, which means thousands of existing integrations become available without custom glue code. You manage the connection through an MCP client and pass its tools to the agent like any other tool list.
If you’re already running MCP servers, this is the cheapest way to give an agent new capabilities. The tradeoff is that you now depend on those servers behaving, which is one reason testing the underlying endpoints matters.
Deploying a Strands agent
Strands is built to go from your laptop to production without a framework change. You test locally, then deploy to the target that fits your stack:
- Amazon Bedrock AgentCore for a managed agent runtime
- AWS Lambda for event-driven, short-lived agents
- AWS Fargate or Amazon EKS for containerized, long-running services
- Plain Docker anywhere you can run a container
Because the agent is ordinary Python or TypeScript, packaging it follows the same rules as any app. AWS also documents observability hooks, so you can trace what the model decided and which tools it called once the agent is live.
Where Apidog fits
Strands builds the agent. It doesn’t build the APIs your agent calls, and that’s the gap worth planning for. Every Strands agent leans on two kinds of HTTP endpoints: the LLM provider API behind the model, and the REST or tool APIs behind your @tool functions and MCP servers. If those endpoints misbehave, the agent fails in ways that look like model problems but aren’t.
Apidog is where you test and mock those underlying APIs before the agent ever touches them. A few concrete uses:
- Mock the model or a tool endpoint while you iterate on the loop, so you don’t burn tokens or hit rate limits on every run. The article on building an AI agent test harness with Apidog shows the pattern.
- Assert tool response shapes so a tool that returns a malformed payload gets caught in a test, not in production. See the guide to API assertions for how to validate fields, types, and status codes.
- Stand up a mock API that mimics a real service’s responses, including error cases your agent needs to handle gracefully.
- Manage API keys per environment so your dev, staging, and prod agents authenticate against the right backends without leaking credentials into code.
To be clear, Apidog isn’t an agent framework and doesn’t orchestrate anything. Strands stays the brain. Apidog is the workbench for the plumbing underneath it. You can download Apidog and wire up mocks for your tool endpoints in a few minutes.
When to use Strands Agents
Reach for Strands when you want to move fast and trust the model to plan. It fits well if you’re on AWS and already using Bedrock, if you want to start with one agent and grow into multi-agent later, or if you want MCP tools without writing integration code.
It’s a weaker fit when you need strict, auditable, deterministic flows where every branch must be predefined. You can still get there with hooks and multi-agent structure, but a graph-first framework may be a more direct match. The honest framing is that model-driven and graph-driven approaches solve different problems, and Strands is the model-driven one.
Frequently asked questions
Is Strands Agents free and open source?
Yes. Strands Agents is open source under the Apache License 2.0, with the source on GitHub. There’s no license fee for the SDK. You pay for the model and any cloud resources you deploy to, like Bedrock inference or Lambda execution, but the framework itself costs nothing.
Do I have to use Amazon Bedrock with Strands?
No. Bedrock is the default provider, but Strands supports Anthropic’s API, the Llama API, Ollama for local runs, and other providers through LiteLLM. You change the model object and keep the rest of your code. That makes it easy to prototype locally and switch to a managed provider for production.
What’s the difference between Strands and a graph-based framework?
Strands is model-driven: you supply a prompt and tools, and the model decides the steps. Graph-based frameworks ask you to define the control flow as nodes and edges. Strands is faster to build and adapt; graph frameworks give you tighter, more predictable execution. Many teams use both for different services.
How do I test the APIs my Strands agent depends on?
Test them independently of the agent, before and during development. Mock the LLM and tool endpoints, assert their response shapes, and run those checks in CI. A tool like Apidog handles the mocking and assertions, and the walkthrough on testing the ChatGPT API with Apidog covers auth, streaming, and tool-call testing that maps directly to agent backends.
Conclusion
Strands Agents is a clean take on building agents: define a model, a prompt, and tools, then let the model run the loop. It scales from one agent to many, speaks MCP and A2A, and deploys across the AWS stack without a rewrite. The framework handles the reasoning. Your job is making sure the APIs underneath it are solid, and that’s exactly where Apidog earns its place, mocking and testing the endpoints your agent calls so failures surface in your tests instead of in production.
