DEV Community

Cover image for LangChain vs Strands: Agent Framework Comparison 2026
ke yi
ke yi

Posted on Originally published at fp8.co

LangChain vs Strands: Agent Framework Comparison 2026

LangChain vs Strands: Which Agent Framework Should You Choose?

TL;DR: LangChain's current create_agent interface and Strands' Agent both support model-driven tool use. Compare their integrations, execution controls, persistence, and operating requirements rather than code length. Strands includes snapshot/checkpoint support for single agents and separate session-management options for Graph/Swarm; it does not require every persistence feature to be built from scratch.

Key Takeaways

  • Use LangChain's current create_agent interface with message-based invocation. Do not present the legacy executor API as the current agent quickstart.
  • Both frameworks can let a model select tools. LangGraph is available when a LangChain application needs more explicit orchestration; it is not mandatory to hand-code a graph for every agent.
  • Current Strands documentation recommends SnapshotSessionManager for new single-agent sessions. Its immutable checkpoints and restore support differ from the repository-based managers used for Graph/Swarm.
  • Separate invocation-scoped configuration from durable state. Strands invocation_state is not a replacement for a session manager.
  • Both have model-provider integrations and open-source libraries. Hosting, model calls, storage, and observability remain separate operating choices and costs.
  • The examples below are fixtures with explicit prerequisites. No model call, latency benchmark, or framework-overhead measurement was performed for this comparison.

What are LangChain and Strands?

LangChain provides a configurable agent harness through create_agent, with tools, prompts, and middleware around the model loop. Its agents build on LangGraph, and applications can use LangGraph directly for more explicit workflow execution. Integration packages provide model, retrieval, and other application components.

Strands Agents is an SDK for model-driven agents with tools, lifecycle controls, state, sessions, and multi-agent patterns. Its repository contains Python and TypeScript packages. Amazon Bedrock is the documented default provider, but alternative providers are supported.

The useful choice is which APIs and operating contracts fit your application. Neither framework's philosophy establishes that it is faster, requires fewer lines, or is suitable only for simple versus complex work.

Official documentation and source were checked September 11, 2026. The LangChain snippets target the current v1 interface. The Strands session example requires a release that exports SnapshotSessionManager; match the installed release to these docs instead of copying an older session API into the new example.

How do they differ architecturally?

LangChain's create_agent constructs an agent without requiring a separate prompt template and executor. The model can choose tools dynamically. For fixed retrieval followed by generation, ordinary application control flow may be sufficient; for branching, interruption, or explicit state transitions, inspect LangGraph's execution and persistence APIs.

Strands also runs a model/tool loop, with hooks and lifecycle controls around it. Applications can use one agent, compose agents as tools, or adopt Graph/Swarm patterns when they need explicit coordination. It should not be characterized as having no workflow or persistence structure.

For either framework, decide who owns tool authorization, side-effect handling, cancellation, execution budgets, and final success checks. A prompt asking an agent to check an order before issuing a refund is not an application-enforced transaction or permission boundary.

How do LangChain and Strands compare at a glance?

Category LangChain Strands Agents
Library license MIT Apache-2.0
Agent entry point create_agent Agent and tools such as @tool functions
Typical invocation agent.invoke({"messages": [...]}) Python agent(question); TypeScript has its own invocation API
Execution Model-driven agent built on LangGraph; explicit graphs also available Model-driven loop with lifecycle controls and composition patterns
Retrieval Compose supported integration packages or application retrieval functions Expose application retrieval through tools or explicit control flow
Durable state Configured thread checkpointer and cross-thread store Single-agent snapshots or repository-based sessions, according to topology
Transient context Use the application's documented runtime/context mechanism invocation_state for one invocation, separate from persistent agent.state
Multi-agent Graph/subgraph and supervisor-style designs Agents-as-tools, Graph, and Swarm designs
Languages Python and JavaScript/TypeScript packages Python and TypeScript packages
Observability LangSmith and supported instrumentation/export integrations OpenTelemetry instrumentation with configured export/backend
Deployment Your compatible host or a managed deployment service Your compatible host, including AgentCore Runtime when its contract fits

The licenses apply to the open-source projects, not to every optional hosted service or dependency. The corresponding primary license files are linked under Sources. There is no LOC, latency, or throughput ranking in this table.

What do equivalent current agent examples look like?

Use the same bounded task before comparing developer experience. These examples look up a status in an in-memory fixture; they do not access a database, issue refunds, or demonstrate production authorization.

