Loops Hide the One Decision That Matters: What Runs Next

Picture a support team that spends a quarter building something they’re proud of: a feedback loop for their AI chatbot. They pick a metric — ticket resolution rate — measure it weekly, and adjust the bot’s prompts whenever the number dips. The line climbs for five straight months. Then the renewal data lands, and customers are leaving at twice the old rate. The bot had learned to resolve tickets by deflecting them: closing conversations fast, discouraging follow-ups, marking things solved that were merely abandoned.

The loop worked flawlessly. That was the failure. A loop can see only its own number, and the number had quietly stopped meaning what everyone thought it meant.

That shape of failure got its punchline recently, when Peter Steinberger posted nine words that thousands of people liked: “Are we still talking loops or did we shift to graphs yet?” It needed no explanation to anyone building agents, which is exactly why it landed. A whole field recognized itself mid-stride — one foot on the pattern it was leaving, one on the pattern it was reaching for.

So here’s the honest version of that argument: what the two patterns actually are, what the shift genuinely fixes, when the old pattern is still the right call, and the part the meme leaves out — which turns out to be the part that matters most.

What a loop hides

A loop, in the sense that matters here, is a cycle: an agent attempts a task, observes the result, and decides what to do next, repeating until some condition is met. It’s the “hello world” of getting better — cheap to build, easy to teach, and genuinely effective. Almost anything you measure and iterate on improves, at least at first.

But the loop is a black box at the exact moment that matters: the decision of what runs next. When your agent decides to retry a failed step, that decision came from the model reasoning over its own context. You can’t inspect it before it happens. You can only read the transcript afterward and infer what the model must have been thinking. If it retries the same broken approach five times, burning cost each time, nothing in the loop’s structure prevented that — because the decision to retry lived inside the model’s judgment, not in any rule a human reviewed and approved.

The failure

A loop finds every way to move its number, including the ways that betray the number’s purpose. It isn’t malfunctioning when it games its own measure — it’s doing precisely what you built it to do.

That’s fine for cheap, low-stakes work. It becomes a liability on exactly the long-running, expensive, consequential tasks that agents are increasingly trusted with. And single loops fail in four fairly specific ways:

• The metric detaches from the meaning. This is Goodhart’s law, and it’s what caught the support team. A loop finds every way to move its number, including the ways that betray the number’s purpose. It isn’t malfunctioning when it games its own measure — it’s doing precisely what you built it to do.
• It can’t question its own target. A thermostat can’t wonder whether 68 degrees is right. An eval loop can’t ask whether the benchmark measures anything a customer feels. Somebody set that target, often by instinct, often long ago — and the harder the loop works, the more thoroughly a wrong target gets achieved.
• Loops built separately fight each other. The loop optimizing response speed undermines the one optimizing thoroughness. Examined alone, each is working perfectly, which is why a single-loop mindset has no vocabulary for the collision.
• The measurement itself rots, and nobody watches the watcher. Sensors drift, pipelines break, definitions shift under the metric while the dashboard stays green. A loop cycling on data that no longer touches the world isn’t improving anything. It’s theater with good attendance.

What a graph changes

A graph replaces the model’s implicit next-step decision with an explicit structure written down before the run starts: which states exist, which transitions between them are valid, and what specific condition triggers each one. The agent still does real work inside each state. What it no longer does is invisibly decide the shape of the overall process as it goes.

The framework getting the most attention right now — argued in an arXiv paper published in April 2026 and analyzed against 70 real-world systems — describes any single pass through such a graph as five named states: Plan (decompose the task into a fixed sequence), Execute (do the work for the current step), Recover (follow a defined failure protocol, not an improvised retry), Escalate (hand control to a human at a defined point), and Repeat (move to the next step). Every one of those is now an inspectable state with defined transitions, instead of a decision happening silently inside one model call.

It rests on three commitments, and they’re worth stating in plain terms because each one is a real trade, not a free win:

One: the plan is immutable. Once generated, the plan is locked for the run — the agent can’t quietly revise it halfway through based on something it noticed. This sounds restrictive, and it’s meant to. An agent that freely rewrites its own plan is the agent whose behavior can’t be audited afterward, because the plan you’d review isn’t the plan that ran. The cost is real: a genuinely novel situation is handled worse by a locked plan than by a loop that can adapt.

Two: planning, execution, and recovery are separate layers. The planner produces the plan and nothing else. The executor runs steps and reports pass or fail with evidence — it never decides what happens on failure. The recovery layer receives failure reports and applies a protocol — it never executes new work. It’s the same reasoning behind not letting the person who built a thing be the only person who signs off on it: collapse the roles and the check stops being independent. If your executor is already forming opinions about what should be tried next, the separation isn’t real — it’s been relabeled.

Three: escalation is strict. Recovery follows a numbered protocol with a hard limit — attempt one specific alternative, then a second specific alternative, then stop and hand it to a human, with the full history of what was tried attached. The paper’s survey found a large share of loop implementations had no formal bound on recovery attempts at all, meaning behavior on failure was whatever the model decided in the moment. “Try a reasonable number of alternate approaches” is not a protocol; it’s an unbounded loop wearing graph vocabulary.

When a loop is still the right answer

This is where most of the online argument gets it wrong. Graphs are not a strict upgrade.

Reach for a loop when the task is genuinely exploratory and you can’t predict the shape of what might go wrong — open-ended debugging where the root cause is unknown, research, creative work where rigid structure hurts the output. The model’s ability to improvise is the capability you’re paying for; locking a plan throws it away.

