Chapter 5: Agentic workflows with LangGraph

Introduction

Introduces agentic workflows as structured, multistep processes in which an LLM makes decisions within predefined boundaries.

• Structured agentic workflows: Explain how an agentic workflow uses an LLM to orchestrate predefined components across multiple steps while managing state explicitly. Describe why its consistent sequence and bounded decisions favor reliability, transparency, and control over dynamic adaptation during execution.
  Why it matters: This distinction helps you recognize what makes a workflow agentic without confusing it with a more autonomous agent.

Key terms: agentic workflows, predefined components, explicit state management

5.1 Understanding agentic workflows and agents

This section distinguishes agentic workflows from agents by how much freedom the LLM has to determine the application's next steps.

• Workflow and agent distinction: Distinguish an agentic workflow from an agent by describing how each uses an LLM to guide what happens next.
  Why it matters: The distinction helps you describe whether an application follows a predictable path or adapts its next steps as circumstances change.

Key terms: agentic workflow, workflow, agent, LLM, tool

5.1.1 Workflows

Defines workflows as LLM-guided choices among limited next steps and distinguishes two common workflow patterns.

• Limited workflow choices: Explain that a workflow uses an LLM to choose the next step from a limited set of choices.
  Why it matters: This distinguishes the LLM’s decision-making role from unrestricted control of the workflow.
• Controller and router patterns: Distinguish a Controller-Worker pattern, in which a controller spawns worker tasks in a sequence, from a Router pattern, in which the LLM directs a task to the appropriate processor or worker.
  Why it matters: These patterns show two ways a workflow can organize its limited choices.

Key terms: workflow, LLM, next step, Controller-Worker, Router, controller, worker

5.1.2 Agents

Defines LLM-based agents by their goal-directed use of language models and contrasts their adaptable flows with fixed prompt–response systems.

• Goal-directed language model use: Explain that an LLM-based agent uses a language model to perceive data, reason about it, decide on actions, and pursue a goal.
  Why it matters: This distinguishes an agent’s goal-directed role from simply producing a response.
• Adaptive agent flows: Distinguish agents from fixed prompt–response systems by describing how agents generate flows based on real-time data and available tools. State that advanced agents may also retain past interactions and learn from feedback.
  Why it matters: Adaptability is the section’s key contrast between agents and fixed prompt–response systems.

Key terms: LLM-based agents, language models, actions, goals, fixed prompt–response systems, dynamic workflows, real-time data, available tools, memory of past interactions, feedback

5.1.3 When to use agent-based architectures

Explains when agentic workflows or agents are worth using and why their added complexity must be justified.

• Choosing an Agentic Architecture: Explain when an LLM-based workflow or agent is useful and why its added power does not always justify its complexity.
  Why it matters: This helps you decide whether an agentic architecture is worth the complexity for a particular application.

Key terms: LLM-based workflows, agents, explicit state management, dynamic control

5.1.4 Agent development frameworks

The section compares agent development frameworks by their focus and tradeoffs, highlighting LangGraph’s role in building stateful, persistent workflows.

• LangGraph focus and tradeoff: Explain that LangGraph uses graph-based execution to build stateful, persistent agentic workflows, making it powerful for complex applications but potentially more demanding technically.
  Why it matters: This explains why the chapter uses LangGraph for complex agentic workflows.
• Framework priorities and tradeoffs: Distinguish a few other frameworks by the priorities and limitations the section names, rather than treating agent frameworks as interchangeable.
  Why it matters: A framework’s strengths and limitations help determine whether it fits an agent project.

Key terms: LangGraph, stateful, persistent agentic workflows, graph-based execution, AutoGPT, CrewAI, n8n, LangFlow, tradeoffs

5.2 LangGraph basics

Introduces LangGraph as a graph-based extension of LangChain for organizing stateful, multi-step agentic workflows.

• Graph tasks paths and state: Describe how LangGraph represents a workflow: nodes are individual tasks, edges connect those tasks, and state carries information between nodes and updates at each step.
  Why it matters: These terms let you describe a workflow before getting into its implementation.
• LangGraph and LangChain roles: Distinguish LangChain’s role in supplying components from LangGraph’s role in organizing those components into a structured, stateful workflow.
  Why it matters: The distinction clarifies why the two frameworks can be used together.
