	In Browser
	StumbleUpon
	del.icio.us
	Google
	Google Buzz
	reddit
	LinkedIn

	Facebook
	Twitter
	Linkedin
	E-Mail

Agentic AI > LangGraph > Building Stateful AI Agents with LangGraph

Building Stateful AI Agents with LangGraph

Author: Venkata Sudhakar

LangGraph is a library built on top of LangChain for building stateful, multi-actor AI applications using a graph-based model. While LangChain LCEL chains execute in a fixed linear sequence, LangGraph allows you to define agents as graphs with nodes (processing steps), edges (connections between steps), and conditional branching. This enables cycles - an agent can call a tool, observe the result, decide to call another tool, and repeat until it reaches a stopping condition. LangGraph is the foundation for building production-grade agentic AI workflows.

The core concept in LangGraph is the State Graph. You define a State class (a TypedDict) that holds all the information flowing through the graph. Each node receives the current state, performs some work (call an LLM, use a tool, apply business logic), and returns an updated state. Conditional edges let the graph branch: after the LLM decides to call a tool, route to the tool executor node; when the LLM gives a final answer, route to END. This is the ReAct agentic loop implemented as an explicit, debuggable graph.

The below example shows a LangGraph agent that uses two migration tools and routes between the LLM and tool nodes until it produces a final answer, demonstrating the core graph structure.

# pip install langgraph langchain-openai
from typing import TypedDict, Annotated, Sequence
from langchain_openai import ChatOpenAI
from langchain_core.messages import BaseMessage, HumanMessage
from langchain_core.tools import tool
from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolNode
import operator

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0, api_key="your-api-key-here")

# Define tools the agent can use
@tool
def get_table_row_count(table_name: str, database: str) -> str:
    "Get the number of rows in a database table. Use to assess migration scope."
    mock_data = {
        "customers": 125000, "orders": 892000,
        "order_items": 3200000, "products": 12000
    }
    count = mock_data.get(table_name, 0)
    return f"Table {database}.{table_name} has {count:,} rows"

@tool
def estimate_migration_duration(total_rows: int, target_db: str) -> str:
    "Estimate migration duration given total row count and target database type."
    rates = {"postgresql": 500000, "bigquery": 2000000, "snowflake": 1500000}
    rate = rates.get(target_db.lower(), 500000)
    minutes = total_rows / rate
    return f"Estimated duration: {minutes:.1f} minutes for {total_rows:,} rows to {target_db}"

tools = [get_table_row_count, estimate_migration_duration]
llm_with_tools = llm.bind_tools(tools)

# Define graph state - all data flowing through the graph
class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], operator.add]

# Node 1: LLM decides what to do next
def llm_node(state: AgentState) -> dict:
    response = llm_with_tools.invoke(state["messages"])
    return {"messages": [response]}

# Node 2: Execute whichever tools the LLM requested
tool_node = ToolNode(tools)

# Routing function: call tools or finish?
def should_continue(state: AgentState) -> str:
    last = state["messages"][-1]
    if hasattr(last, "tool_calls") and last.tool_calls:
        return "tools"
    return END

# Build and compile the graph
graph = StateGraph(AgentState)
graph.add_node("llm", llm_node)
graph.add_node("tools", tool_node)
graph.set_entry_point("llm")
graph.add_conditional_edges("llm", should_continue)
graph.add_edge("tools", "llm")  # After tools, always go back to LLM
app = graph.compile()

# Run the agent
result = app.invoke({"messages": [
    HumanMessage(content=
        "How many rows are in customers and orders in appdb? "
        "Then estimate migration time to PostgreSQL for the combined total.")
]})
print(result["messages"][-1].content)

It gives the following output (the agent makes 3 tool calls then answers),

# LangGraph execution trace:
Node: llm -> tool_calls: [get_table_row_count(customers, appdb)]
Node: tools -> "Table appdb.customers has 125,000 rows"
Node: llm -> tool_calls: [get_table_row_count(orders, appdb)]
Node: tools -> "Table appdb.orders has 892,000 rows"
Node: llm -> tool_calls: [estimate_migration_duration(1017000, postgresql)]
Node: tools -> "Estimated duration: 2.0 minutes for 1,017,000 rows to postgresql"
Node: llm -> Final Answer (no tool calls, routes to END)

Final Answer: The customers table in appdb has 125,000 rows and the orders table has
892,000 rows, giving a combined total of 1,017,000 rows. Migrating all of them to
PostgreSQL would take approximately 2.0 minutes.

The below example shows how to add persistence (checkpointing) to a LangGraph agent so it can maintain conversation history across turns and resume interrupted sessions.

It gives the following output,

Turn 1: The customers table in appdb has 125,000 rows.

Turn 2: Based on the 125,000 rows we identified for the customers table,
migrating to BigQuery would take approximately 0.1 minutes (about 4 seconds),
as BigQuery supports a much higher ingestion rate of 2,000,000 rows per minute.

LangGraph vs LangChain LCEL - when to choose each:

Use LCEL chains for linear, deterministic workflows where the steps are always the same: document summarisation, structured extraction, RAG Q&A. Use LangGraph when the agent needs to decide how many steps to take, which tools to use, or when to stop - essentially any agentic task that requires a reasoning loop, multi-turn memory, or human-in-the-loop interrupts. LangGraph also enables parallel node execution: two independent tool calls can run simultaneously rather than sequentially.

Send your comments, suggestions or queries regarding this site to [email protected].