Production AI agents fail when built on simple chains. Uber, LinkedIn, and Klarna learned this the hard way—demo chatbots work until you need retry logic, state persistence, or error recovery. That’s why 60% of production AI projects now default to LangGraph, a framework that models agents as state machines instead of linear chains. If your agent crashes when an API call fails, you’re building on the wrong foundation.
Why Simple Chains Break in Production
Simple chains flow in one direction: analyze request → call API → generate response → done. This works for demos. It fails in production because production environments are hostile—APIs time out, models hallucinate, users send unexpected input. Without loops, your agent can’t retry a failed step. Without state persistence, context vanishes on errors. Without conditional logic, you can’t route around failures.
Consider a customer support bot that queries an external CRM. The CRM returns a 500 error. A simple chain crashes. The user starts over, frustrated. A stateful agent with LangGraph catches the error, retries with exponential backoff, falls back to cached data if retries fail, and logs the incident for investigation—all without losing the conversation context.
After 20+ production deployments, developers learned the pattern: start with simple chains for speed, hit production complexity, rewrite with state machines. Now they skip the rewrite and build on LangGraph from day one.
What LangGraph Adds: State Machines for AI
LangGraph treats agents as state machines, not linear pipelines. Instead of A → B → C, you define nodes (units of work) and edges (transitions). Nodes share a persistent state object that updates over time. This enables loops for retries, conditionals for routing, and checkpoints for recovery.
The architecture is simple: state flows through a graph. Each node receives the current state, performs work (call an LLM, query a database, validate output), and returns updates. LangGraph merges those updates back into state and passes it to the next node. If a node fails, the checkpoint system saves progress. You restart from the last successful step, not from scratch.
Think of it this way: simple chains are one-way streets. State machines are road networks with GPS checkpoints. When you hit traffic, you reroute. When an agent hits an error, it recovers.
Building Your First Stateful Agent (15 Minutes)
Here’s a stateful customer support agent that handles request analysis, data fetching with retry logic, and response generation. This example shows state definition, node functions, graph construction, and conditional routing.
from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.checkpoint.memory import MemorySaver
# Define state schema
class SupportState(MessagesState):
retry_count: int = 0
data_fetched: bool = False
# Node 1: Analyze customer request
def analyze_request(state: SupportState):
# Classify intent: refund, tracking, account issue
return {"messages": [{"role": "ai", "content": "Analyzing request..."}]}
# Node 2: Fetch data from external API (with retry)
def fetch_customer_data(state: SupportState):
try:
# Call external CRM API
data = call_crm_api(state)
return {"data_fetched": True, "messages": [{"role": "system", "content": f"Data: {data}"}]}
except APIError:
if state["retry_count"] < 3:
return {"retry_count": state["retry_count"] + 1}
else:
return {"messages": [{"role": "system", "content": "Using cached data"}]}
# Node 3: Generate response
def generate_response(state: SupportState):
# Use fetched data to craft answer
return {"messages": [{"role": "ai", "content": "Here's your order status..."}]}
# Conditional routing: retry if data fetch failed
def should_retry(state: SupportState):
if state["data_fetched"]:
return "respond"
elif state["retry_count"] < 3:
return "fetch"
else:
return "respond" # Give up, use cached data
# Build the graph
graph = StateGraph(SupportState)
graph.add_node("analyze", analyze_request)
graph.add_node("fetch", fetch_customer_data)
graph.add_node("respond", generate_response)
graph.add_edge(START, "analyze")
graph.add_edge("analyze", "fetch")
graph.add_conditional_edges("fetch", should_retry)
graph.add_edge("respond", END)
# Compile with checkpointing (MemorySaver for dev, PostgreSQL for prod)
app = graph.compile(checkpointer=MemorySaver())
# Run the agent
result = app.invoke({
"messages": [{"role": "user", "content": "Where's my order?"}],
"retry_count": 0,
"data_fetched": False
})The key insight: the should_retry function creates a loop. If the API call fails, the agent routes back to fetch and tries again. Simple chains can’t do this. The checkpoint system means if your process crashes mid-execution, you resume from the last saved state—no data loss, no starting over.
Production Patterns: Persistence and Recovery
Three features make LangGraph production-ready: checkpointing, error recovery, and human-in-the-loop.
Checkpointing saves graph state at every step. In development, use MemorySaver (in-memory storage). In production, use PostgresSaver, Redis, or DynamoDB. When a node completes, LangGraph writes a checkpoint. If your process dies, you load the last checkpoint and resume. No custom database logic required.
Error recovery builds on checkpoints. If a node fails, LangGraph doesn’t re-run successful nodes from earlier in the graph. It restarts only the failed node. This matters at scale—reprocessing expensive LLM calls wastes money and time. Uber’s automated test generation uses this: if one test generation fails, it doesn’t regenerate all previous tests.
Human-in-the-loop pauses execution for approval. Klarna’s support bot handles 85 million users, but high-stakes actions like refunds require human review. LangGraph lets you pause before the refund node, surface the decision to a human operator, and resume after approval. The API is first-class, not bolted on.
The philosophy: errors will happen. Design for graceful recovery, not perfect prevention.
When to Use LangGraph vs LangChain
Use LangChain for rapid prototypes, MVPs, and simple use cases like FAQ bots or summarization. It’s fast, high-level, and gets you shipping quickly. Use LangGraph when you need production-grade features: multi-step workflows with error handling, loops and conditionals, state persistence, or human-in-the-loop. If your agent will run in production, start with LangGraph.
The data supports this. After building 20+ projects, one team reported LangGraph became their default for 60% of development work. Companies deploying at scale—Uber for test generation, LinkedIn for SQL translation, Replit for code generation—chose LangGraph over simpler alternatives because production demands reliability, not just speed.
Migration path: prototype fast with LangChain, graduate to LangGraph when complexity grows. Or skip the rewrite and build on state machines from day one.
Production AI Requires State Machines
The lesson from Uber, LinkedIn, and Klarna is clear: production AI agents need loops, state, and recovery. Simple chains are training wheels. State machines are how you ship to 85 million users without losing data on errors. LangGraph gives you checkpointing, conditional routing, and human-in-the-loop out of the box. Copy the code example above, swap in your use case, and deploy an agent that doesn’t break when reality hits.
