You spent three weeks building a stateful AI agent in LangGraph. It worked perfectly in your Jupyter notebook. You deployed it. Within 48 hours, your Slack is blowing up with error reports, your costs are 4x what you projected, and one user somehow got stuck in a loop that ran 847 tool calls before you killed the process manually.
Welcome to production.
LangGraph is genuinely one of the most powerful frameworks for building stateful AI agents in 2026. The graph-based architecture, native checkpointing, and first-class support for multi-agent workflows make it the right tool for serious production deployments. But "powerful" and "production-ready out of the box" are not the same thing. The gap between a working prototype and a reliable production agent is where most developers lose weeks of their lives.
This post covers the five failure modes I see most often — state corruption, infinite loops, memory blowout, tool call errors, and checkpointer failures — with real code, real fixes, and the specific tools that will save you when things go sideways.
---
Why LangGraph Production Failures Are Different From Regular Bugs
Standard application bugs are usually deterministic. Same input, same error, same stack trace. You fix it, you move on.
LangGraph failures are different because they emerge from the interaction between your graph structure, the LLM's non-deterministic outputs, external tool responses, and persistent state that accumulates across many turns. A bug that never appeared in 200 test runs can surface on run 201 because the LLM happened to format a tool call slightly differently, which corrupted a state field, which caused the next node to behave unexpectedly.
This is why observability isn't optional. Before you fix anything, you need to see what's actually happening inside your graph. LangSmith is the obvious first choice — it integrates natively with LangGraph and gives you full trace visibility across every node execution. Langfuse is the open-source alternative that many teams prefer for cost control and self-hosting. Both will show you the exact sequence of node executions, state snapshots at each step, and LLM inputs/outputs.
Set one of these up before you read the rest of this post. Seriously. Debugging LangGraph without traces is like debugging a distributed system by reading log files from a single server.
---
Failure Mode 1: State Corruption
State corruption is the sneakiest LangGraph failure because it often doesn't throw an error immediately. Instead, your agent starts producing subtly wrong outputs that are hard to trace back to a root cause.
The most common source is type mismatches in your state schema. LangGraph uses TypedDict for state by default, but Python's type hints are not enforced at runtime. If one node writes a string to a field that another node expects to be a list, you won't get a TypeError — you'll get bizarre behavior three nodes later.
```python
class AgentState(TypedDict):
messages: list[BaseMessage]
tool_results: list[dict]
current_step: str
def process_node(state: AgentState) -> AgentState:
# Bug: returns a single dict instead of a list
return {"tool_results": {"result": "some data"}} # This will corrupt downstream nodes
```
The fix: Use Pydantic models for your state schema instead of TypedDict. Pydantic validates types on assignment, so corruption gets caught at the source.
```python
from pydantic import BaseModel, validator
from typing import List, Dict, Any
class AgentState(BaseModel):
messages: List[dict] = []
tool_results: List[Dict[str, Any]] = []
current_step: str = "start"
class Config:
validate_assignment = True # Validates on every field update
```
The second common source of state corruption is concurrent node execution in parallel graph branches writing to the same state fields. If you're using LangGraph's parallel execution features, treat shared state fields as append-only and use reducers explicitly.
```python
from langgraph.graph import StateGraph
import operator
class AgentState(TypedDict):
messages: Annotated[list, operator.add] # Safe for parallel writes
errors: Annotated[list, operator.add] # Accumulates from all branches
```
---
Failure Mode 2: Infinite Loops
The 847-tool-call incident I mentioned at the top? Infinite loop. This is the failure mode that will cost you real money and potentially take down your service.
LangGraph graphs can loop by design — that's part of what makes them powerful for agentic workflows. But without proper termination conditions, a confused LLM or a malformed tool response can send your agent spinning forever.
The most common pattern: your agent calls a tool, the tool returns an error or unexpected format, the LLM decides to retry, the retry produces the same error, repeat indefinitely.
Fix 1: Hard iteration limits
```python
class AgentState(TypedDict):
messages: list
iteration_count: int
max_iterations: int
def should_continue(state: AgentState) -> str:
if state["iteration_count"] >= state["max_iterations"]:
return "force_end"
if state.get("task_complete"):
return "end"
return "continue"
graph.add_conditional_edges(
"agent_node",
should_continue,
{
"continue": "tool_node",
"end": END,
"force_end": "error_handler" # Don't just end — log the forced termination
}
)
```
Fix 2: Tool call deduplication
If your agent is calling the same tool with the same arguments repeatedly, that's almost always a bug. Track recent tool calls in state and short-circuit duplicates.
```python
def check_duplicate_tool_call(state: AgentState, tool_name: str, tool_args: dict) -> bool:
recent_calls = state.get("recent_tool_calls", [])[-10:] # Last 10 calls
call_signature = f"{tool_name}:{json.dumps(tool_args, sort_keys=True)}"
return call_signature in recent_calls
```
Fix 3: LangSmith alerts
Set up LangSmith run alerts for traces that exceed a token threshold or duration threshold. This catches runaway agents before they exhaust your budget. Langfuse has equivalent alerting functionality if you're on the open-source path.
If you want a comprehensive framework for monitoring agent behavior in production — including loop detection, cost controls, and escalation policies — The GUARDIAN Framework covers exactly this problem space in depth.
---
Failure Mode 3: Memory Blowout
LangGraph's in-memory state management is fine for short sessions. It becomes a serious problem when you have long-running agents, many concurrent users, or conversations that accumulate hundreds of messages.
The symptom: your agent starts slow, gets slower, eventually crashes with OOM errors or hits LLM context limits and starts hallucinating because it's trying to process 50,000 tokens of conversation history.
The core problem: Most developers pass the entire message history to the LLM on every node execution. This is fine for 10 messages. It's catastrophic for 500.
Fix 1: Message windowing
```python
def trim_messages_for_llm(messages: list, max_messages: int = 20) -> list:
"""Keep system message + last N messages"""
if len(messages) <= max_messages:
return messages
system_messages = [m for m in messages if m.get("role") == "system"]
recent_messages = messages[-max_messages:]
# Ensure we don't duplicate system messages
non_system_recent = [m for m in recent_messages if m.get("role") != "system"]
return system_messages + non_system_recent
def agent_node(state: AgentState) -> AgentState:
trimmed = trim_messages_for_llm(state["messages"])
response = llm.invoke(trimmed) # Use trimmed, store full
return {"messages": state["messages"] + [response]}
```
Fix 2: Summarization nodes
For long-running agents, add a periodic summarization step that compresses old conversation history into a summary message.
```python
def should_summarize(state: AgentState) -> bool:
return len(state["messages"]) > 50 and state["iteration_count"] % 10 == 0
def summarize_history(state: AgentState) -> AgentState:
old_messages = state["messages"][:-20] # Everything except last 20
summary_prompt = f"Summarize this conversation history concisely: {old_messages}"
summary = llm.invoke(summary_prompt)
summary_message = {"role": "system", "content": f"[Previous context summary]: {summary.content}"}
return {"messages": [summary_message] + state["messages"][-20:]}
```
Fix 3: External state storage
For production multi-user deployments, don't store state in memory at all. Use a proper checkpointer backed by a database. Which brings us to failure mode 4.
Before you scale, it's worth running your architecture through the LangGraph Agent Architecture Planner to identify memory and state management issues before they hit production.
---
Failure Mode 4: Tool Call Errors
Tool calls are the primary interface between your LangGraph agent and the real world. They're also the primary source of runtime failures. APIs go down. Responses come back in unexpected formats. The LLM generates malformed arguments. Rate limits get hit.
The naive approach is to let tool errors propagate as exceptions and hope your graph's error handling catches them. This works until it doesn't.
Fix 1: Structured tool error handling
Every tool in your graph should return a structured result that includes success/failure status, not just raise exceptions.
```python
from typing import Union
from pydantic import BaseModel
class ToolResult(BaseModel):
success: bool
data: Any = None
error: str = None
retry_allowed: bool = True
def safe_tool_wrapper(tool_fn):
def wrapper(args, *kwargs) -> ToolResult:
try:
result = tool_fn(args, *kwargs)
return ToolResult(success=True, data=result)
except RateLimitError as e:
return ToolResult(success=False, error=f"Rate limit: {e}", retry_allowed=True)
except ValidationError as e:
return ToolResult(success=False, error=f"Invalid args: {e}", retry_allowed=False)
except Exception as e:
return ToolResult(success=False, error=str(e), retry_allowed=False)
return wrapper
```
Fix 2: Retry logic with exponential backoff
For transient failures (rate limits, network timeouts), implement proper retry logic at the tool level, not the graph level.
```python
import time
from functools import wraps
def with_retry(max_retries=3, base_delay=1.0):
def decorator(func):
@wraps(func)
def wrapper(args, *kwargs):
for attempt in range(max_retries):
result = func(args, *kwargs)
if result.success or not result.retry_allowed:
return result
if attempt < max_retries - 1:
delay = base_delay (2 * attempt)
time.sleep(delay)
return result
return wrapper
return decorator
```
Fix 3: LLM argument validation before execution
The LLM will sometimes generate tool arguments that look valid but fail schema validation. Validate arguments before calling the tool and return a helpful error message to the LLM if validation fails — this gives it a chance to self-correct rather than crashing.
```python
def validate_and_call_tool(tool_schema: dict, tool_fn: callable, llm_args: dict) -> ToolResult:
try:
validated_args = tool_schema(**llm_args)
return tool_fn(**validated_args.dict())
except ValidationError as e:
# Return structured error for LLM to self-correct
return ToolResult(
success=False,
error=f"Tool argument validation failed: {e}. Please check the tool schema and retry.",
retry_allowed=True
)
```
---
Failure Mode 5: Checkpointer Failures
LangGraph's checkpointing system is what enables persistent state across sessions, human-in-the-loop workflows, and fault tolerance. When it breaks, you lose state, conversations reset unexpectedly, and users lose their context mid-task.
The default in-memory checkpointer is fine for development. In production, you need a persistent backend.
The SQLite checkpointer is a step up but still not production-grade for multi-instance deployments. It has file locking issues under concurrent load and doesn't work across multiple server instances.
The Supabase checkpointer (via `langgraph-checkpoint-postgres`) is what I recommend for most production deployments. PostgreSQL handles concurrent writes correctly, Supabase gives you a managed instance with built-in monitoring, and the connection pooling handles high-concurrency scenarios.
```python
from langgraph.checkpoint.postgres import PostgresSaver
import psycopg
DB_URI = "postgresql://user:password@host:5432/langgraph_db"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
checkpointer.setup() # Creates required tables
graph = StateGraph(AgentState)
# ... add nodes and edges ...
compiled_graph = graph.compile(checkpointer=checkpointer)
```
Common checkpointer failure: Thread ID collisions
If you're not generating unique thread IDs per user session, different users will read each other's state. This is a security issue, not just a bug.
```python
import uuid
def create_session_config(user_id: str) -> dict:
"""Generate a unique, deterministic thread ID per user session"""
session_id = str(uuid.uuid4())
return {
"configurable": {
"thread_id": f"{user_id}_{session_id}",
"user_id": user_id # Store for audit logging
}
}
```
Common checkpointer failure: Schema migrations
When you update your state schema, existing checkpointed states won't match the new schema. Plan for this from day one with versioned state schemas and migration utilities.
```python
class AgentStateV2(TypedDict):
messages: list
tool_results: list
current_step: str
schema_version: int # Add this field to every state schema
def migrate_state_v1_to_v2(old_state: dict) -> dict:
"""Migration function for schema updates"""
if old_state.get("schema_version", 1) == 1:
old_state["schema_version"] = 2
old_state.setdefault("tool_results", [])
return old_state
```
---
Building a Production-Ready LangGraph Agent: The Full Picture
Fixing these five failure modes individually will dramatically improve your agent's reliability. But production-grade agents require more than patching failure modes — they require intentional architecture from the start.
If you're building your first serious LangGraph agent, Build Your First AI Agent in 24 Hours walks through the full implementation with production considerations baked in from the beginning, not bolted on afterward.
If you're building agents for clients or as a business, the economics matter as much as the architecture. Use the AI Agent Cost Calculator to model your actual per-run costs before you price your service, and the AI Agent Performance Calculator to benchmark whether your agent