Graphs in production

A graph gives you something a loop cannot: a finite set of paths. That makes testing tractable, because you can enumerate them and ask which are exercised — the same idea as code coverage, applied to routes.

• Cover every path. An untested path is one nobody has ever seen run.
• Check for unreachable nodes. If no input reaches a node, either the routing is wrong or the node is dead.
• Assert on routes, not only replies. "A refund request must visit the policy node" is a stronger test than checking the wording of an answer.
• Record the path with every run. In production it is the first thing you want when something looks wrong.

That last one ties the courses together. Evals grades outputs; agent loops showed that a right answer reached by an unreliable route will not stay right; a graph makes the route a first-class thing you can assert on. "Did it visit the policy node before the refund node" is a grader you can write.

Knowing when to go back is part of the skill. If you keep adding branches for cases you did not anticipate, the structure is fighting the problem: the task is more open-ended than a graph wants. Many real systems end up mixed — a graph for the parts that must not vary, with a loop inside one node for the part that genuinely needs to improvise.