Agent graph

An agent graph is the written-down structure of an AI agent: the steps it can take as nodes, the transitions it may make as edges. A node is one job, such as calling the model, running a tool or asking a person. An edge says which node may follow, often under a condition. The agent still decides inside a node. Between nodes, the route is yours.

Why write an agent down as a graph?

The simplest AI agent is a loop. The model decides, a tool runs, the result goes back to the model, repeat until done. That shape is fine for a demo and hard to run in production, because nobody can say in advance which paths the loop will take with an unusual input.

A graph makes the paths explicit. If "send the quote" may only follow "check the price list" and "get approval", those are two edges, and the absence of any other edge into "send the quote" is a guarantee rather than an instruction the model might ignore.

A graph also lets you mix kinds of steps. Some nodes are plain code and always behave the same way. Some are model calls. One is a person deciding. In a graph, each node has one job and one kind of failure.

What does an agent graph consist of?

Three kinds of node show up in almost every production agent. Model nodes read the current state and produce a decision or a piece of text. Tool nodes are deterministic: look up a customer, compare two documents, write a record, usually reached through tool calling and often wired via MCP. Human nodes pause the graph and wait. This is where human-in-the-loop is implemented, as a node the route has to pass through rather than a policy in a document.

Edges are either fixed or conditional. A conditional edge reads the state and picks the next node: if the invoice total is above the limit, go to approval, otherwise go to posting.

The state is a shared record every node reads from and writes to. It carries the case through the graph, and it is the thing you inspect afterwards when a case went wrong.

Frameworks such as LangGraph make this shape a first-class construct, but a graph drawn on a whiteboard and implemented as ordinary code is one too.

Why does this matter for a company running agents?

Three things become possible that an open loop cannot offer.

Testing per node. An agent evaluation for "classify the request" is small and precise. One for "handle the request end to end" is neither. With a graph you test the parts, then the whole.

Limits by design. A graph has a finite set of routes, so a step ceiling and a cost ceiling are properties of the structure rather than a hope attached to a prompt.

Explanation after the fact. The trace of a case is a list of nodes in the order they ran, with the state at each step. That is the record your own team, an auditor or a works council asks for after an incident.

Example: a graph for incoming requests

A company receives requests by email. The graph starts with an ingest node that reads the mail and its attachments into the state. A classify node assigns a category and a confidence. A conditional edge splits: high confidence goes to an enrich node that looks up the sender in the CRM, low confidence goes to a human node that queues the case for a person.

From enrich, a draft node writes a reply using the enriched state. A second conditional edge checks the category and the amount involved. Complaints and anything above a threshold go to a human approval node. Everything else goes to a send node. A final log node writes the whole trace.

The two human nodes are not a safety net bolted on later. They are edges the graph has to take. Removing one is a change to the structure, visible in the diff and in the review, rather than a prompt edit nobody notices.

Agent graph or agentic workflow?

An agentic workflow describes what the system does: a process in which the model works out the route. An agent graph describes how far that freedom reaches. Most production agents are both, agentic inside a node and fixed between nodes.

The two mistakes sit at the extremes. A graph so rigid that it is ordinary automation with an expensive model inside it. Or a loop so open that nobody can say what it will do with the next unusual input. When we build an agent into a client's stack, the graph is the first artefact we agree on, before a prompt is written. More on that under software development.