LangGraph vs LangChain vs CrewAI: When to Use Each

Key Takeaways

• The short answer in 2026: LangChain for linear pipelines and quick prototypes, LangGraph for production stateful agents (our default), CrewAI for role-based multi-agent demos that ship to internal teams.
• LangGraph is the production default at Bitontree for any agentic workflow with branching, state persistence, or human-in-the-loop requirements - it is the only framework with first-class checkpointing and graph-based control flow.
• Our sales workflow automation runs on LangGraph plus LangChain primitives, with CrewAI evaluated and rejected because the role abstraction was the wrong model for the conditional routing the workflow required. Net result: 60% faster lead response time.
• The frameworks are not exclusive. Most production systems use LangChain components (retrievers, tools, models) inside a LangGraph orchestration. CrewAI rarely makes sense in the same stack.

The langgraph vs langchain question is asked badly. They are not competitors; LangGraph is built by the LangChain team and uses LangChain primitives internally. The real comparison is between architectural shapes - linear pipelines (LangChain Expression Language), stateful graphs (LangGraph), and role-based crews (CrewAI). We have shipped production systems on all three and abandoned all three for different reasons. This guide is the honest framework selection logic we use at Bitontree, with code in each framework solving the same problem and an explicit recommendation for when each fits.

LangGraph vs LangChain vs CrewAI: The Short Answer

LangChain is for composing LLM components into pipelines. LangGraph is for orchestrating stateful, branching agent workflows. CrewAI is for role-based multi-agent collaboration where agents have personas and delegate to each other. The frameworks solve different problems; calling them alternatives is a common mistake that wastes weeks of engineering time.

The decision logic, compressed:

Question	Recommendation
Linear pipeline (prompt → retrieve → generate)	LangChain or just the OpenAI / Anthropic SDK
Branching workflow with state and retries	LangGraph
Need human-in-the-loop checkpoints	LangGraph
Multiple agents with distinct roles collaborating	CrewAI (or LangGraph multi-agent)
Complex production system, long-running	LangGraph
Quick prototype, exploring an idea	LangChain LCEL or CrewAI for demos
Highly performant, low-latency serving	None - write it in plain Python

The Bitontree default in 2026 is LangGraph for the orchestrator, with LangChain primitives (retrievers, tool decorators, model wrappers, output parsers) used inside the graph nodes. CrewAI shows up rarely - usually in internal demos or research projects where the role metaphor matches the use case. We have built one production CrewAI system and migrated it to LangGraph within six months because the role abstraction did not survive a real workload.

The rest of this guide explains why those defaults exist and where they break.

What Each Framework Actually Is

The three frameworks have different scopes, different abstractions, and different opinions about what an agent is. Understanding the actual architecture matters more than the marketing - every framework's docs make it sound like the right choice for any use case.

LangChain is a component library plus a composition language. The components are retrievers, vector stores, model wrappers, output parsers, document loaders, and tool decorators. The composition language is LCEL (LangChain Expression Language) - chains expressed with the | operator. LangChain is closest to a Unix-style toolkit; you assemble pieces into pipelines.

LangGraph is a graph-based runtime for agent workflows. Built on top of LangChain primitives by the same team. The graph is a state machine - nodes are functions that read and update a typed state object, edges define control flow (conditional, fixed, or loop). LangGraph adds checkpointing, human-in-the-loop interrupts, streaming, and time-travel debugging.

CrewAI is a multi-agent framework built around the metaphor of a "crew" - a team of agents with roles (researcher, writer, analyst) that collaborate on tasks. CrewAI handles role definition, task assignment, agent-to-agent communication, and sequential or hierarchical execution. The abstraction is intuitive for non-engineers writing agent workflows.

The architectural differences:

Dimension	LangChain	LangGraph	CrewAI
Primary abstraction	Chain (pipeline)	Graph (state machine)	Crew (roles + tasks)
State management	Per-chain context	Typed persistent state	Crew memory
Control flow	Linear, with branches via LCEL	Explicit edges, conditional routing	Sequential or hierarchical process
Checkpointing	None native	First-class (Postgres, Redis, SQLite)	Limited
Human-in-the-loop	None	interrupt_before / interrupt_after	Manual via tasks
Multi-agent	Possible but awkward	Native subgraphs	Native, primary use case
Production tracing	LangSmith	LangSmith	Limited; bring your own

LangChain: The Component Toolkit

LangChain is the right choice when the workflow is mostly linear - load data, transform it, send to a model, parse the output. LCEL pipelines compose cleanly, the primitives are well-documented, and the ecosystem of integrations (retrievers, vector stores, document loaders) is the largest in the space. We use LangChain components in every production project even when the orchestrator is LangGraph.The official LangChain LCEL documentation specifies this composition language and its operator semantics.