• Graph workflow suitability: Explain why a LangGraph workflow is useful compared with a traditional chain when an application needs decisions, branching paths, or state management.
  Why it matters: It helps you recognize when a straightforward chain may not fit the workflow you need.

Key terms: nodes, edges, state, LangChain, LangGraph, LLMs, embeddings, retrievers, branching paths, stateful processing

5.3 Moving from LangChain chains to LangGraph

This section explains why complex applications may outgrow linear LangChain chains and how LangGraph’s graph-based workflows address their limits.

• Limits of linear chains: Explain why simple LangChain chains suit straightforward tasks but struggle as workflows become more complex.
  Why it matters: These limits help explain when moving beyond a linear chain is worthwhile.
• LangGraph workflow capabilities: Describe how LangGraph’s explicit state management, conditional branching, and cyclical workflows address complex workflow needs.
  Why it matters: These capabilities give multi-step systems ways to retain context and adapt their path.
• Graph visibility and use cases: Explain why LangGraph’s graph-based structure helps with complex workflows and name examples given in the section.
  Why it matters: Clearer data flow makes a complex workflow easier to inspect when something goes wrong.

Key terms: LangChain, linear chains, state, LangGraph, explicit state management, conditional branching, cyclical workflows, graph-based structure, data flows, multi-step reasoning

5.4 LangGraph core components

Introduces the state, nodes, and edges that make up a LangGraph workflow, including how its path can change at runtime.

• Strongly Typed Workflow State: Explain that a LangGraph application has a state object, typically a Python TypedDict, that defines structured, type-checked data for the workflow.
  Why it matters: The shared state gives the workflow a defined structure for passing data between components.
• Nodes and Directed Edges: Describe nodes as processing units, usually Python functions, and edges as the connections that direct data through the graph.
  Why it matters: Distinguishing processing from flow makes the graph’s basic structure easier to describe.
• Conditional Paths and Boundaries: Explain that conditional edges can choose execution paths based on runtime state, while entry points and end conditions define where execution begins and finishes.
  Why it matters: These components explain how a workflow can follow different paths rather than one fixed sequence.

Key terms: state object, ResearchState, TypedDict, nodes, edges, directed flow, conditional edges, runtime state, entry points, end conditions

5.4.1 StateGraph structure

5.4.2 State management and typing

This subsection explains why LangGraph uses explicit, strongly typed state and how nodes update that state.

• Explicit typed workflow state: Explain how LangGraph’s explicit, strongly typed state differs from the implicit or loosely typed state of chain-based methods and why that makes workflows more robust and predictable.
  Why it matters: Explicit state makes it easier to reason about what a workflow carries between steps.
• Node state updates: Describe how a LangGraph node receives the current state and returns updates that merge into the overall state.
  Why it matters: This is the basic state exchange between nodes in the workflow.

Key terms: state management, strongly typed state, ResearchState, node, current state, updates, overall state

5.4.3 Node functions and edge definitions

This subsection defines nodes as state-processing functions and edges as transitions between nodes, including state-based conditional transitions.

• Node Functions and State Updates: Explain that a node is a processing step implemented as a function that takes the current state and returns updates.
  Why it matters: This identifies what each processing step does in a graph.
• Linear and Conditional Edges: Distinguish edges as valid transitions between nodes, including simple linear edges and conditional edges that use a function to choose the next node from the state.
  Why it matters: This explains how a graph connects processing steps and can choose where to go next.

Key terms: node, current state, updates, edges, valid transitions, linear edge, conditional edge, state

5.4.4 Entry points and end conditions

This subsection states that a LangGraph graph needs a starting point and clear end conditions.

• Graph start and end conditions: State that every graph needs a starting point and clear end conditions.
  Why it matters: These boundaries make it clear where a graph begins and when it is finished.

Key terms: starting point, end conditions

5.5 Turning the web research assistant into an AI agent

Introduces a LangGraph upgrade to the web research assistant that routes its work according to the relevance of web-page summaries.

