LangGraph Agents

A linear prompt chain — step A feeds into step B feeds into step C — works reliably only when the task follows a predictable sequence and every step succeeds on the first attempt. In practice, this assumption fails with uncomfortable frequency. A web search step might return insufficient or irrelevant results, requiring a reformulated query with different search terms. A generated draft might fail quality validation, requiring revision with specific feedback about what went wrong. A data extraction step might encounter unexpected formats, requiring fallback parsing strategies. A user might provide clarifying information mid-task that invalidates an earlier step's assumptions.

Linear chains have no native mechanism for any of these scenarios. When step B fails, the entire chain fails or produces garbage output that propagates through subsequent steps. When output quality is poor at any stage, there is no mechanism to retry with adjusted parameters or alternative approaches. When the user's request evolves mid-flow, the chain must restart entirely from the beginning, losing all intermediate work. These limitations remain manageable for simple three-step workflows but become severe as task complexity grows — any workflow involving iterative research, planning with contingencies, or multi-source synthesis quickly outgrows what linear execution can reliably handle.

The fundamental issue is that real-world tasks have branching, conditional, and iterative structure — the hallmark of agentic workflows. A research task that might need to search multiple sources, evaluate result quality, and decide whether to search more deeply or move to synthesis is inherently a graph, not a line. Forcing it into a linear chain requires either building brittle exception handling around each step or accepting frequent failures.

In LangGraph, a workflow is defined as a directed graph where each node is a function that receives and modifies a shared state object, and each edge defines a transition to the next node. Edges can be conditional — inspecting current state values to determine which node executes next. This enables branching (take path A if the retrieval quality score exceeds a threshold, path B if it does not), looping (retry a search with reformulated parameters until results meet quality criteria or a maximum attempt count is reached), and parallel execution (run multiple retrieval strategies simultaneously and merge their results before proceeding).

Persistent state is the key architectural differentiator. LangGraph maintains a typed state object that flows through the entire graph, accumulating information as each node adds or modifies data. This state captures search results, intermediate analyses, quality scores, tool outputs, error histories, and user feedback — making all accumulated context available to any downstream node that needs it. This is fundamentally different from chain architectures where each step only receives the previous step's output and has no visibility into earlier processing stages.

The graph structure also provides superior debugging and observability. Each node execution is a discrete, logged event with its own input state, output state, timing, and any errors. When an agent produces an unexpected result, the trace shows the exact path taken through the graph and the state that existed at each decision point. This makes diagnosing failures dramatically faster compared to debugging a chain of opaque LLM calls where the only visible artifacts are the input to the first step and the output of the last.

The reflection pattern introduces a quality-check node after a generation step. The checker evaluates the output against defined criteria — factual accuracy, completeness, format compliance, policy adherence — and either approves it for the next stage or routes it back to the generator with specific feedback about what needs improvement. This creates a self-correcting loop where the agent iterates on its own output until it meets quality thresholds. A maximum iteration count prevents infinite loops when the generator cannot satisfy the checker, triggering a graceful fallback instead.

The plan-and-execute pattern separates strategic planning from tactical execution. A planning node analyzes a complex request and decomposes it into an ordered list of sub-tasks with dependencies. An execution loop then processes each sub-task, feeding results back to the planner after each step. The planner can adjust the remaining plan based on what execution has revealed — adding steps that were not initially anticipated, skipping steps that turn out to be unnecessary, or changing approach when initial results suggest the original plan was suboptimal. This mirrors how skilled human practitioners approach complex projects.

The human-in-the-loop pattern pauses graph execution at designated checkpoint nodes to collect human input, approval, or correction before the workflow continues. This is particularly valuable for high-stakes workflows where certain decisions — sending an email, modifying a database, publishing content — require explicit human authorization. The agent performs research, analysis, and preparation autonomously, then presents a recommendation for human review. Upon approval (with optional modifications), the agent proceeds with execution. This pattern connects to broader human oversight design principles about when and how to involve humans in AI-assisted workflows.

The tool-selection pattern uses a routing node to dynamically choose which tool or data source to use based on the current query. Rather than hardcoding tool usage order, the agent evaluates the current state and selects the most appropriate tool — searching the web for current events, querying a database for internal data, or calling a calculator for numerical computations. This flexibility allows a single agent graph to handle diverse queries without separate implementations for each query type.

Not every AI task benefits from graph-based orchestration. If your workflow is genuinely linear with no branching, no retry logic, and no conditional paths — input goes in, model processes it, output comes out — a simple function call or basic prompt chain is easier to build, test, debug, and maintain. Adding graph infrastructure to a straightforward task introduces conceptual complexity, additional dependencies, and more failure modes without corresponding benefit.

Similarly, if your agent has fewer than three nodes and no conditional edges, the overhead of defining the graph schema (compared to simpler frameworks like CrewAI), state types, and edge functions exceeds the organizational value. The decision to adopt LangGraph should be driven by concrete workflow requirements — the need for retry loops, conditional branching, state persistence, or checkpointing — rather than architectural aspiration. Start with the simplest approach that handles your current requirements, and migrate to graph-based orchestration when you encounter the specific limitations it was designed to solve. Many successful AI applications run on simple prompt chains or single model calls, and forcing them into a more complex architecture would be counterproductive.