LangGraph Tutorial 2026: Build Stateful AI Agents for Enterprise

What Is LangGraph and Why It Matters for Enterprise AI

In short

LangGraph is a graph-based Python framework for building stateful, multi-step AI agents. It solves the core enterprise problem of LangChain's linear chains: cyclic reasoning, persistent memory, and fine-grained control over agent execution flow.

LangGraph is an open-source Python library released by LangChain Inc. in January 2024. It models AI agent logic as a directed graph — every decision point is explicit, every transition is traceable, and every step can be paused, inspected, or resumed.

The simplest way to understand it: a LangChain chain is a conveyor belt — one direction, no going back. LangGraph is a flowchart — you can loop, branch, pause, and hand off to a human before the next step executes.

It solves three problems that block enterprise adoption of LangChain's standard AgentExecutor:

• No persistent state: AgentExecutor loses context between agent turns. LangGraph checkpoints state to SQLite or PostgreSQL after every node.
• No cyclic logic: Chains are acyclic by design. LangGraph natively supports loops — enabling ReAct-style reasoning that iterates until a condition is met.
• Limited observability: AgentExecutor abstracts away intermediate steps. LangGraph exposes every node execution as an inspectable event in LangSmith.

LangGraph reached v0.2 in mid-2024, introducing breaking API changes that significantly improved the developer experience. LangGraph Platform — its managed cloud offering — went generally available in late 2024.

The library is MIT-licensed and open source. Commercial support is available through LangGraph Platform (formerly LangGraph Cloud), which adds dedicated infrastructure, authentication, webhooks, and SLA-backed support.

LangGraph vs LangChain AgentExecutor: Feature Comparison

Alice Labs evaluated LangGraph against five alternative frameworks during 2024 as part of its enterprise AI agent practice. LangGraph is now the default recommendation for any multi-step, stateful, or human-in-the-loop agent use case across its 50+ implementations.

Core Concepts: State, Nodes, and Edges

In short

LangGraph has three primitives: StateGraph (the container that holds your graph definition), nodes (Python functions that read and update state), and edges (transitions between nodes that can be unconditional or conditional).

Every LangGraph application is built from exactly three primitives. Understanding them precisely prevents the architectural mistakes that cause most enterprise LangGraph projects to stall.

• StateGraph: The container that defines your graph. You instantiate it with your state schema class and then register nodes and edges before compiling to a runnable.
• Nodes: Python functions with the signature (state: YourStateType) -> dict. They receive the full current state and return a partial dict containing only the keys they are updating.
• Edges: Connections between nodes. Unconditional edges always route from node A to node B. Conditional edges call a router function that returns the name of the next node as a string — this is where branching and looping logic lives.

Two special nodes exist in every graph: START (the entry point — where your initial input arrives) and END (the terminal node — where the graph stops and returns output).

The state is the single shared data structure that flows through every node. It persists between turns when a checkpointer is attached. Think of it as the agent's working memory — it holds messages, tool results, classification flags, and any other data your agent needs to reason across steps.

Why Enterprise Teams Choose LangGraph in 2025

In short

Enterprise teams choose LangGraph because it addresses three non-negotiable production requirements: auditability (every decision point is inspectable), governance (interrupt nodes enforce human approval), and reliability (checkpointing enables resumption without restart).

Gartner's 2025 AI Hype Cycle Report found that 45% of enterprise AI projects now use multi-agent orchestration frameworks — up from 12% in 2023. LangGraph is the dominant open-source choice for Python-first teams.

The reason is architectural alignment with enterprise requirements, not just developer preference:

• Auditability: LangGraph's graph execution makes every decision point inspectable via LangSmith. You can replay any session step-by-step — a requirement for regulated industries and EU AI Act compliance.
• Governance: interrupt_before and interrupt_after nodes allow human reviewers to approve before irreversible actions execute. No custom callback engineering required.
• Reliability: Checkpointing means a failed agent resumes from the last successful node — not from the beginning. In long-running enterprise workflows, this difference can save hours of LLM compute per failure.
• Multi-vendor compatibility: LangGraph is model-agnostic. It works with OpenAI, Anthropic, Mistral, and any LangChain-compatible LLM — critical for enterprises managing multi-vendor AI strategies.

In Alice Labs' implementations for Nordic clients, observability and resumability consistently rank as the top two enterprise requirements that LangGraph addresses out of the box — requirements that competing frameworks require significant custom engineering to satisfy.

LangGraph Platform (the commercial cloud offering) adds dedicated infrastructure, authentication, webhook support, and an SLA — removing the operational blockers that historically delayed enterprise open-source adoption by 6–12 months.

