Strands Agents SDK

Core concepts

1. The agent is callable: agent("...") both sends the message and runs the tool-calling loop — no separate Runner or .run() call needed. Strands Docs
2. @tool decorator: Same lightweight registration pattern as the other frameworks, minimal ceremony.
3. Bedrock-first, provider-neutral otherwise: Defaults to Amazon Bedrock with zero configuration; OpenAI, Anthropic direct, Ollama, LiteLLM, and Gemini are all supported.
4. Native MCP support: Thousands of pre-built tools available through MCP servers with no custom integration code.
5. AgentCore: A companion runtime for deploying Strands agents — positions the framework as the agent-building half of a two-piece AWS-native stack.

What Is It?

Strands is AWS's open-source agent SDK used internally in Amazon Q Developer and Glue.

Emphasizes composable agents, MCP, and Bedrock model access.

Pairs with AgentCore for hosting patterns on AWS.

Why Should I Care?

If your org standardizes on Bedrock and IAM, Strands reduces glue code.

Shows up in enterprise RFPs mentioning Amazon Q extensibility.

Real World Analogy

Strands is AWS's LEGO kit where each brick clicks into Bedrock and AgentCore — fewer exotic pieces, tighter cloud fit.

Visual Mental Model

Strands agent
     -> Bedrock models
     -> MCP tools
     -> AgentCore hosting

Beginner Explanation

AWS Strands focuses on callable agents, MCP integration, and Bedrock-first deployments — lean for teams already on AWS.

Smallest Possible Example

# Strands: callable agents, MCP, Bedrock-first
print("AWS-native agent composition")

Common Mistakes

❌ Ignoring IAM least privilege on tool roles.

Agents amplify any overbroad AWS permissions.

❌ Assuming Strands replaces observability.

You still need traces and evals outside the SDK.

❌ Choosing Strands without AWS footprint.

Other frameworks may be simpler off AWS.

Real Project Example

Amazon Q Developer features build on Strands-style composition.

Enterprises on Bedrock pilot internal agents with AWS-native SDKs.

Build This Mini Project

Sketch an agent that calls one Bedrock model and one MCP tool; list IAM roles each call needs.

Interview Question

When is Strands a good fit?

When you deploy on AWS, use Bedrock models, want MCP-compatible tools, and prefer AWS-supported agent abstractions over rolling your own boto3 loops.

Key Takeaways

• Bedrock-first agent SDK.
• MCP-friendly tooling.
• Mind IAM boundaries.
• Best inside AWS estates.

Resources

• Strands Agents Docs
• GitHub: strands-agents

YouTube learning

Core concepts from video walkthroughs:

• Introducing Strands Agents — AWS open-source SDK
• Build your first agent workflow with Strands
• Build AI agents on AWS (Bedrock + Strands)

The 60-second story

Some frameworks make you meet a runner, a graph, and a config file before you ask a question. Strands lets the agent be something you call. agent("Where is order 18?") sends the message and runs the tool loop. The call is the shift. That is a small difference in spelling and a large difference in how the code reads. The work is still the same loop: model, tool, model. You just do not keep a second object around whose only job is to say “go.”

@tool is the light switch you have seen everywhere. A function becomes a tool without a ceremony. The model sees the description you bothered to write. If you did not bother, you will watch it call the wrong switch.

Bedrock is the default utility company. If you are already in AWS, the lights come on without a scavenger hunt for keys. You can still switch the utility: OpenAI, Anthropic, Ollama, Gemini, LiteLLM. The office layout stays. Native MCP means a lot of tools are already packaged as standard plugs. You do not forge a new plug for GitHub if a decent plug exists.

AgentCore is the other half of the pitch: not only build the employee, but have a place to run them that AWS already understands. Build here, deploy beside the same account, stop pretending the laptop is production.

Map the office.

• Calling the agent is running the shift.
• @tool is the labeled switch.
• Bedrock is the default utility.
• Other providers are alternate utilities.
• MCP tools are plugs that already fit.
• AgentCore is the building you move into when the laptop is no longer the office.

# the shape to remember
# result = agent("Where is order 18?")

The line is the documentation. Construction configured the employee. The call did the job.

Strands exists for people who want that shape on AWS without adopting a graph on day one. The callable agent is easier to teach. The trade is the same trade as any compact SDK: when the flow becomes a floor plan with a human approval, you may still outgrow the one call. That is not a failure. That is a sequel.

Mental model: an employee you can call like a function. Setup is the hiring packet. The call is the shift. MCP is the drawer of plugs you should check before you build a plug.

You can explain the page if you remember it is Bedrock-first, not Bedrock-only, and that the agent itself is the thing you invoke.