Strands vs LangGraph: Model-Driven vs Graph-Based Agent SDKs (2026)

TL;DR: Strands Agents is an open-source, model-driven SDK from AWS where the LLM controls the agent loop, so a working tool-calling agent takes under 20 lines of code. LangGraph is an open-source, graph-based framework from the LangChain team where you define an explicit state machine, trading more code for deterministic control, checkpointing, and human-in-the-loop gates. Choose Strands for speed and simplicity when you trust the model to drive. Choose LangGraph when your workflow needs branching, cycles, approval steps, or auditable state transitions. Both are free, both run any model, and both deploy on AWS AgentCore Runtime.

Key Takeaways

• Strands takes a model-driven approach: you supply a system prompt and tools, and the LLM decides which tools to call and when, with the framework staying out of the way.
• LangGraph takes a graph-driven approach: you define nodes, edges, and a typed state object, making every decision path explicit, inspectable, and reproducible.
• Strands minimizes code — a functional agent is under 20 lines; the same agent in LangGraph often needs 40 or more once you wire up state, nodes, and edges.
• LangGraph's checkpointing enables pause/resume, time-travel debugging, and crash recovery — capabilities Strands does not provide natively because it delegates control flow to the model.
• Both are model-agnostic (Bedrock, Anthropic, OpenAI, Ollama, and more) and both offer Python and TypeScript SDKs, so neither locks you to a single provider.
• They occupy the same layer of the stack (agent logic), making them genuine alternatives — but each can be packaged and deployed on Amazon Bedrock AgentCore Runtime for managed hosting.

What are Strands Agents and LangGraph?

Building an AI agent means writing the loop that lets a language model reason, call tools, observe results, and decide what to do next. In 2026, two open-source SDKs represent opposite philosophies for writing that loop, and the choice between them shapes how much control you keep versus how much you hand to the model.

Strands Agents is a lightweight, code-first SDK that AWS open-sourced in 2025. Its defining principle is that the model drives the agent. You define tools as plain Python functions, write a system prompt, and hand both to an Agent object. From there, the LLM runs its own reasoning loop: it inspects the request, decides which tool to invoke, reads the output, and iterates until the task is done. Strands deliberately keeps its abstraction thin so that improvements in model reasoning translate directly into better agent behavior without framework changes. It ships for both Python and TypeScript and defaults to Amazon Bedrock while supporting many other providers.

LangGraph is an open-source framework built by the LangChain team, released under the MIT license. Its defining principle is that the developer drives the agent through an explicit graph. You model the workflow as a directed graph where nodes perform computation (an LLM call, a tool execution, a data transform) and edges decide what happens next based on a typed state object. Every node reads and writes that state, and LangGraph checkpoints it at each step. This makes agent behavior deterministic given the same inputs, and it enables cycles, conditional branching, parallel execution, and human-in-the-loop pauses that a simple model-driven loop cannot express cleanly.

The distinction is not managed-versus-open-source (both are open source) or infrastructure-versus-logic. It is a genuine philosophical fork: how much of the control flow do you delegate to the model, and how much do you encode yourself?

How do Strands and LangGraph differ architecturally?

Strands treats the agent loop as an emergent property of the model. There is no explicit state machine to design. You register tools, and the model's function-calling ability decides the sequence of actions at runtime. If the model decides it needs to call a search tool, then a calculator, then answer, that ordering was never written by you — it emerged from the model's reasoning. This is powerful because it requires almost no orchestration code, and it improves automatically as models get better at planning. The cost is determinism: the same prompt can produce different tool-call sequences on different runs, which makes strict reproducibility and auditability harder.

LangGraph treats the agent loop as a state machine you design. You declare a state schema (typically a Python TypedDict), add nodes, and connect them with edges — some unconditional, some conditional on the current state. The model still makes decisions inside nodes, but the topology of what can happen next is fixed by your graph. This is more work upfront, but it gives you a workflow engine: you can enforce that a "human approval" node always runs before a "send email" node, route errors to a recovery node, or fan out to parallel nodes and merge their results. Because state is explicit and checkpointed, you can replay execution from any prior step.

A useful mental model: Strands is a smart intern you brief and trust to figure out the steps; LangGraph is a flowchart the intern must follow. The intern is faster to onboard; the flowchart is easier to audit.

