What Are Strands Agents? AWS's Open-Source Agent SDK

// In plain English

Strands Agents is an open-source Python SDK from AWS for building AI agents — programs that don't just answer a question once, but loop: think, call a tool, read the result, think again, and keep going until the task is done. Strands' whole personality is captured in one phrase it uses about itself: model-driven. Instead of you writing a rigid script that says "first do A, then B, then C," you hand the model a goal and a box of tools, and let the model's own reasoning decide what to do next.

Picture hiring a capable assistant versus following a paper checklist. A checklist (the old way) has a fixed sequence: every step is written down in advance, and if reality doesn't match the script, it breaks. A good assistant (the Strands way) is different — you say "book me a flight to Berlin under $400 next Tuesday," hand them a phone, a calendar, and a company card, and trust them to figure out the order of operations themselves. They check the calendar, search flights, notice Tuesday is a holiday, adjust, and come back with a booking. You described the destination; they planned the route.

That's the bet Strands makes: modern models like Claude are now good enough at reasoning that the smartest place to put the planning logic is inside the model, not in your code. Your job shrinks to three things — pick a model, give it a clear instruction (the system prompt), and register the tools it's allowed to use. Strands runs the loop and gets out of the way.

// Why it matters

Most agent frameworks ask you to draw the control flow yourself — nodes, edges, branches, retries. That gives precise control but it's a lot of plumbing, and every time the model gets smarter, your hand-drawn flowchart becomes the thing holding it back. Strands flips the default: write less orchestration, trust the model more. Here is why a builder cares.

• Less boilerplate to ship a working agent. A useful Strands agent is genuinely a few lines: create an Agent, pass it a list of tools, call it with a prompt. There is no graph to define, no state machine to wire. For prototypes and many production agents, that's the whole program.
• It rides the model's improvements for free. Because the planning lives in the model, swapping a smarter model in often makes your agent better without changing any of your code. A framework built on hardcoded steps can't do that — its logic is frozen in your source.
• First-party AWS deployment story. Strands is built by AWS, so the path from laptop to production is short: the same agent runs locally, then deploys to Amazon Bedrock, AWS Lambda, Fargate, or EC2 with the framework's own helpers. If your stack already lives on AWS, that integration is a real advantage.
• Native tools and protocol support. Tools are ordinary Python functions you mark with a decorator. Strands also speaks the Model Context Protocol (MCP), so it can plug into the growing ecosystem of pre-built tool servers without custom glue.

Who should reach for it? Teams that want to ship an agent quickly, especially on AWS; people who believe the model should do the planning and want the framework to disappear; and anyone tired of maintaining a brittle orchestration graph that fights the model instead of helping it. Who should be cautious? Workflows that legally or operationally must follow an exact, auditable sequence — there, you may want explicit control (see the comparison below).

// How it works

At its core Strands runs the classic agentic loop: the model receives the goal and the list of available tools, decides whether to answer directly or call a tool, the SDK executes the chosen tool, feeds the result back, and the model decides again. This repeats until the model produces a final answer with no further tool calls. The loop is the engine; the model is the driver.

The word model-driven points at the Decide step. In a graph framework, you wrote the branch that says when to call which tool. In Strands, the model makes that call using tool use / function calling: you give it tool names, descriptions, and input schemas, and it chooses. Strands' job is to present the tools cleanly, run them safely, and keep the conversation history so the model always sees what already happened.

Tools are just decorated Python functions

You don't describe tools in a config file. You write a normal function, add the @tool decorator, and Strands turns its name, docstring, and type hints into the schema the model needs. The docstring is not a comment — it's the instructions the model reads to decide when and how to use the tool, so write it for the model, not for yourself.

from strands import Agent, tool

@tool
def get_weather(city: str) -> str:
    """Get the current weather for a city.

    Args:
        city: The city name, e.g. "Berlin".
    """
    # Call a real weather API here; stubbed for the example.
    return f"It is 18C and sunny in {city}."

# The model plans; the tools are what it's allowed to do.
agent = Agent(
    system_prompt="You are a concise travel assistant.",
    tools=[get_weather],
)

result = agent("Should I pack a coat for Berlin tomorrow?")
print(result)

Notice what's missing: no loop, no "if the model asked for weather, call the function, then ask again." Calling agent(...) runs the entire loop above. The model reads the question, decides it needs get_weather, Strands runs it, the model reads "18C and sunny," and answers. Behind that one line is the cycle, repeated as many times as the task needs.