For a broader comparison of agent frameworks, see our best AI agent frameworks guide for 2026.

Step 1–2: Install LangGraph and Define Your State Schema

In short

Install LangGraph with pip into a Python 3.9+ virtual environment, then design your state schema — an Annotated TypedDict that defines what data flows through the graph and how each field updates. This schema is the contract all nodes must honour.

LangGraph requires Python 3.9 or higher. Use a virtual environment — mixing LangGraph versions across projects causes dependency conflicts that are difficult to debug in CI/CD pipelines.

Install the three core packages:

pip install langgraph==0.2.* langchain-openai langgraph-checkpoint-sqlite

For Anthropic or Mistral, replace langchain-openai with langchain-anthropic or langchain-mistralai. All three are drop-in compatible — LangGraph is fully model-agnostic.

Once installed, your first and most consequential task is designing the state schema. State is an Annotated TypedDict where you specify not just what data exists, but how it updates when nodes write to it.

A customer support agent state schema for a production deployment might look like this:

from typing import Annotated, TypedDict
from langgraph.graph.message import add_messages

class SupportAgentState(TypedDict):
    messages: Annotated[list, add_messages]  # append reducer
    customer_id: str                          # overwrite reducer
    intent_classification: str               # overwrite reducer
    escalation_flag: bool                    # overwrite reducer
    tool_call_results: Annotated[list, add_messages]  # append reducer
    retry_count: int                          # overwrite reducer
    error_log: Annotated[list, add_messages] # append reducer

The add_messages reducer appends new items to the list rather than overwriting it. This is non-optional for the messages field — without it, every LLM response replaces the conversation history rather than extending it.

For production deployments, wrap your TypedDict in a Pydantic model for runtime validation. Pydantic catches malformed state updates at the node boundary rather than allowing corrupt state to propagate silently through the graph.

State Field Reducer Patterns

For multi-agent systems, agree on a shared state schema before any sub-agent is built. This is a governance requirement, not just a technical one — mismatched state schemas between sub-agents are the most common cause of integration failures Alice Labs encounters during enterprise LangGraph reviews.

Step 3–4: Build Nodes and Connect Edges with Conditional Logic

In short

Nodes are Python functions that accept state and return partial state updates. Conditional edges call a router function that inspects state and returns the next node name as a string — this is how branching, looping, and ReAct-style reasoning are implemented.

Every node follows the same contract: accept the full state, execute logic, return a dict containing only the keys you are changing. LangGraph merges your partial update into the full state using the reducers defined in your schema.

Three archetypal nodes appear in almost every enterprise LangGraph agent:

• LLM node: Calls the language model with the current message history and appends the response to state['messages'].
• Tool execution node: Runs a tool function (API call, database query, calculation) and appends results to state['tool_call_results'].
• Routing/classification node: Inspects messages or other state fields and sets a flag (e.g., intent_classification) used by conditional edges to determine the next node.

A minimal LLM node looks like this:

from langchain_openai import ChatOpenAI

model = ChatOpenAI(model="gpt-4o", temperature=0)

def llm_node(state: SupportAgentState) -> dict:
    response = model.invoke(state["messages"])
    return {"messages": [response]}

For tool execution, LangGraph's prebuilt ToolNode handles the boilerplate — it reads tool call requests from the last AI message, executes the corresponding functions, and appends results as ToolMessages.

from langgraph.prebuilt import ToolNode

tools = [search_tool, database_lookup_tool]
tool_node = ToolNode(tools)

Conditional edges are where agent decision logic lives. A router function inspects state and returns a string matching one of the registered node names — or the special END constant to terminate:

from langgraph.graph import END

def route_after_llm(state: SupportAgentState) -> str:
    last_message = state["messages"][-1]
    # If the LLM made tool calls, route to tool execution
    if hasattr(last_message, "tool_calls") and last_message.tool_calls:
        return "tool_node"
    # Otherwise, we're done
    return END

Wire the conditional edge to the graph using add_conditional_edges. The third argument maps every possible return string to a target node:

graph.add_conditional_edges(
    "llm_node",
    route_after_llm,
    {"tool_node": "tool_node", END: END}
)
# Tool node always returns to LLM for next reasoning step
graph.add_edge("tool_node", "llm_node")

This pattern — LLM node → conditional edge → tool node → back to LLM — is the ReAct loop. It cycles until the LLM produces a response with no tool calls, at which point the router returns END. It is the foundation of every retrieval-augmented, tool-using agent in production today.

For a document processing enterprise use case, you might add a document classification node before the LLM node that sets document_type in state. The subsequent conditional edge routes to specialised extraction nodes (invoice extractor, contract extractor, report extractor) based on that field — keeping each extractor focused and testable in isolation.

