Graphs and State Machines (when the shape of the task is known, draw it)

Building with LLMs. A returns desk drawn as six boxes and the arrows between them, with a seventh box, ESCALATE, that most of the arrows can end in. The board answers a question the last two lessons left open: if a loop can call any tool on any turn, what happens when the task itself only ever moves one way?

Before you start. The example running through this lesson is a support assistant for an online shop’s returns desk: a program a customer types at, which can look up an order and start a return. It runs on a model, the AI that reads text and writes text back, which is what LLMs, large language models, are. The Loop (an agent is a while loop around one model call) gave that assistant a loop: on every turn it could reach for any tool it had, a tool call being the model asking a program to run something for it, and it decided for itself when the conversation was done. This lesson keeps the same model and the same tools, and takes that freedom away.

The idea in 30 seconds

A state machine is a diagram of boxes, what the task can be, and arrows, what moves it, drawn before any code is written.
Each box becomes a node: some call the model with a short prompt and one or two tools, some are code nodes that call no model at all.
Every arrow, every edge, is code reading a fact a previous box wrote down, never code guessing at a sentence.
Wherever the model must judge something a fact can’t settle, it answers from a short fixed list, an enum, instead of writing free text.
The loop from The Loop (an agent is a while loop around one model call) is still in here, just boxed into one node at a time instead of running the whole desk.
The trade is real: fewer, cheaper, narrower model calls, at the cost of having to know the steps in advance.

Read the story · Skip to the numbers