AWS Strands Agents — 25M Downloads, Bedrock Is the Default

AWS published a “what we learned” retrospective for Strands Agents on May 15, marking one year since the SDK’s open-source launch. The headline number: 25 million Python downloads. The quieter number: Amazon Bedrock is still the default model provider, and the teams building on Strands internally — Amazon Q Developer, AWS Glue, VPC Reachability Analyzer — are all running on Bedrock. That combination of adoption velocity and platform gravity deserves a closer look.

TL;DR

• What: Strands Agents SDK crossed 25M Python downloads in its first year, shipped TypeScript 1.0, and published an internal lessons-learned retrospective
• Why it matters: The model-driven approach removes graph and state boilerplate — but the SDK was built by Bedrock teams and defaults to Bedrock
• Lock-in signal: Every “production” example in the docs and retrospective points to Bedrock; switching providers works but requires explicit configuration
• Action: Evaluate Strands for agent simplicity, but set your model provider on day one — not after you’ve built twenty tools around Bedrock defaults

AWS Strands Agents — What Happened

Strands Agents launched in May 2025 as an open-source Python SDK built by the same engineering teams behind Amazon Q Developer. The pitch was deliberately anti-LangChain: instead of chaining abstractions together, you give a model a prompt and a list of tools, and the model decides how to use them. No graph definitions, no state machines, no orchestration YAML. The SDK calls this “model-driven” development.

A year later, the numbers suggest the pitch landed. Twenty-five million downloads puts Strands in the top tier of agent framework adoption, though direct comparisons with LangChain or CrewAI at equivalent age aren’t publicly available. What is clear is that Strands grew fast enough for AWS to invest in a TypeScript 1.0 SDK (blog post published April 30, 2026), a separate experimental org called Strands Labs, and a detailed public retrospective from Clare Liguori, a Senior Principal Engineer at AWS.

The TypeScript SDK ships with full type safety, Zod-validated tool definitions, multi-agent patterns (Agent-as-Tool, Graph, and Swarm), and browser-runnable agents with no server required. The model provider list covers Bedrock, Anthropic, OpenAI, Gemini, Ollama, LiteLLM, llama.cpp, Writer, Cohere, and Mistral.

On the experimental side, Strands Labs launched in February 2026 with three projects: Robots, Robots Sim, and AI Functions. These sit in a separate GitHub org — the core SDK API stays stable while experimental features iterate independently without breaking production consumers.

Why This Matters

The agent framework market has two failure modes that keep burning teams. The first is abstraction hell: LangChain and LangGraph give you enormous flexibility but demand you understand the framework’s own mental model before you can build anything. I’ve watched senior engineers spend days debugging LangGraph state transitions when the underlying agent logic was ten lines of prompt engineering. The second failure mode is managed-harness lock-in, where a cloud provider offers a “simple” SDK that funnels you into their billing relationship before you’ve noticed.

Strands addresses the first problem directly. The model-driven philosophy means your agent’s behavior is defined by the prompt and the tools, not by framework plumbing. Community testimonials claim a reduction from roughly 40 lines of LangGraph boilerplate to around 3 lines of Strands code for an equivalent ReAct agent. I haven’t independently reproduced that specific benchmark, but the architecture supports the claim — there simply aren’t graph definitions or state schemas to write. Liguori’s retrospective adds a concrete data point: Steering Hooks (a mechanism for injecting guardrails into agent loops) achieved a 100% accuracy pass rate in their evaluations, compared to 80.8% for graph-based workflow approaches. That’s a meaningful difference for production reliability.

But here’s where the second failure mode creeps in. Strands was built by the Amazon Q Developer team. Bedrock is the default model provider — not just “supported,” but the zero-configuration path. When you instantiate an agent without specifying a provider, you get Bedrock. Every production case study in the retrospective (Q Developer, Glue, VPC Reachability Analyzer) runs on Bedrock. The documentation’s quickstart uses Bedrock. The TypeScript SDK’s getting-started guide uses Bedrock.

Strands supports a dozen model providers, but only Bedrock requires zero configuration. Every other provider — Anthropic, OpenAI, Ollama, LiteLLM — requires explicit setup. That asymmetry is by design, not by accident.

This isn’t a hidden conspiracy. It’s how platform engineering works at every cloud provider. You build the SDK, you make your service the path of least resistance, and adoption follows the defaults. By contrast, provider-first SDKs like Anthropic’s Claude Agent SDK or Google’s Vertex AI tooling are explicit about their preferred backends — you know what you’re buying into from the first line of documentation. Strands occupies a more ambiguous position: it presents as provider-agnostic while ergonomically defaulting to one provider. Compared to LiteLLM, which is purely a routing layer with no agent framework opinions, Strands bundles framework opinions and provider defaults into a single package.

What’s harder to assess from public documentation is the lock-in surface area beyond the model provider itself. If you build agents using Strands with Bedrock, then later want to switch to Anthropic direct or OpenAI, the model swap is straightforward — change the provider configuration. But session state, memory persistence, and any AgentCore integrations you’ve adopted may not transfer cleanly. The public docs don’t provide a migration guide, and the internal AWS teams have no incentive to test that path.

If you’re evaluating Strands, configure a non-Bedrock provider (Anthropic, OpenAI, or LiteLLM) in your first prototype. If Strands is provider-agnostic in practice, this costs you nothing. If it isn’t, you’ll find out before you’ve committed.

The Take

I’ve been tracking agent frameworks since before LangChain hit 1.0, and Strands is the cleanest model-driven SDK I’ve used. The philosophy is right: let the model drive, define tools as functions, skip the orchestration ceremony. If the question is “should I evaluate Strands for my next agent project,” the answer is yes — it’s earned that evaluation.

But the question I’d actually ask my team is different: “Are we comfortable with our agent infrastructure defaulting to Bedrock?” Because that’s what happens if you follow the docs, copy the examples, and don’t actively choose otherwise. Six months later, you’ve got twenty agents, forty tools, and a Bedrock bill you didn’t negotiate. The SDK is open-source. The billing relationship it nudges you toward is not.

The 25 million download number tells you Strands has momentum. The TypeScript 1.0 launch tells you AWS is investing for the long term. The retrospective tells you the internal teams are serious. None of that changes the fundamental dynamic: when a cloud provider builds your agent framework, the default provider is not a neutral technical choice. It’s a business decision someone made for you. Make it yourself instead.