Step 5: Add Memory and Persistence with Checkpointers

In short

LangGraph persistence is implemented via checkpointers that save graph state to a backend after every node execution. SqliteSaver works for development; PostgresSaver is recommended for production. Pass a thread_id on every invocation to enable session resumption.

Persistence is what separates a stateless LLM call from a production-grade AI agent. LangGraph's checkpointer system automatically saves the full graph state to a backend after each node executes — enabling agents to resume mid-workflow across sessions, process interrupts, and recover from failures without restarting.

For local development, SQLite requires no infrastructure and runs in-process:

from langgraph.checkpoint.sqlite import SqliteSaver

# In-memory SQLite for development/testing
memory = SqliteSaver.from_conn_string(":memory:")

# File-based SQLite for local persistence across restarts
disk_memory = SqliteSaver.from_conn_string("./agent_state.db")

# Compile graph with checkpointer
app = graph.compile(checkpointer=memory)

For production, use PostgresSaver from the langgraph-checkpoint-postgres package. It supports concurrent sessions, connection pooling, and the horizontal scaling required by enterprise workloads.

Every invocation must include a thread_id in the config dict. LangGraph uses this to partition state — each thread_id maintains independent state history:

config = {"configurable": {"thread_id": "user-12345-session-7"}}

# First invocation — starts fresh
result = app.invoke(
    {"messages": [HumanMessage(content="Analyze this invoice")]},
    config=config
)

# Second invocation — resumes from checkpoint, full history preserved
result = app.invoke(
    {"messages": [HumanMessage(content="Now extract the line items")]},
    config=config
)

Use thread_id values that map to your application's user or session identifiers. This makes it straightforward to retrieve full conversation history, audit agent decisions per user, and debug failures without trawling generic logs.

To inspect the current state of any thread without invoking the agent, use app.get_state(config). This returns the full state snapshot — useful for dashboards, audit trails, and human review interfaces.

Alice Labs' production implementations map thread_id to the client's internal case or ticket ID. This creates an automatic audit trail linking every agent action to a specific business transaction — a requirement in regulated sectors including financial services and energy.

For deeper context on memory architecture in AI agents, see our guide to AI agent memory systems.

Step 6: Implement Human-in-the-Loop and Production Governance

In short

LangGraph's interrupt_before and interrupt_after parameters pause graph execution at specified nodes, allowing humans to review state and approve before the next step runs. This is the primary mechanism for enterprise governance compliance in AI agent deployments.

Human-in-the-loop (HITL) is not a UX feature — it is an enterprise governance requirement. Any AI agent that writes to a database, executes a financial transaction, sends external communications, or takes an action that cannot be undone must include a human approval checkpoint before execution.

LangGraph implements HITL via the interrupt_before parameter at compile time. Specify a list of node names where execution should pause:

# Pause BEFORE the tool_node executes — human sees the tool call request
app = graph.compile(
    checkpointer=memory,
    interrupt_before=["tool_node"]
)

# Invoke — graph runs until it hits tool_node, then pauses
app.invoke(
    {"messages": [HumanMessage(content="Process this purchase order")]},
    config=config
)

# Human reviews state at this point
current_state = app.get_state(config)
print(current_state.values["messages"][-1].tool_calls)

# Human approves — resume by invoking with None input
app.invoke(None, config=config)

The paused state is persisted by the checkpointer. The agent can remain paused indefinitely — hours or days — without losing context. This enables asynchronous approval workflows integrated with existing enterprise ticketing systems.

To modify state before resuming — for example, to correct a parameter in a tool call — use app.update_state(config, updated_values) before the resume invocation.

For streaming output (critical for real-time user interfaces), replace invoke with stream:

for event in app.stream(input_state, config=config, stream_mode="values"):
    # Each event contains the full state after the most recent node
    latest_message = event["messages"][-1]
    print(latest_message.content, end="", flush=True)

Connect LangSmith for production tracing. Set two environment variables: LANGCHAIN_TRACING_V2=true and LANGCHAIN_API_KEY=your_key. Every graph execution — including every node, tool call, and LLM invocation — becomes a traceable run in the LangSmith dashboard with latency, token counts, and full input/output at each step.

In Alice Labs' enterprise deployments, LangSmith traces are shared directly with client compliance teams as the primary audit artifact. No additional logging infrastructure is required — LangSmith provides a complete, timestamped, human-readable record of every agent decision.

For EU AI Act compliance considerations relevant to agentic systems, see our EU AI Act compliance checklist for 2026.

Multi-Agent Orchestration: The Supervisor Pattern

In short

