3 Years of Graph Engineering with LangGraph

The Big Idea

On July 22, 2026, Sydney Runkle and Harrison Chase published "3 Years of Graph Engineering with LangGraph" on the LangChain blog - a retrospective on representing agentic systems as graphs. Their core argument: "graph engineering" is not a new concept dressed in a new buzzword. LangChain has been building production agent systems as directed graphs for three years, and LangGraph now processes 65M+ downloads per month. The framework encodes a simple but powerful abstraction - Nodes do work, Edges define transitions, and State moves through the graph. The key insight that separates graph engineering from traditional pipeline orchestration is that production agents need cycles. Retries, user clarification loops, repeated tool calls, and answer revision all require the graph to revisit nodes it has already executed. This makes agent graphs fundamentally different from DAGs (directed acyclic graphs), which by definition cannot loop back. The post traces how nodes themselves have evolved - from fixed code steps to single LLM calls to full agents with their own internal loops - meaning LangGraph now orchestrates agents, not just LLM calls.

Before vs After

How It Works

Graph Architecture: Nodes, Edges, State

The core abstraction has three components. Nodes perform work - they take the current state, do something (run code, call an API, invoke an LLM, or run an entire sub-agent), and return updated state. Edges define transitions between nodes - they can be unconditional (always go from A to B) or conditional (route based on state content). State is a typed object that flows through the graph, accumulating information as each node processes it. The graph executes by starting at an entry node, flowing state through edges to subsequent nodes, and continuing until it reaches an end node or a cycle stabilizes. What makes this different from a simple function pipeline is that edges can point backward - creating loops that enable the retry, revision, and multi-turn patterns that production agents require.

The Deterministic-to-Agentic Spectrum

Runkle and Chase describe a spectrum of node types that ranges from fully deterministic to fully agentic. At the left end, Fixed Steps execute set code - API calls, data parsing, validation logic - with no LLM involvement and completely predictable behavior. In the middle, Model Steps make a single LLM call to classify, extract, or generate based on the current state. At the right end, Agent Steps contain a full agent with its own internal execution loop - the agent decides which tools to call, how many times to loop, and when to stop. The critical design decision in any LangGraph application is where each node sits on this spectrum. More agentic nodes provide flexibility but reduce predictability. The post argues that most production systems mix all three types: deterministic preprocessing, a model-based routing decision, then an agentic execution phase.

Use Cases: Knowledge Base Agent and Docs Agent

The post details two production architectures. The Knowledge Base Agent uses a fan-out pattern with three subagents - GitHub, Notion, and Slack - coordinated through three stages: classify the query, search across all sources in parallel, then synthesize results into a single answer. Each subagent is itself a full agent node with its own tool-calling loop, and the fan-out count is fixed (three sources). The Docs Agent handles a different pattern: a Slack request arrives, gets classified, then routes through a mix of fixed steps (fetch repo context), model steps (generate code changes), and agent steps (validate and iterate on the PR) to produce a ready pull request. The key design point is that both architectures mix node types intentionally - they do not commit to being "fully agentic" end-to-end but use deterministic nodes where predictability matters and agent nodes where flexibility is required.

Key Findings

• Agent graphs are not DAGs. Production agents require cycles for retries, asking users for clarification, revising answers, and repeated tool calls. A directed acyclic graph cannot express these patterns - you need directed cyclic graphs where edges can point backward.
• Loops are simple graphs. A basic agent loop (call LLM, check if done, call tools, repeat) is itself a directed cyclic graph with just two or three nodes. LangChain's simple agent framework is built on top of LangGraph, not as a separate system. The simple case is a subset of the general case.
• Dynamic transitions matter for real workloads. The Send API enables map-reduce patterns where the number of parallel workers is not known until runtime. This handles cases like "search N repositories" where N comes from a previous classification step, not from the graph definition.
• Nodes evolved from code to agents. Three years ago, LangGraph nodes were code steps or single LLM calls. Now a node can be a full agent with its own internal tool-calling loop. The framework has moved from "orchestrating LLM calls" to "orchestrating agents."
• Graph structure encodes world knowledge. The authors call these "cognitive architectures" - the graph topology encodes what you know about how a system should work. A well-designed graph reflects domain expertise about task structure, not just control flow.
• The terminology proliferation is real. Prompt engineering, context engineering, harness engineering, loop engineering, graph engineering - all describe real challenges in getting LLMs to do work. The reason so many terms exist is that the problem is genuinely hard and multi-dimensional.

Why This Matters for AI and Automation Practitioners

The practical implication of this retrospective is clarity about when to reach for a graph-based orchestration framework versus simpler alternatives. If your agent system has any of these characteristics - retry logic, human approval gates, multi-step revision, parallel tool execution with dynamic fan-out, or mixed deterministic/agentic pipelines - you are already building a graph whether you model it as one or not. LangGraph makes that graph explicit, inspectable, and debuggable rather than implicit in nested function calls and conditional branches scattered across your codebase. The 65M+ downloads figure validates that this is not a niche pattern - it is how a large segment of the production agent ecosystem actually structures their systems. For practitioners who have been building agents with simpler abstractions and hitting walls around retry logic, state management, or human-in-the-loop flows, the graph model provides a clean formalization of patterns you have likely been implementing ad-hoc. The evolution from "nodes as LLM calls" to "nodes as full agents" also signals where the framework is headed: multi-agent orchestration as the default, not the exception.

My Take

The most honest and useful part of this post is the explicit acknowledgment of when graphs are the wrong tool. Runkle and Chase could have presented graph engineering as universal - they have 65M+ monthly downloads and every incentive to position it that way. Instead, they point directly at GPT Researcher's decision to move away from graphs for deep research tasks and explain why: when the execution path is fundamentally unpredictable and recursively nested, pre-defining a graph topology becomes a constraint rather than an aid. That intellectual honesty makes the positive claims more credible. The "cognitive architecture" framing is the most important conceptual contribution. When you define a graph for an agent system, you are encoding your domain knowledge about how the task should flow - which steps are deterministic, which need model judgment, where cycles are expected, and where human oversight is required. That is a design document and an execution engine in one artifact. The term "graph engineering" itself will generate some eye-rolling - it joins a crowded field of "X engineering" labels. But the underlying point stands: representing agent systems as explicit graphs with typed state, conditional edges, and first-class cycles is a meaningfully different design choice from either linear pipelines or fully autonomous agent loops, and three years of production usage at LangChain scale validates that it works for the problems it targets.

Discussion Question

LangGraph's evolution from "orchestrating LLM calls" to "orchestrating agents" raises a design tension: when a node is itself a full agent with an internal loop, you have nested control flow that can be difficult to reason about, debug, and set cost guardrails for. At what level of nesting does the graph abstraction stop helping and start obscuring? If you are building multi-agent systems, where do you draw the line between making the agent a node in an outer graph versus giving it full autonomy to manage its own execution - and how do you maintain observability across both levels?