AI & automation · Guide
What is graph engineering, and when should agents run as a graph?
Graph engineering is the design of an AI system as a graph: nodes that do the work, from a fixed rule to a whole agent, and edges that choose the next step from a shared state. The name appeared in July 2026; the technique is older and is the basis of LangGraph.
Master TimmUpdated on 6 min read
Where the term came from, and what is new about it
The term took off on social media in July 2026, from a post on X. On July 22, LangChain, the company behind LangGraph, published a look back at three years of agents built as graphs and was blunt: graph engineering is not a new idea but the latest name for a well-established approach to building reliable agents.
The same post calls the term the latest output of X's AI content factory, alongside prompt, context, harness and loop engineering, and grants that these labels exist because they describe real decisions that builders face.
What has changed, in LangChain's own reading, is what fits inside a node. Early on, a node was fixed code or a single model call; now it can be a whole agent run, such as a coding agent embedded in a larger flow.
How an agent graph works
LangGraph describes itself as a low-level orchestration framework and runtime for long-running, stateful agents. It has only a few parts.
- State: The shared data structure that represents the current snapshot of the run.
- Nodes: Functions that receive the state, do some work, such as calling the model, a tool or another agent, and return the updated state.
- Edges: Connect the nodes; a normal edge always goes from A to B, and a conditional edge picks the destination from the state.
- Dynamic fan-out: With Send, a node routes work to several nodes in parallel, as in map-reduce.
- Checkpointer: Saves the state during the run, so it can resume after a failure or a pause for human approval.
A graph can have cycles, so an agent can return to an earlier node; as a safeguard, LangGraph stops a run after a maximum number of steps, 1,000 by default in recent versions.
Graph, loop or free-running agent: which design to use
The central question is who decides the path. The more predictable the structure of the work, the more sense it makes to design it; the more open the task, the more it pays to let the model plan.
| Design | Who decides the path | When to use it |
|---|---|---|
| Fixed workflowSteps in sequence, no detours | The code, the same way every time | Stable processes that must be audited step by step |
| GraphDesigned steps and branches, with nodes that can be agents | The edges, based on the state; the model decides inside each node | Flows with a known structure, approval points and expected exceptions |
| Agent in a loopThe model plans and picks the tools | The model, within the limits of the harness | Open tasks, such as research, where the path cannot be predicted |
LangChain gives examples on both sides: a support agent that classifies an issue before answering or escalating calls for a graph; a generic research agent that has to plan, delegate and synthesize does not. For that reason, GPT Researcher swapped its graph-shaped pipeline for an agent harness, Deep Agents.
When graph engineering matters to a business
A graph design pays off when the process already has a known shape and the business needs control over the path a run takes. Signs that this is the case:
- Approval mid-flow: A compliance rule requires someone to approve before an external action, such as paying or sending something to a customer.
- Long runs: The flow takes hours or days and must survive failures without starting over.
- Code and AI in the same flow: Deterministic steps, such as validating a tax document, sit next to steps where the model decides.
- Auditing: You need to know which path each case took and why.
- Different specialties: Parts of the work need different tools, instructions or models.
We design these flows with LangGraph and put human approval at the decision points. Two of Master Timm's own products have this shape: the Contas Casal assistant routes each question by intent and queries 10 SQL retrieval tools in parallel before answering, and Zorbit schedules AI coding agent runs as a DAG, where a task starts only when the tasks it depends on are done.
The risks of a graph design
A graph gives control, and too much control has a cost too. The risks show up when the graph grows faster than the need.
- Locking down an open task: Forcing work that needs free planning into fixed paths makes the result worse, as LangChain itself warns.
- A graph that is too big: Many nodes and conditional edges become a state machine that is hard to test and to explain.
- Poorly defined state: When every node reads and writes everything, the shared state becomes coupling, and a change in one node breaks another.
- Multiplied cost: Every node with a model is a call, and a parallel fan-out multiplies the calls per run.
- Little visibility: Without traces per node, in tools such as LangSmith, Langfuse or OpenTelemetry, there is no way to tell where the flow went wrong or what it spent.
A safe path is to start with a simple agent and extract the graph once the traces make the structure of the work clear.
Related service
AI & LLM Engineering
AI agents, RAG and MCP in production, not in demos.
Free first conversation · Reply within 1 business day
See also: AI Business Process Automation.
Frequently asked questions
Is graph engineering the same thing as LangGraph?
No: graph engineering is the design, and LangGraph is one framework for implementing it. The same design can be built with other tools or with plain code; LangGraph ships the state, the checkpoints, the pauses for approval and the recovery after failures ready-made.
Is every agent graph a multi-agent system?
No: many graphs have a single node with a model and the rest in code, such as a classification step followed by fixed rules. A graph becomes multi-agent when two or more nodes are full agents, each with its own tools and instructions.
How do you add human approval in the middle of a graph?
In LangGraph, a node calls interrupt, the run pauses and the checkpointer saves the state; when the person decides, the run resumes from the same point with their answer. In production the checkpointer must be persistent, backed by a database, so the pause survives a restart.
Should an agent project start with a graph?
Only when the flow is already known. If the structure of the work is not clear yet, a simple agent with good tools and traces shows which steps repeat; those steps become nodes later, with tests and approval points.
Sources
Master Timm · Updated on