Prerequisites: install the relevant SDK and provider integration, configure credentials outside the source, and pass a compatible model supporting tool calls. The functions define invocation paths; calling them uses the supplied model and can incur charges. They were syntax/static-checked, not invoked against a model here.

The current LangChain example follows its documented create_agent and messages interface:

from langchain.agents import create_agent

ORDER_STATUSES = {"4471": "Delivered; refund eligibility needs human review."}

def get_order_status(order_id: str) -> str:
    """Return the status of an order in this local demonstration fixture."""
    return ORDER_STATUSES.get(order_id, "Order not found in the fixture.")

def ask_langchain(model, question: str):
    agent = create_agent(
        model=model,
        tools=[get_order_status],
        system_prompt="Look up order status. Do not claim to issue refunds.",
    )
    return agent.invoke({"messages": [{"role": "user", "content": question}]})
Enter fullscreen mode Exit fullscreen mode

The equivalent Strands example uses its Python Agent and tool decorator:

from strands import Agent, tool

ORDER_STATUSES = {"4471": "Delivered; refund eligibility needs human review."}

@tool
def get_order_status(order_id: str) -> str:
    """Return the status of an order in this local demonstration fixture."""
    return ORDER_STATUSES.get(order_id, "Order not found in the fixture.")

def ask_strands(model, question: str):
    agent = Agent(
        model=model,
        tools=[get_order_status],
        system_prompt="Look up order status. Do not claim to issue refunds.",
    )
    return agent(question)
Enter fullscreen mode Exit fullscreen mode

LangChain returns its agent state, including messages; Strands returns an AgentResult. Inspect each documented result type rather than assuming identical output objects. Neither example guarantees the model will choose a particular sequence of tools.

The LangChain v1 migration guide separates the streamlined current package from langchain-classic functionality. If maintaining an older executor/chain application, use its versioned migration path. Do not use that older application's extra setup to claim current LangChain agents necessarily require more boilerplate.

How do they handle retrieval and RAG workflows?

LangChain's ecosystem includes document-loading, splitting, model, and vector-store integrations. Check the current package for each component; legacy chain/retriever imports are not interchangeable with the v1 agent namespace. Strands can call retrieval code as a tool, and either framework can be used after an application performs deterministic retrieval.

There are two separate choices: how documents are retrieved, and whether the model should decide when to retrieve. A fixed “retrieve, then answer” task does not require a second agent loop. A task that must choose among multiple information sources may benefit from tool-driven retrieval.

What is a complete offline retrieval fixture?

This self-contained Python example uses a small keyword fixture, not a production vector database or semantic-search benchmark. The generation dependency is an explicit callable, so the retrieval/context behavior can be checked offline. There is no undefined qa_chain, database, or external endpoint.

from collections.abc import Callable

DOCUMENTS = (
    {"id": "auth", "term": "authentication",
     "text": "Configure authentication with the approved identity provider."},
    {"id": "refund", "term": "refund",
     "text": "Refund eligibility requires human review before any payment action."},
)

def retrieve_docs(question: str) -> list[dict[str, str]]:
    query = question.casefold()
    return [dict(doc) for doc in DOCUMENTS if doc["term"] in query]

def build_rag_messages(question: str) -> list[dict[str, str]]:
    documents = retrieve_docs(question)
    if not documents:
        return []
    context = "\n".join(f"[{doc['id']}] {doc['text']}" for doc in documents)
    return [
        {"role": "system", "content": "Answer only from the supplied fixture. Cite its IDs."},
        {"role": "user", "content": f"Evidence:\n{context}\n\nQuestion: {question}"},
    ]

def answer_with_retrieval(
    question: str,
    generate: Callable[[list[dict[str, str]]], str],
) -> str:
    messages = build_rag_messages(question)
    if not messages:
        return "No matching evidence in the fixture."
    return generate(messages)
Enter fullscreen mode Exit fullscreen mode

For an offline check, pass a deterministic local function that inspects the messages and returns a fixture answer. For a deployed application, supply an adapter for the chosen model interface and normalize its response to a string. That adapter, credentials, production retrieval, access control, and document freshness are explicit application responsibilities, not hidden prerequisites of the fixture.

A LangChain agent can instead expose retrieval through a tool supplied to create_agent; a Strands agent can expose it through @tool. Preserve document identifiers and evaluate answer support in either approach. Choose integrations that fit the data source instead of claiming that one framework is universally better for RAG.