How do Strands and LangGraph compare at a glance?

How much code does each require?

The clearest practical difference shows up in a minimal example. Here is a customer-support agent in Strands. Tools are ordinary Python functions; the @tool decorator reads the signature and docstring so the model knows how and when to call them.

That is the entire agent. The model decides to call get_order_status first, reads the result, and — following the system prompt — only then calls issue_refund. You wrote no control flow.

The same behavior in LangGraph is more verbose because you encode the flow explicitly. That verbosity is the point: the "verify before refund" rule becomes a structural guarantee rather than a prompt instruction the model might ignore.

With LangGraph, the refund physically cannot happen until the graph passes through the approval node, and the interrupt_before clause pauses execution so a human can inspect and approve. Strands would enforce that same rule only as far as the model reliably follows the system prompt. For low-stakes tasks, the Strands version is faster to build and easier to read. For a financial action, LangGraph's structural guarantee is worth the extra lines.

How do they handle state and memory?

State is where the two SDKs diverge most sharply.

In Strands, the model manages its own working context. The framework keeps a conversation history and passes it back to the model, but it does not impose a typed state object or checkpoint execution. For shared configuration across multi-agent runs, Strands offers an invocation_state mechanism that propagates values (like a user_id or database handle) to agents and tools without exposing them in the prompt. This is simple and adequate for conversational agents, but it does not give you step-level execution snapshots.

In LangGraph, state is a first-class, typed object. Every node receives the current state and returns updates to it, and the checkpointer persists a snapshot at each step. You can back checkpoints with in-memory storage for development or PostgreSQL and SQLite for production. Because every step is saved, LangGraph supports three capabilities Strands does not provide natively:

• Pause and resume: stop mid-workflow (for human approval or an external event) and continue later from the exact saved state.
• Time-travel debugging: replay execution from any prior checkpoint to reproduce and diagnose a bug.
• Crash recovery: resume a long-running agent from its last checkpoint instead of restarting.

If your agent is a multi-turn conversation, Strands' lighter model is enough. If your agent is a long, multi-step process where losing progress is expensive — a data pipeline, a multi-stage research task, an approval workflow — LangGraph's checkpointing earns its complexity.

How do Strands and LangGraph support multi-agent systems?

Both SDKs scale beyond a single agent, but with different primitives.

Strands ships several composable multi-agent patterns:

• Agents-as-tools: wrap one agent as a tool another agent can call, creating hierarchies of specialists.
• Swarm: a set of agents that collaborate with shared context, handing off to each other.
• Graph: connect agents as nodes with edges for a deterministic pipeline of specialists.
• Workflow: orchestrate multi-step sequences across agents.

Notably, a Strands Swarm can be nested as a single node inside a Strands Graph, so you can compose a team of researchers into a larger analysis pipeline. Shared state flows through invocation_state, keeping configuration out of the prompt.

LangGraph approaches multi-agent design through subgraphs and supervisor patterns. Because every agent is itself a graph, you compose systems by embedding subgraphs as nodes in a parent graph, or by building a supervisor node that routes work to worker agents based on state. The same checkpointing and human-in-the-loop features apply to the whole hierarchy, so a multi-agent LangGraph system remains inspectable and resumable end to end.

The trade-off mirrors the single-agent case: Strands gives you ready-made collaboration patterns with less wiring, while LangGraph gives you explicit, checkpointed orchestration you assemble yourself.

Which models and deployment targets does each support?

Neither SDK locks you to one model provider, which is a common misconception about Strands given its AWS origin.

Strands defaults to Amazon Bedrock but supports Anthropic (direct), OpenAI, Mistral, Meta's Llama API, Ollama for local models, LiteLLM as a unified gateway, Writer, Cohere, and custom providers. Swapping models is a one-line change:

LangGraph inherits LangChain's model ecosystem, so it works with 50-plus providers through LangChain's chat model wrappers, including Bedrock via langchain-aws. In practice both cover the same providers.

On deployment, Strands agents run anywhere Python or Node runs and are designed to deploy cleanly onto AWS targets — AgentCore Runtime for managed hosting, AWS Lambda, or Fargate. LangGraph agents likewise run anywhere, with LangGraph Platform (a paid service) offering managed hosting, streaming, and a visual debugger. Importantly, because AgentCore Runtime is framework-agnostic, you can build with either Strands or LangGraph and deploy the result on AgentCore — the deployment layer is not part of this decision.

