Lesson 01 · Foundations · 11 min

Why graphs

A loop is implicit control flow. On every turn the model decides what happens next, and that flexibility is exactly right for open-ended work where the path cannot be known in advance.

It becomes wrong when part of the process must not vary. If a refund has to be checked against policy before it is issued, a loop can only be asked to do that. Asking works most of the time. Most of the time is not a control.

There is a recognisable moment when a team crosses this line: the system prompt starts containing a flowchart. "First look up the order. Then check the policy. Only if both succeeded, propose a refund. Never propose one for an order still in transit." That is structure written as prose, enforced by hope.

Nodes do one thing each and never call one another. They communicate only through shared state, which is why a graph is inspectable: at any point you can ask what is known, and the answer is a plain object.

NodeOne step. It reads shared state, does one thing — a model call, a tool call, a decision — and writes back.

EdgeA permitted transition between nodes. Some are unconditional; some fire only when state matches.

StateThe object every node reads from and writes to. It is what carries information between steps.

The trade is real and worth naming. Graphs give you guarantees, inspectable routes and natural approval points. They cost flexibility: a path you did not draw cannot be taken, so a graph handles the unexpected badly. Choose by how much of your process is genuinely fixed.

The lab runs three graphs over the same message. Start with "Straight through" — one path for everything — and notice what it cannot do rather than what it can.

Checkpoint

Name one thing the straight-through graph gets wrong that a routed one would not.