How do they handle state, memory, and persistence?

LangGraph persistence distinguishes a checkpointer, which records thread-scoped graph state, from a store for data across threads. Configure the appropriate backend and thread identity. An in-memory example is not durable across process restarts, and external side effects still need an idempotency/recovery contract.

Current Strands session documentation describes built-in persistence and recovery. For new single-agent sessions, it recommends SnapshotSessionManager, which saves a latest snapshot and can create immutable checkpoints. Its implementation exposes restore_snapshot() with an optional checkpoint ID.

How does a single-agent Strands snapshot configuration look?

Unexecuted configuration example: use a release exporting these classes, provide a compatible model, and choose an authorized session ID and storage location. Calling this factory can initialize local storage; invoking the returned agent calls the model. Neither action was executed during this article's validation.

from strands import Agent
from strands.session import SnapshotSessionManager
from strands.storage import LocalFileStorage

def build_persistent_agent(model, session_id: str, storage_dir: str):
    session = SnapshotSessionManager(
        session_id=session_id,
        storage=LocalFileStorage(storage_dir),
        snapshot_trigger=lambda *, agent_data, **kwargs: True,
    )
    agent = Agent(model=model, session_manager=session)
    return agent, session
Enter fullscreen mode Exit fullscreen mode

Here the trigger requests an immutable checkpoint after each qualifying invocation. The manager also maintains the latest snapshot. To restore a particular saved checkpoint, the source documents await session.restore_snapshot(agent, snapshot_id=checkpoint_id); supply a real ID from that session's stored snapshots. Retention, tenant isolation, and replay of external effects still require application design.

How do Graph/Swarm sessions differ?

SnapshotSessionManager is single-agent only. Current documentation says to use a repository-based session manager such as FileSessionManager or S3SessionManager on the Graph/Swarm orchestrator. Agents inside that system should not each receive their own session manager. Do not transfer the single-agent snapshot example unchanged into a multi-agent graph.

Strands state documentation also separates persistent application state from invocation_state. Invocation state is initialized for one invocation, shared with its tools/hooks, and excluded from model context; automatic cross-session persistence is a different mechanism. Passing a database connection through invocation state does not make that connection or the conversation durable.

Both frameworks therefore have persistence capabilities. Compare the topology, save boundaries, restore API, and failure behavior required by the workload instead of using “has memory” or “no checkpointing” as a blanket selection rule. See Agent Memory for the broader state boundary.

How do they support multi-agent systems?

LangChain applications can use LangGraph-based composition when they need explicit routing, subgraphs, or a supervisor design. Strands documents agents-as-tools and Graph/Swarm patterns. Choose a topology because it solves a coordination requirement, such as distinct tool permissions or an independent review step.

Define which component owns shared state, cancellation, retries, and termination. Persistence configuration belongs to the intended execution boundary. A resumable conversation or graph does not itself guarantee exactly-once execution of a database write, payment, or message.

For each candidate, test a handoff, a tool failure, an interrupted run, and a restart using the selected session/checkpoint backend. These are proposed acceptance checks, not experiments performed for this article.

Which models and providers does each support?

Both support multiple providers. LangChain's overview documents provider integrations; Strands' repository documents Bedrock as the default and alternatives such as Anthropic and OpenAI. Configure the model explicitly when comparing frameworks so a default-provider difference does not become an accidental comparison variable.

Choose package versions and a provider with the tool-calling, streaming, and structured-output behavior your task requires. Swapping an import or model identifier does not establish equivalent behavior, context limits, or credentials. This guide does not rank ecosystems using unverified provider counts.

How do observability and debugging compare?

LangSmith provides tracing and evaluation workflows for LangChain and other applications. Its OpenTelemetry documentation describes ingestion and attribute mapping, so LangChain should not be presented as locked to a single proprietary tracing path.

Strands includes tracing instrumentation. A useful deployed setup still needs export configuration, an accessible backend, appropriate field mapping, and retention/access decisions. Built-in instrumentation does not mean a trace dashboard appears without configuring a destination.

Compare one representative trace: task, retrieved evidence, model generation, tool outcome, error, and evaluation result. Verify that usage fields and parent/child relationships survive export. For deployment and evaluation trade-offs, see LangSmith vs Langfuse vs Phoenix.

How do deployment and costs compare?