A typical LangChain RAG pipeline (with Qdrant as the vector store and OpenAI embeddings):

from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_qdrant import Qdrant
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = Qdrant.from_existing_collection(
    embedding=embeddings,
    collection_name="docs",
    url=QDRANT_URL,
)
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

prompt = ChatPromptTemplate.from_template(
    "Answer the question using only this context:\n{context}\n\nQuestion: {question}"
)
model = ChatOpenAI(model="gpt-4o")

chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt
    | model
    | StrOutputParser()
)

answer = chain.invoke("What is our refund policy?")

This is clean and readable for pipelines. The honest limitations:

• State is implicit. Once the chain runs, the intermediate state is gone. Debugging means re-running with extra logging.
• Branching is awkward. LCEL supports RunnableBranch, but conditional routing with more than two paths becomes nested and hard to follow.
• No native checkpointing. A crashed chain restarts from the top. Fine for cheap chains, painful for expensive ones.
• LCEL is its own DSL. New engineers spend a week learning the operators before they can read existing chains.

LangChain shines for retrieval pipelines, content transformation, and any workflow that is genuinely sequential. We ship LangChain code in production every week - but the LangChain code lives inside LangGraph nodes, not as the top-level orchestrator. The framework is a toolkit, not a runtime for stateful agents.

LangGraph: Stateful Graphs for Production Agents

LangGraph is the production default for any agent workflow with branching, state persistence, or human-in-the-loop checkpoints. The graph abstraction matches how agentic workflows actually behave - a state object passes between nodes, edges define what happens next based on state content, and checkpointing makes the whole thing resumable. Every production agent we have shipped at Bitontree in the past 12 months runs on LangGraph.See our AI agent development services for the production patterns we use across these systems.

The mental model is straightforward - define a Pydantic state class, write nodes as functions that take and return state, declare edges (fixed or conditional), and compile the graph. The runtime handles state propagation, checkpointing, retries, and streaming.

A LangGraph version of a sales lead routing agent, the actual pattern in our sales workflow automation system:

from langgraph.graph import StateGraph, END
from langgraph.checkpoint.postgres import PostgresSaver
from pydantic import BaseModel
from typing import Literal

class LeadState(BaseModel):
    lead_id: str
    email_content: str
    classification: Literal["enterprise", "smb", "irrelevant", "unknown"] = "unknown"
    enriched: dict = {}
    routing: Literal["sales_team", "automation", "discard", "pending"] = "pending"

def classify(state: LeadState) -> LeadState:
    result = classifier_chain.invoke({"email": state.email_content})
    return state.model_copy(update={"classification": result})

def enrich(state: LeadState) -> LeadState:
    company_data = clearbit.lookup(state.email_content)
    return state.model_copy(update={"enriched": company_data})

def route(state: LeadState) -> str:
    if state.classification == "irrelevant":
        return "discard_lead"
    if state.classification == "enterprise":
        return "alert_sales_team"
    if state.classification == "smb" and state.enriched.get("employees", 0) > 50:
        return "alert_sales_team"
    return "automated_response"

graph = StateGraph(LeadState)
graph.add_node("classify", classify)
graph.add_node("enrich", enrich)
graph.add_node("alert_sales_team", alert_sales)
graph.add_node("automated_response", automated_response)
graph.add_node("discard_lead", discard)

graph.set_entry_point("classify")
graph.add_edge("classify", "enrich")
graph.add_conditional_edges("enrich", route)
graph.add_edge("alert_sales_team", END)
graph.add_edge("automated_response", END)
graph.add_edge("discard_lead", END)

checkpointer = PostgresSaver.from_conn_string(POSTGRES_URL)
app = graph.compile(checkpointer=checkpointer)

What you get for that complexity:

• Persistent state - every node transition writes a checkpoint. A crash resumes from the last good state.
• Conditional routing - the route function dispatches based on state content; no nested branches in the chain.
• Human-in-the-loop - adding interrupt_before=["alert_sales_team"] pauses the graph and waits for an approval signal.
• Replay and time-travel - LangSmith lets you re-run from any checkpoint with modified state.
• Streaming - clients see state updates as they happen, not just the final result.

The trade-off is verbosity. A LangChain LCEL chain that fits in 10 lines becomes 40 lines in LangGraph. For workflows that genuinely are linear, the overhead is not justified. For workflows with branching or state, LangGraph is the only framework in this list that handles the production concerns natively.

The sales workflow described above runs this pattern in production and cut lead response time by 60% compared to the previous email-queue-and-spreadsheet workflow.

CrewAI: Role-Based Multi-Agent Collaboration

CrewAI organizes agents into crews, teams of role-specialized agents that collaborate on a task. The framework is fastest to demo for multi-agent workflows where the role metaphor fits naturally (research, writing, code review). It has the easiest learning curve for non-engineers and the slickest "wow, watch the agents talk to each other" demos. The honest assessment from running it in production: the role abstraction is the wrong model for most real workflows. The official CrewAI documentation defines the framework's crew, agent, task, and process abstractions in detail.

