From loops to graphs: how AI agents are growing up

TL;DR. A year ago, the exciting way to run an AI agent was a loop: point it at a task and let it repeat until done. The "leave it running overnight" screenshots were everywhere. That era is ending, and what is replacing it is graphs: agents built as structured maps of named steps, with defined paths between them, explicit state, and the ability to branch, recover from a crash, and be watched. This is not a fashion. It is the field growing up, from "run it and hope" to something you can actually run a business on. Here is the shift, the research behind it, and why it matters even if you never write a line of it.

The loop era, and its ceiling

The simplest way to run an agent is a loop. Do a step, feed the result back in, repeat until the work is finished. In its purest form that is the Ralph Wiggum technique that went viral in 2025: a coding agent in a bash loop, running unattended until it produces something. It is genuinely clever, and for the right work it still is.

But a single loop has a low ceiling, and the moment the work gets real you hit it. A loop cannot branch cleanly when a task needs to go two ways at once. It cannot recover gracefully when the machine crashes halfway through a six-hour run, it just starts over. It is hard to observe: from the outside, a loop is an opaque box that is either still going or done, with little to see in between. And it cannot easily route work, sending one kind of subtask one way and another kind elsewhere. For a weekend project none of that matters. For production, all of it does.

Enter graphs

The answer the field has converged on is to stop thinking of an agent as a loop and start thinking of it as a graph: named steps, called nodes, connected by defined paths, called edges, with state passed explicitly between them. The best-known framework for this is LangGraph, where nodes are functions, edges are the control flow, and the state is something you can see and checkpoint. There are others, but the pattern is the point.

A graph fixes exactly what the loop could not. It can branch and merge, because that is what edges are for. It can retry a single failed step instead of restarting the whole run. And because every step and every transition is named, you can watch it happen, log it, and pause it at a specific point. The opaque box becomes a map.

Sitting underneath this is a second shift, less visible but just as important: durable execution. Engines like Temporal and Restate wrap each step of a long-running agent so that if the process crashes, it resumes from where it stopped instead of redoing everything, or worse, repeating a step that already charged a customer or sent an email. A loop that runs overnight and dies at hour five loses five hours. A durable graph loses nothing. For anything that touches money or real systems, that difference is the whole game.

The frontier: graphs that build themselves

The bleeding edge goes one step further: can the graph design itself? Instead of an engineer laying out the nodes and edges, can the system search for the best structure automatically, or even generate a bespoke graph for each task?

The research says yes, with an important caveat about the hype. A 2026 survey of the field, From Static Templates to Dynamic Runtime Graphs, maps this whole space and reaches a sober verdict: fully generating a fresh workflow graph at runtime is usually overkill and riskier than it looks. The pragmatic sweet spot is to build one well-validated graph and let a router select the right piece of it per task, which captures most of the benefit while keeping the safety of a structure you already trust.

Where automatic structure search does pay off, the results are striking. AFlow, a system that searches the space of workflow graphs using Monte Carlo Tree Search, beat manually designed workflows by an average of 5.7% and other automated methods by 19.5% across six benchmarks. More tellingly, it found structures that let a smaller, cheaper model reach GPT-4o-level results on a coding benchmark at 4.55% of the cost. The structure of the graph, not just the model inside it, is where a large chunk of the performance and the cost now lives.

Why this matters even if you never build it

Here is the part for anyone paying for AI rather than writing it. This shift is not a framework preference. It is the line between a demo and a system you can depend on.

A loop is fine when nothing is at stake. Graphs and durable execution exist because production has stakes: a run has to survive a crash, be observable while it happens, and recover without repeating what it already did. This is the same maturation we described in our Oversight Ladder and in keeping AI agents trustworthy in production. Loops belong at the unsupervised, low-stakes end. Real business work belongs on structured, recoverable rails where a person and a system can both see what is happening.

So the useful question for a vendor is not "do you use the latest framework." It is simpler: what happens when a run fails halfway through? If the honest answer is "it starts over" or "we would not know," you are looking at loop-era engineering pointed at a production problem. If the answer describes a structure that recovers a single step, keeps its state, and can be watched, you are looking at someone who has made the jump from loops to graphs. That jump is quietly becoming the difference between AI that demos well and AI that runs your business.

We build production AI on structured, recoverable rails, not overnight loops, because for the work our clients depend on, that is the only honest way to do it. If you want to understand what that means for something you are considering, that is what a first conversation is for.