LangGraph supports three multi-agent patterns: supervisor (one orchestrator delegates tasks to specialised sub-agents), hierarchical (nested supervisors for complex domains), and collaborative (peer agents share a message queue). The supervisor pattern is the most common in enterprise deployments.

Single-agent architectures hit a practical ceiling around 5–7 distinct tools or responsibilities. Beyond that, the LLM's context window fills with tool descriptions, reasoning quality degrades, and the agent becomes unreliable.

The solution is multi-agent architecture — decomposing responsibilities across specialised agents coordinated by an orchestrator. LangGraph supports three coordination patterns:

LangGraph Multi-Agent Patterns

The supervisor pattern is the right starting point for most enterprise teams. A supervisor node contains an LLM that reads the conversation and decides which sub-agent to invoke next — routing by returning the sub-agent's name as a string:

from langchain_core.prompts import ChatPromptTemplate

SUPERVISOR_PROMPT = """You are a supervisor coordinating these agents: {agents}.
Given the conversation, decide which agent should act next.
Reply with the agent name only: {agents}. When complete, reply FINISH."""

def supervisor_node(state: MultiAgentState) -> dict:
    response = supervisor_chain.invoke({
        "agents": ["research_agent", "writer_agent", "reviewer_agent"],
        "messages": state["messages"]
    })
    return {"next_agent": response.content}

Each sub-agent is itself a compiled LangGraph — enabling independent testing, deployment, and versioning. The supervisor graph treats each sub-agent as a node, passing relevant state in and receiving state updates out.

In Alice Labs' Nordic enterprise implementations, the supervisor pattern has been deployed successfully in procurement automation (routing between supplier lookup, contract review, and approval agents) and in media content workflows (routing between research, drafting, and compliance review agents).

For broader context on multi-agent architecture, our multi-agent systems guide covers agent communication protocols, failure isolation, and observability patterns in depth.

Enterprise Production Deployment: Checklist and Platform Options

In short

Enterprise LangGraph deployments require four production pillars: checkpointing to PostgreSQL, LangSmith tracing for observability, interrupt-based human-in-the-loop for governance, and a deployment target (LangGraph Platform or self-hosted containerised service). LangGraph Platform reduces DevOps overhead by an estimated 40% compared to self-hosted setups.

Moving from a working prototype to a production-grade enterprise system requires addressing four non-negotiable pillars. Missing any one of them will cause the deployment to fail security review, compliance audit, or operational SLA requirements.

• Persistence: Replace SqliteSaver with PostgresSaver. Configure connection pooling. Set a retention policy for checkpoint data — indefinite retention creates GDPR compliance issues in the EU.
• Observability: Connect LangSmith. Configure project-level and run-level tagging so traces are filterable by environment, user, and agent version. Export traces to your SIEM if required by your security policy.
• Governance: Add interrupt_before on every node that executes an irreversible action. Document the approval workflow in your AI governance policy. Reference your EU AI Act risk classification for the system.
• Scalability: Choose between LangGraph Platform (managed — recommended for most enterprises) or self-hosted containerised deployment (Kubernetes, Docker Compose). LangGraph Platform handles autoscaling, authentication, webhooks, and background task queuing out of the box.

LangGraph Deployment Options Compared

For enterprises operating under EU AI Act obligations, LangGraph's interrupt pattern and LangSmith audit trails directly address the transparency and human oversight requirements for high-risk AI systems. Document your interrupt configuration in your conformity assessment — it is evidence of technical control implementation.

Our AI production deployment checklist covers infrastructure, security, and compliance requirements for enterprise AI systems beyond the LangGraph layer.

If your team is evaluating whether to build this in-house or engage external support, our build vs buy AI guide provides a structured decision framework used across Alice Labs' 50+ enterprise implementations.

LangGraph vs Alternatives: When to Use Each Framework

In short

LangGraph is the best choice for stateful, multi-step, or human-in-the-loop enterprise agents in Python. CrewAI is simpler for role-based multi-agent scenarios. AutoGen suits research and collaborative coding agents. Use LangGraph when you need explicit control over execution flow and production-grade persistence.

LangGraph is not the right tool for every use case. Understanding where it excels — and where alternatives are faster to implement — prevents over-engineering.

LangGraph vs Alternative Agent Frameworks

The decision rule Alice Labs uses across its 50+ implementations: if the agent needs to loop, remember context across turns, pause for human approval, or coordinate multiple specialised models — use LangGraph. If you need a quick proof-of-concept with defined roles and no persistence requirement — CrewAI is faster to launch.

For a comprehensive comparison of all major open-source agent frameworks including benchmarks and licensing details, see our open-source AI agent frameworks comparison.