When should you choose Strands, and when LangGraph?

Choose Strands Agents when:

• You want a working agent in minutes and value minimal, readable code.
• Your workflow is a conversational assistant or a straightforward tool-calling loop.
• You trust the model to plan the sequence of actions and want that to improve as models improve.
• You are on AWS and want a clean path to Bedrock and AgentCore, without being locked out of other providers.
• You prefer built-in OpenTelemetry observability without wiring a separate tracing service.

Choose LangGraph when:

• Your workflow has conditional branches, cycles, parallel steps, or error-recovery paths.
• You need human-in-the-loop approval gates enforced structurally, not just by prompt.
• Reproducibility and auditability matter — you need deterministic, replayable execution.
• Long-running agents must survive crashes and resume from checkpoints.
• You are already invested in the LangChain ecosystem and want tight LangSmith tracing.

A simple heuristic: if you can describe your agent as "read the request and use tools until done," start with Strands. If you can describe it as a flowchart with decision diamonds and approval steps, reach for LangGraph.

Can you use Strands and LangGraph together?

Because Strands and LangGraph occupy the same layer — the agent logic SDK — they are more genuinely alternatives than complements, unlike the AgentCore-versus-framework comparison where one is infrastructure and the other is logic. You would rarely wrap a Strands agent inside a LangGraph node or vice versa in a single service; that mostly adds confusion.

The realistic "both" scenario is at the portfolio level. A team might use Strands for its simple, high-volume agents (support bots, quick tool-callers) where speed of development wins, and reserve LangGraph for the handful of complex, high-stakes workflows (financial approvals, multi-stage pipelines) where control and auditability justify the extra engineering. Both can then deploy onto the same AgentCore Runtime, giving you one operational surface for two development styles. This split — model-driven for the many, graph-driven for the critical few — is a pragmatic pattern that plays to each SDK's strengths.

Frequently Asked Questions

What is the main difference between Strands and LangGraph?

The main difference is who controls the agent loop. Strands is model-driven: you supply tools and a prompt, and the LLM decides which tools to call and in what order, so you write almost no control flow. LangGraph is graph-driven: you define an explicit state machine of nodes and edges, so the control flow is fixed by you and only the decisions inside nodes are left to the model. Strands optimizes for simplicity and speed of development; LangGraph optimizes for determinism, auditability, and complex workflows with branching, cycles, and human approval gates.

Is Strands Agents only for AWS?

No. Strands defaults to Amazon Bedrock and is designed to deploy cleanly on AWS, but it is model-agnostic and provider-agnostic. It supports Anthropic, OpenAI, Mistral, Meta's Llama API, Ollama for local models, LiteLLM, Cohere, Writer, and custom providers, and swapping between them is a one-line change. Strands agents run anywhere Python or TypeScript runs, so you are not required to use AWS infrastructure. The AWS origin means the smoothest path is to Bedrock and AgentCore, but it is not a hard dependency.

Which is better for beginners, Strands or LangGraph?

Strands has the lower barrier to entry. Its model-driven philosophy means a functional tool-calling agent takes under 20 lines: define tools as Python functions with docstrings, create an Agent, and call it. LangGraph requires understanding graph-based programming — typed state objects, nodes, edges, conditional routing, and checkpointing — which adds conceptual overhead before you write your first agent. Beginners building a conversational assistant or a simple tool-calling agent should start with Strands. Move to LangGraph once you understand the agent loop and hit a workflow that genuinely needs explicit branching, approval steps, or replayable state.

Can LangGraph agents deploy on Amazon Bedrock AgentCore?

Yes. AgentCore Runtime is framework-agnostic — it hosts agents built with any Python framework, including LangGraph, Strands, LangChain, or raw code. A common production pattern is to build your orchestration as a LangGraph state machine with checkpointing and human-in-the-loop gates, then wrap that compiled graph in an AgentCore Runtime application for managed auto-scaling, IAM security, and monitoring on AWS. This gives you LangGraph's controllable orchestration with AgentCore's operational simplicity, and it means the choice of Strands versus LangGraph is independent of your deployment platform.