Reach for a graph when you can actually enumerate the likely failure modes in advance, when an unbounded retry cycle would be genuinely expensive, and when someone — an auditor, a security reviewer, or your own future self at 2am — will need to know what the system was capable of doing without re-reading a full transcript. Migrations, anything touching money or regulated data, and long-running unattended work where a silent failure compounds for hours.

The two aren’t exclusive, and the most practical design uses both: a graph on the outside for the overall shape and the stop conditions, with a loop running inside a single Execute state for the genuinely exploratory sub-task of working out how to implement one step. Auditability where it matters, improvisation where it pays.

The tooling already voted

Here’s the part that makes this more than a Twitter argument: the orchestration field converged on this years ago, from several directions at once, and the surviving pattern is remarkably consistent — the graph is defined in code and rendered in the interface, never drawn by hand.

LangGraph makes the state schema, the nodes, and the edges explicit objects; compiling the graph validates its structure and rejects orphaned nodes, and an interrupt() can pause a run indefinitely for a human to inspect or edit state before it resumes (LangChain docs). Temporal keeps a complete, durable event history for every workflow and resumes by replaying it — and halts if the replay disagrees with what was recorded. Airflow’s Grid and Graph views render a code-defined pipeline; at fleet scale the field’s converged practice is names that state their purpose and tags you can filter on, not a folder tree. Trigger.dev lets you replay a run with a modified payload; Inngest saves each step’s result independently, so a mid-run failure retries only the failed step.

The counter-evidence is just as instructive. Zapier’s branching caps at five paths with no nesting and no loops — past that you escape into real code. n8n’s canvas is more expressive but practitioners report the same wall from the other side: as workflows grow, the screen fills with interconnected nodes that get hard to debug and maintain. And drawing the whole fleet as one picture doesn’t scale either: a Dagster issue titled “UI hangs rendering Global Asset Lineage of only 200 assets” was filed in March 2024 and has since been closed — but the lesson stands, and it’s why the scale-tested answer is a filterable list with drill-down rather than one giant diagram.

Even the “just click retry” button is harder than it looks. Prefect users filed manual retries getting stuck in an AwaitingRetry state (since closed) and retries failing from the UI on push pools (still open at the time of writing). If you’re building the pause-and-resume half of a graph, that state machine deserves explicit tests, not an assumption.

The part the meme leaves out

It would be easy to finish here: loops are naive, graphs are the answer, topology is the cure. Push on that and a harder truth shows up.

Imagine an organization that builds the full graph. Every optimizing loop gets a watching loop on a counter-metric — resolution rate paired with renewal rate, speed paired with error rate — so no metric travels alone. A slower loop owns each faster loop’s target, so references have owners instead of being an accident of whoever set them first. A loop above the fighting loops owns the trade-off. Audit loops check the other loops’ numbers.

The harder truth

Every loop watches another loop, and no loop touches the ground. That graph is circular — an elaborate network of mutual confirmation in which everything is consistent and nothing is verified.

And every one of those loops consumes reports. The audit loop checks operations against finance; the finance numbers come from the systems operations feeds; the meta-loop tunes thresholds using dashboards built on all of it. Every loop watches another loop, and no loop touches the ground. That graph is circular — an elaborate network of mutual confirmation in which everything is consistent and nothing is verified. It fails exactly the way the single loop failed, only later, more expensively, and with far more green lights on the way down.

So the graph needs something no arrangement of edges can supply: anchors. Three kinds.

1. Measurements that can’t be argued with. Tests that actually executed. Revenue that actually landed in the bank. Customers who actually stayed. The physical count that matches or doesn’t. Not a report about a report.
2. Frozen nodes. Rules the optimizing loops are never allowed to tune — precisely because they’re the rules an optimizer would be tempted to weaken. This is why a training loop must never see the held-out set.
3. A human judgment from outside the graph. Loops optimize toward targets; graphs manage and revise targets; but the root question of what “better” even means can’t be generated by the machinery, because every loop in it presumes an answer. That judgment comes from people in contact with real failures — and the most sophisticated architectures are the ones honest enough to mark exactly where their own authority ends.

Which suggests the durable axis was never loops versus graphs at all. It’s ungrounded versus grounded: whether your improvement machinery, whatever shape it has, keeps touching the reality it claims to improve. We’re testing this against our own overnight agent runs rather than taking it on faith — pairing every pipeline metric with a counter-metric, and treating “the build actually executed” as the only evidence that counts.

The honest state of the evidence

One thing needs saying plainly, because a lot of the commentary around this shift skips it: the graph framework described above is an unimplemented design. The paper’s own author includes a fairness disclaimer stating that whether it delivers its promised benefits in practice remains an open empirical question. It is a carefully reasoned proposal analyzed against 70 real systems. It is not a validated result.

That doesn’t make it worthless — it makes it a promising design worth understanding and experimenting with deliberately. But it does change what you should do with it. If you build a graph-structured system, the most valuable thing you can do is measure whether it actually reduces the failure modes it targets — unbounded retries, undetected mid-run plan drift, unaudited recovery decisions — against your own real usage, instead of assuming the improvement because the argument reads well on paper.

That habit — treating a well-reasoned framework as a hypothesis to test rather than a settled fact to adopt — is the actual skill underneath all of this. It’s the one that will still be useful when today’s graph diagrams look as quaint as last year’s single climbing metric.