• Relevance gated research flow: Describe how the upgraded assistant uses summary relevance to decide whether to generate new search queries or write the final report. Explain why this dynamic control motivates moving from plain LangChain to LangGraph.
  Why it matters: The relevance check explains what the agent-based version adds to the original research assistant.

Key terms: LangGraph, LangChain, relevance of summaries, search queries, final report, dynamic control

5.5.1 Original LangChain implementation overview

This section recaps the web research assistant’s sequential LangChain workflow and explains why its linear flow and lack of explicit state make adaptation and troubleshooting difficult.

• Original research assistant workflow: Trace how the original assistant passed work through sequential chains, from choosing a research assistant and generating searches to summarizing results and compiling a report.
  Why it matters: This is the workflow the chapter is about to convert.
• Sequential chain limitations: Explain why the original linear chains make conditional changes, error handling, context management, and debugging difficult.
  Why it matters: These limitations explain the motivation for changing the assistant’s architecture.

Key terms: sequential chains, web research assistant, research report, rigid and linear, conditional flow, explicit state, error handling, debugging

5.5.2 Identifying components for conversion

The section identifies the web research assistant’s LangGraph nodes, the state each node needs and updates, and the conditional route that can repeat research before writing a report.

• Research assistant node roles: Describe how the assistant’s work is divided among the Assistant Selector, Query Generator, Web Searcher, Content Summarizer, Relevance Evaluator, and Report Writer.
  Why it matters: The node roles show what must be separated when converting the existing assistant into a graph.
• Relevance based routing: Trace how the relevance check determines whether research repeats or a report is written, including what happens at the iteration limit.
  Why it matters: The relevance decision lets the assistant improve its research without looping indefinitely.
• Per node state definition: Describe the input state, processing, and state updates defined for each component.
  Why it matters: These three descriptions clarify what each node receives, does, and contributes to the graph.

Key terms: nodes, Assistant Selector, Query Generator, Web Searcher, Content Summarizer, Relevance Evaluator, Report Writer, route_based_ on_relevance, threshold, iteration count

5.5.3 Step-by-step transformation process

This section converts a linear LangChain research assistant into a stateful LangGraph workflow that can repeat searches when its results are not relevant enough.

• Shared graph state: Explain why the conversion begins by defining a composite state that flows through the graph and makes the data available at each stage clear.
  Why it matters: The nodes need a clear, shared account of the data they work with.
• Components as node functions: Describe how existing components become node functions that take the current state, perform their task, and return updated state information.
  Why it matters: This gives the graph separate steps that can be connected into a workflow.
• Relevance-based conditional routing: Trace how the Relevance Evaluator changes the graph's path: insufficiently relevant summaries send it back to refine queries, while sufficient summaries or the iteration limit send it toward the final report.
  Why it matters: The relevance check is what makes this workflow adaptive instead of a rigid linear chain.
• Graph compilation and initialization: Describe the final step of compiling and running the graph with an initial state containing required fields, including parameters that control conditional flow.
  Why it matters: The initial state supplies the values the graph needs when execution begins.

Key terms: state, composite state, inner types, node function, current state, updated state information, Relevance Evaluator, conditional edge, Query Generator, iteration

5.5.4 Code comparison and benefits realized

Compares the LangGraph version of the case study with traditional LangChain chains, emphasizing the benefits of explicit state, modular graph structure, and conditional flow.

• Runtime Conditional Flow: Explain how conditional edges let the application choose its next step based on a relevance evaluation, and why this is more adaptable than a plain LangChain chain.
  Why it matters: This is the main reason the graph can adapt to intermediate results.
• Explicit State Handling: Describe how defining state and passing it through each node makes data handling transparent and reliable.
  Why it matters: Explicit state makes it easier to see what data each step receives and passes on.
• Modular Graph Benefits: Explain how single-task nodes and a visible graph structure help with tracing, debugging, maintenance, error handling, and later changes.
  Why it matters: These properties make a complex workflow easier to inspect and change.

Key terms: conditional edges, relevance evaluation, conditional flow control, explicit state management, state, node, modular components, nodes, edges, clear flow control

5.6 Summary

This chapter summary recaps how LangGraph represents agentic workflows as stateful graphs, how their nodes and routing work, and why they help when moving beyond linear LangChain chains.