LangGraph

Why LangGraph Exists:

LangChain agents are great for simple tool-calling. But real production agents need persistent state, conditional branching, loops with exit conditions, human approval steps, and error recovery. LangGraph models agent workflows as state machines represented as directed graphs.

LangGraph is built by the LangChain team but is a separate package. Think of it as "LangChain for complex agents" - where LangChain chains are linear, LangGraph allows cycles, branches, and state persistence.

Real-World Analogy - IRCTC Booking:

Think of booking a train ticket on IRCTC as a LangGraph workflow:

• State: Your booking details (name, train, class, payment status) persisted throughout
• Nodes: Search trains, select seat, fill passenger details, payment gateway
• Conditional Edges: If payment fails -> retry or cancel. If waitlisted -> check alternatives.
• Human-in-the-Loop: "Confirm booking?" - pauses for user approval before payment
• Loops: Payment retry loop (max 3 attempts)

A simple LangChain chain cannot model this. LangGraph can.

Core Concepts:

What is State?

State in LangGraph is a typed dictionary (defined as a TypedDict or Pydantic model) that flows through the graph. Every node can read from and write to this state. Unlike LangChain where data flows linearly through a chain, LangGraph state is shared and persistent.

State Reducers:

When multiple nodes write to the same state key, LangGraph uses reducers to combine values. The most common reducer is add for message lists - instead of overwriting, new messages are appended.

Example: messages field uses add_messages reducer. Node A adds message 1. Node B adds message 2. Final state has both messages - no data lost.

Checkpointing - Persistent State:

LangGraph can save state at every step using checkpointers. This enables:

• Time Travel: Go back to any previous state and re-run from there
• Human-in-the-Loop: Pause execution, wait for human input, resume
• Crash Recovery: If the process crashes, resume from the last checkpoint
• Conversation Persistence: Save conversations across sessions using thread_id

Checkpointer backends: MemorySaver (dev), SqliteSaver, PostgresSaver (production).

State Best Practices:

• Keep state minimal - only store what nodes actually need
• Use Pydantic models for type validation
• Always use reducers for list fields (especially messages)
• Use PostgresSaver in production for durability

Nodes - The Processing Units:

A node is simply a Python function that takes state as input and returns state updates. Nodes can do anything: call an LLM, execute a tool, validate data, query a database, or even pause for human input.

Edge Types:

• Normal Edge: Always goes from Node A to Node B. Like a straight road.
• Conditional Edge: Routes to different nodes based on current state. Like a traffic signal - green goes forward, red goes to waiting. A function inspects the state and returns the next node name.
• Entry Edge: Defines which node starts the graph (START -> first_node).
• End Edge: Defines which node ends the graph (last_node -> END).

Common Graph Patterns:

• ReAct Agent: LLM node -> conditional (tool_needed?) -> Tool node -> back to LLM node (loop)
• Supervisor: Supervisor node decides which worker node to call next. Workers report back to supervisor.
• Plan-and-Execute: Planner node creates plan -> Executor node runs each step -> Replanner checks if done
• Human-in-the-Loop: Agent node -> interrupt_before tool_node -> wait for human approval -> tool_node

Graph Construction Steps:

1. Define your State (TypedDict with annotations)
2. Create a StateGraph with that state type
3. Add nodes (add_node)
4. Add edges and conditional edges (add_edge, add_conditional_edges)
5. Set entry point (set_entry_point)
6. Compile the graph (graph.compile())
7. Run with graph.invoke(initial_state)

Why Human-in-the-Loop?

Production agents often need human approval before taking high-stakes actions - sending emails, making purchases, modifying databases. LangGraph provides interrupt_before and interrupt_after to pause execution at specific nodes and wait for human input.

How Interrupts Work:

1. Graph executes until it reaches a node marked with interrupt_before
2. State is saved to the checkpointer (everything persisted)
3. Execution pauses and returns to the caller
4. Human reviews the planned action and approves/rejects/modifies
5. Graph resumes from the interrupted point with (optionally modified) state

Real-World Examples:

• Email Agent: Drafts email -> interrupt -> Human reviews/edits -> Sends
• Trading Bot: Analyzes market -> Suggests trade -> interrupt -> Human approves -> Executes trade
• Customer Support: Suggests refund -> interrupt -> Manager approves -> Processes refund
• Code Agent: Generates code -> interrupt -> Developer reviews -> Commits to repo

Time Travel Debugging:

Because LangGraph checkpoints every state, you can "time travel" to any previous step, modify the state, and re-run from there. This is incredibly powerful for debugging agent behavior - you can see exactly what the agent was thinking at each step and change its course.

When to Use LangGraph:

• Complex agent workflows with loops, branches, and conditional logic
• Human-in-the-loop requirements for high-stakes actions
• Multi-agent systems where agents coordinate and hand off tasks
• Conversation persistence across sessions
• Crash recovery for long-running agent tasks

LangGraph vs Alternatives:

When NOT to Use LangGraph:

• Simple RAG: Overkill. Use LangChain or Haystack instead.
• Linear workflows: If there are no loops or branches, a simple chain suffices.
• Quick prototypes: LangGraph has a learning curve. For demos, LangChain agents are faster.

Q: How is LangGraph different from LangChain agents?

Q: How does human-in-the-loop work in LangGraph?

Q: What are state reducers in LangGraph and why are they needed?