Separate open-source library licensing from service costs. Model API calls, runtime resources, storage, telemetry, and operational work are costs regardless of the agent library. LangSmith pricing describes optional hosted services and usage; it is not a license fee for executing an open-source LangChain agent.

AgentCore Runtime can host applications built with different frameworks, including LangChain and Strands, subject to its deployment contract. Compare Runtime here as a host; the wider AgentCore family also includes managed Harness orchestration. See AgentCore vs LangChain for that distinction.

No fixed monthly price, measured milliseconds of overhead, or throughput winner is established in this article. If performance matters, hold the task, model configuration, tools, environment, and completion criteria fixed; include failed attempts and retries in the results.

When should you choose LangChain, and when Strands?

Requirement Candidate to inspect Evidence that should decide
Existing LangChain integrations and application components LangChain Current packages cover the required models, retrieval, and output handling
Configurable agent with explicit workflow extensions LangChain / LangGraph Required branches, interrupts, and checkpoint recovery behave correctly
In-process model/tool loop with Strands controls Strands Tool handling, budgets, hooks, and provider integration fit the workload
Single-agent snapshot/restore Strands snapshot sessions or LangGraph persistence, as appropriate Selected save/restore semantics satisfy the application's recovery contract
Graph/Swarm state persistence Strands repository-based orchestrator sessions Restart and handoff tests match the chosen topology
A fixed retrieve-then-answer task Either framework or ordinary application code Retrieval and evidence checks pass without unnecessary orchestration

These are shortlist criteria, not a ranking. The framework selection guide places these choices alongside other orchestration approaches.

Can you use LangChain and Strands together?

Applications can use different frameworks for different agents or components when their interfaces and ownership are explicit. Keep a contract for inputs, outputs, errors, cancellation, and durable state rather than trying to share an internal executor or checkpoint object implicitly.

For migration, start with one bounded workflow and retain its evaluation cases. Reuse tool business logic where compatible, but validate the framework wrappers and state/replay behavior separately. Moving into LangChain does not require replacing all model-driven behavior with deterministic chains, and moving into Strands does not require abandoning all checkpoints.

Frequently Asked Questions

What is the main difference between LangChain and Strands?

Both provide model-driven agents. Compare their integration APIs, lifecycle controls, state/session model, and workflow composition against your task. LangChain's current agent API does not require the old separate executor setup, and Strands includes persistence and multi-agent capabilities.

Is Strands only for AWS or Amazon Bedrock?

No. Bedrock is the documented default, but other providers are supported. Configure a supported model and the appropriate credentials, then verify the capabilities your application needs. An AWS origin is not a requirement to host every Strands application on AWS.

Which framework is better for RAG?

Choose the retrieval integrations and control flow that fit the data source and task. Either framework can call retrieval tools or consume application-selected context. The offline fixture above demonstrates a complete retrieval/generation boundary without claiming that its keyword search is production semantic retrieval.

Does Strands support checkpoints and time-travel restore?

Current documentation and source provide single-agent SnapshotSessionManager checkpoints and restore_snapshot(). Graph/Swarm use different repository-based session managers on the orchestrator. Verify the installed release and topology rather than assuming that all session managers provide the same restore behavior.

Can LangChain agents deploy on AgentCore Runtime?

AWS documents framework-independent Runtime hosting, including LangChain and Strands. The application still needs to meet the runtime contract and configure identity, state, tools, and observability correctly.

Which framework has better observability?

Compare a real trace and its required fields in the intended backend. LangSmith provides a managed workflow and OTEL ingestion; Strands supplies instrumentation that needs an export destination. Neither product label establishes that your data was collected correctly.

Which framework is better for beginners?

Try the same small read-only tool task with each current API. Assess whether errors, results, configuration, and persistence are understandable. The source-line count of two differently scoped examples is not a reliable beginner ranking.

How do LangChain and Strands compare on performance and latency?

This guide has no framework-overhead measurement or benchmark result. Measure a common workload and include model calls, tools, retries, persistence, and instrumentation. A different prompt, provider default, or success rate can outweigh the choice of framework.

Can I migrate from one framework to the other?

Yes, but align tool schemas, model capabilities, result types, state ownership, and recovery semantics. Validate a bounded workflow before expanding the migration. Neither interface compatibility nor equal fixture output proves equivalent production behavior.

Sources


Originally published at fp8.co. Subscribe for weekly AI engineering analysis at fp8.co/newsletters.

Top comments (0)