A CrewAI implementation of a research assistant:

from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool

researcher = Agent(
    role="Senior Research Analyst",
    goal="Find and summarize the latest information on a topic",
    backstory="You are an experienced research analyst with deep expertise.",
    tools=[SerperDevTool()],
    verbose=True,
)

writer = Agent(
    role="Tech Content Writer",
    goal="Write clear, accurate, engaging content from research findings",
    backstory="You are a skilled writer who turns dense research into clear prose.",
    verbose=True,
)

research_task = Task(
    description="Research the latest developments on {topic}",
    expected_output="A detailed research summary with sources",
    agent=researcher,
)

writing_task = Task(
    description="Write a 500-word brief from the research",
    expected_output="A polished 500-word brief",
    agent=writer,
    context=[research_task],
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential,
)

result = crew.kickoff(inputs={"topic": "MCP protocol adoption in 2026"})

The framework works. The agents do their tasks. The output is reasonable. What you cannot do well:

• Conditional routing - CrewAI's sequential and hierarchical processes do not natively model "if the researcher found nothing, escalate" without custom code that fights the framework.
• Strict typed state - agent outputs are free-form strings parsed implicitly; getting structured data across tasks requires careful prompt engineering.
• Production observability - limited tracing compared to LangSmith. Most teams bolt on their own.
• Performance agent-to-agent communication is verbose; what could be three model calls in LangGraph becomes 8-12 calls in CrewAI because each role-play exchange adds tokens.

CrewAI's role metaphor is compelling for demos but lossy for production. The "Senior Research Analyst" backstory is overhead the model spends tokens on every turn. In a workflow with strict outputs and clear branching, those tokens buy nothing. We use CrewAI for internal experiments and for client demos where stakeholders need to see "the agents working together." We do not ship it as a top-level orchestrator for customer-facing systems.The gap between demoable AI and production-grade AI is documented at scale: McKinsey's State of AI research consistently finds that production deployment, not model selection, is where most AI initiatives stall.

Code Comparison: The Same Lead-Routing Workflow

A direct comparison clarifies the differences in shape - same workflow, three frameworks, very different line counts and branching behavior. The workflow: classify an incoming sales email, enrich with company data, and route to a human, an automated response, or trash. Below is the same problem solved in LangChain, LangGraph, and CrewAI so the structural costs of each framework are visible side by side.

LangChain (LCEL) version - works for the happy path; branching gets ugly fast:

from langchain_core.runnables import RunnableBranch

classify_chain = classify_prompt | model | classification_parser
enrich_chain = enrich_prompt | model | enrich_parser

pipeline = (
    {"classification": classify_chain, "email": RunnablePassthrough()}
    | RunnablePassthrough.assign(enriched=enrich_chain)
    | RunnableBranch(
        (lambda x: x["classification"] == "irrelevant", discard_chain),
        (lambda x: x["classification"] == "enterprise", alert_chain),
        (lambda x: x["enriched"]["employees"] > 50, alert_chain),
        automated_response_chain,
    )
)

This compiles. It runs. Debugging a failure in enrich_chain while preserving the classification result is painful. There is no checkpoint. There is no "the agent decided to retry with refined inputs." It is a pipeline pretending to be an agent.

LangGraph version - the code shown in the earlier section; 40 lines, explicit state, conditional edges, checkpointed, and naturally extends to human-in-the-loop and retries.

CrewAI version - the role metaphor strains:

classifier = Agent(role="Lead Classifier", goal="Classify incoming leads", ...)
enricher = Agent(role="Lead Enricher", goal="Enrich with company data", ...)
router = Agent(role="Lead Router", goal="Route lead to right path", ...)

tasks = [
    Task(description="Classify lead {email}", agent=classifier, ...),
    Task(description="Enrich the lead", agent=enricher, ...),
    Task(description="Route based on classification and enrichment", agent=router, ...),
]
crew = Crew(agents=[...], tasks=tasks, process=Process.sequential)

This runs. It costs 3-4x the tokens of the LangGraph version because each agent role-plays through its task. It cannot easily express "if classification is irrelevant, skip enrichment" - the sequential process runs every task. Hierarchical process can express this but adds a manager agent that costs more tokens still.

The same workflow, three frameworks, very different operational profiles. The Bitontree pick is LangGraph for any version of this that ships to production.

When to Use LangChain (Honest Recommendation)

Use LangChain when the workflow is genuinely linear and you want the ecosystem of integrations. RAG pipelines, document processing chains, content transformation flows - these are LangChain's strength. The LCEL composition is clean, the retrievers and vector store integrations cover 30+ vendors, and LangSmith gives you tracing for free.