From the schema's point of view

Concretely, the decorator hands the model a tool definition that looks roughly like the JSON below. The model never sees your Python — it sees this contract, and it decides whether to invoke it.

{
  "name": "get_weather",
  "description": "Get the current weather for a city.",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "The city name" }
    },
    "required": ["city"]
  }
}

// Strands vs LangGraph: two philosophies

The clearest way to understand Strands is to put it next to LangGraph, the best-known graph-based framework. They sit at opposite ends of the same spectrum: how much control over the flow do you keep, and how much do you hand to the model?

Neither is "better" — they optimize for different things. A graph gives you a deterministic, inspectable path: great when a regulator, a refund policy, or a safety rule says step 3 must always follow step 2. A model-driven loop gives you flexibility and brevity: great when the task is fuzzy and you'd rather trust the model's judgment than predict every branch in advance. Many teams even mix them — a deterministic outer workflow with a model-driven agent doing one open-ended step inside it.

// From laptop to production

A common letdown with agent frameworks is that the demo runs on your machine but production is a second project. Strands is designed to shorten that gap, especially on AWS. The same agent object you tested locally is what you deploy — you change where it runs, not what it is.

The deployment choice is mostly about shape of traffic, not about rewriting the agent. A chatbot that answers occasional requests fits Lambda; a service that streams long conversations fits a container on Fargate; and Bedrock supplies the models and a managed runtime underneath. Strands provides starter patterns for each so you're not inventing the wiring.

// Common pitfalls

Model-driven simplicity is liberating until it isn't. Most Strands trouble comes from forgetting that the model is now in charge, which means the model needs clear instructions where you used to write explicit code.

• Vague tool docstrings. The model picks tools by reading their descriptions. A terse or misleading docstring leads to the wrong tool, wrong arguments, or a tool that never gets called. Treat docstrings as prompt engineering, because they are.
• No guardrails on dangerous tools. "Let the model drive" means the model can call any tool you give it, in any order. A tool that deletes records or spends money needs validation, confirmation, or a permission check inside the tool — never assume the model won't call it.
• Runaway loops. An agent can get stuck calling tools forever if the task is impossible or the result never satisfies it. Set a maximum number of loop iterations (a step or turn limit) so a confused agent fails fast instead of burning tokens.
• Treating tool output as trusted. A tool that fetches a web page or reads a user file returns text the model will obey. Hidden instructions in that text are prompt injection — sanitize and fence retrieved content, and never let tool output silently grant new powers.
• Expecting determinism. The same prompt can produce a different tool sequence on different runs. If you need the exact same path every time, that's a sign the step belongs in explicit code, not in the model's hands.

// Going deeper

Once the basic loop clicks, the interesting questions are about scale, structure, and control. A few directions worth knowing as you grow a Strands agent past its first demo.

MCP and reusable tools. Beyond hand-written @tool functions, Strands connects to Model Context Protocol servers — standardized, pre-built tool providers for things like file systems, databases, and SaaS APIs. Instead of writing the same database tool in every project, you point your agent at an MCP server and the tools appear. This is increasingly how agents reach data and services they weren't trained on.

Multi-agent patterns. One model-driven agent is a building block, not the ceiling. You can have a coordinator agent call specialist agents as if they were tools — a research agent, a coding agent, a reviewer — each with its own prompt and tool set. The model-driven philosophy scales up: the coordinator decides which specialist to delegate to, rather than you hardcoding the routing.

Observability and tracing. When the model plans the steps, you lose the comfort of reading them off a graph — so you need traces. Strands integrates with standard observability tooling (OpenTelemetry-style tracing) so you can see, after the fact, exactly which tools the agent called, with what arguments, and why. For a model-driven system, tracing isn't a nice-to-have; it's how you debug at all.

Where it sits among the SDKs. Strands is one of several first-party agent SDKs that all share this lean, model-driven shape — alongside the Claude Agent SDK, the OpenAI Agents SDK, and Google's ADK. They differ mainly in their home ecosystem and deployment story rather than core idea. If you're choosing between them, start from where your models and infrastructure already live, then compare the agent frameworks on tooling, multi-agent support, and how much control you want to keep versus hand to the model.

The durable lesson is the one Strands is built around: as models get better at reasoning, the value of hand-written orchestration falls and the value of clear goals, well-described tools, and good guardrails rises. Strands is a bet that the framework's job is to disappear — to run a clean loop, present tools faithfully, and let the model do the thinking it's increasingly good at.