Specifically, reach for LangChain in these scenarios:

• RAG retrieval and generation - the LangChain retriever interface is the cleanest abstraction we have used, and it works with every major vector DB
• Document ingestion - the document loaders for PDF, docx, HTML, Notion, Confluence, and SharePoint are production-quality and well-maintained
• Output parsing - PydanticOutputParser and StructuredOutputParser plus Instructor are the cleanest path to typed LLM outputs
• Quick prototypes - LCEL lets you compose a working pipeline in 20 lines

When NOT to use LangChain as the top-level orchestrator: any workflow with branching, retries, human-in-the-loop, or state that must survive a crash. Use it for components, use LangGraph for orchestration.

When to Use LangGraph (Our Production Default)

Use LangGraph when the workflow has branching, state, or any production concern (checkpointing, observability, retries, human-in-the-loop). This is most production agent systems. The verbosity cost over LangChain is real but pays back the first time you need to debug a stuck workflow at 2am.

Specifically, LangGraph is the right pick when:

• The workflow has more than two conditional branches - LCEL's RunnableBranch gets unreadable beyond two levels; LangGraph's add_conditional_edges stays clean
• State must survive a crash - checkpointing to Postgres or Redis is one line of config
• A human must approve specific steps - interrupt_before and interrupt_after make this trivial
• The agent might loop - bounded loops with explicit step counters are native to the graph runtime
• You need to replay state - LangSmith time-travel debugging works on LangGraph traces

The medication calling system, the sales workflow, and the Singapore invoice processing system all run on LangGraph. Every production agent we ship in 2026 starts here.

When to Use CrewAI (And Why We Mostly Don't)

Use CrewAI for two specific cases - internal demos that showcase multi-agent collaboration, and workflows where the role metaphor matches the actual structure (a research team, a writing team, a code review team). For anything else, the abstraction costs more than it returns.

The honest cases where CrewAI wins:

• Internal research and writing workflows - content production with researcher, writer, editor roles maps cleanly
• Stakeholder demos - when the audience needs to see "agents collaborating," the verbose dialogue is a feature
• Non-engineer-authored agents - the role/goal/backstory abstraction is approachable for product or operations folks

Where we have seen CrewAI hit walls in production:

• Conditional logic in workflows - sequential and hierarchical processes do not handle "skip step 3 if step 2 returned X" cleanly
• Strict typed outputs - the framework leans on free-form text between agents; structured outputs require fighting it
• Token cost - agent dialogue adds 2-4x tokens compared to a tight LangGraph
• Observability - bring your own; LangSmith integration is limited

The one production CrewAI system we shipped was a content research agent for an internal Bitontree workflow. We migrated it to LangGraph within six months because the routing requirements grew past what the sequential process could express. The migration paid back in a month of reduced token spend.

Migration Paths Between the Three

The migration paths between these three frameworks are asymmetric - LangChain → LangGraph is a clean upgrade, LangGraph → LangChain is a downgrade rarely worth doing, and CrewAI → LangGraph is a genuine rewrite because the role abstraction does not translate to typed graph state. We have done each migration on production code at least twice. Plan the direction and the engineering cost before you start.

LangChain → LangGraph - each LCEL chain becomes a node in the graph. Wrap the chain in a function that takes state in and returns state out, register it as a node, define edges between nodes. Most of the LangChain components (retrievers, parsers, models) keep working unchanged. Migration time for a moderate pipeline (5-10 chains): 2-4 days.

LangGraph → LangChain - only worth doing if the workflow turned out to be linear and the state machine was overkill. Rare in our experience. Migration is replacing the graph with an LCEL pipeline; usually a half-day of work if the original graph was simple.

CrewAI → LangGraph - each agent role becomes a node, each task becomes an edge or sub-graph, and the role metaphor gets translated into explicit state. The hard part is replacing implicit agent-to-agent communication with explicit state propagation. Migration time for a moderate crew (3-5 agents, 5-10 tasks): 1-2 weeks.

The migration that almost never makes sense - moving production code to CrewAI from LangGraph. The role abstraction is fundamentally a step backward for systems that need explicit control flow.

Where to Start With Framework Selection

The framework decision rarely makes or breaks a production system - the architecture does. Most teams obsess over framework choice and underinvest in observability, evaluation, and graceful degradation. Pick LangGraph for production agents, use LangChain components inside, and skip CrewAI unless the role metaphor genuinely fits your workflow. If you are choosing between langgraph vs langchain (or CrewAI) for a specific production system and want a second opinion on the architecture, Book a Free AI Fit Assessment and we will tell you which framework fits the workflow shape you have, and where the framework choice is a rounding error compared to the real architectural decisions. You can also see the broader work we do across agents, RAG, and MCP integrations on the Bitontree homepage.