A Loop With Better Marketing

Three weeks ago I published a piece arguing that the loop is the easy part. The mechanism at the center of every AI agent is about six lines long, and everything that decides whether it helps you or burns your budget is bolted around it.

Three days later, Peter Steinberger, who built the OpenClaw agent framework, posted twelve words: "Are we still talking loops or did we shift to graphs yet?"

Two point nine million views.

By the next morning the vocabulary had reorganized itself. There were now five layers, in a tidy hierarchy people were sharing as though it had been settled for years: prompt engineering, context engineering, harness engineering, loop engineering, and, newly crowned at the top, graph engineering.¹1The stack assembled in public over about five weeks. @akshay_pachaar posted four layers on June 23 with no graph in them. @_avichawla still had four on July 3. @sairahul1 named all five as one lineage on July 19, the day after Steinberger. Within forty eight hours the term had three competing definitions, a wave of copycat posts, and two separate Stanford studies invented to prove it.

Neither study has ever been produced.

There is a real idea buried in here and it deserves better than the treatment it is getting. More useful than the idea, though, is the pattern. A category arrived fully formed, with a name and a hierarchy and a set of statistics, before anyone ran a controlled test. That happens constantly now, and spotting it from the outside is worth more to you than an opinion about graphs.

Start with what they are right about

The distinction underneath is sound, and it is simple enough to state in two sentences.

A loop is how one worker handles time. Try something, look at the result, correct, try again. It answers a question about dependence: step two needs step one's answer before it can start.

A graph is how work is arranged in space. Which pieces exist, which can run at the same time, what feeds into what. It answers the opposite question: these four things never needed to talk to each other at all.

From that falls the one mechanical claim the whole movement rests on. A loop reviews a document three times in sequence. A graph sends it to three reviewers at once and collects the answers. If the three reviews truly do not depend on each other, the graph finishes in a third of the time.

That claim is narrower than it sounds, because it is about concurrency and nothing else. Arranging work in a diagram does not make a model smarter, does not make an answer more correct, and does not fix anything that was broken in the loop. It runs independent things at the same time.

So the decision collapses onto one variable that almost nobody puts on screen: how many of your subtasks need another subtask's output before they can start. Drag it and watch each bar.

Wall clock stops improving the moment a dependency chain forms, because the chain is the critical path and no topology shortens it. The cost bar has no slider that makes it go down.²2The 25 percent overhead default is an assumption you can change, not a measurement. A nine-framework comparison posted to r/LangChain on July 23 put LangGraph at roughly 40 percent higher token overhead per step than a simple tool loop, which is the closest published figure I found and is a forum claim rather than a benchmark. Fan-out charges its coordination tax whether or not the topology bought you anything, and it never announces the charge.

The two studies that do not exist

On July 19, an account posted this in capital letters: "STANFORD AND ANTHROPIC SPENT $3.1M TO PROVE YOUR AGENT PERFORMS 42% WORSE THAN IT SHOULD." Thirteen thousand tasks. Code accuracy up 36 percent, research up 45, unnecessary actions down 39. A thousand likes, a hundred and forty eight thousand views.

Eugeniu Ghelbur, writing at The AI Operator, went looking for the grant and could not find it. There is no such study.

The following day a different account invented a different one. Stanford again, this time two years and 9,842 tasks, with its own set of round numbers.³338.6 percent, 24.1 percent, 21.7 percent. Note the difference in what I can tell you about the two. The first was traced by a named person who went looking for the grant. For the second I can only say that a sweep across eight source legs and 45 fetched pages turned up nothing corroborating it, which is a statement about my search, not about the world. Nobody has produced either paper. Running alongside both is a cluster of accounts describing "a senior Anthropic engineer's twelve page PDF on graph engineering," each summarizing the same five stage pipeline, each attributing it a little differently. In none of the posts is the PDF ever linked.

Meanwhile, the actual evidence

Eleven weeks before Steinberger's post, five researchers published a controlled comparison of exactly the question at issue. In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks, submitted on April 30. They took three domains, travel booking, technical support, and insurance claims, and ran two hundred conversations through each under two conditions. One used LangGraph to route the model through an explicit graph. The other threw the graph away and wrote the procedure into the system prompt.

The orchestrated version failed on 24 percent of travel conversations, 9 percent of support, and 17 percent of insurance claims. The version with no orchestration at all failed on 11.5 percent, 0.5 percent, and 5 percent.

Adding the graph doubled the failure rate on travel, tripled it on insurance, and on support multiplied it by eighteen.

I want to be careful with that, because I am about to ask you to be careful with other people's numbers. It is a preprint and has not been through review. The scoring was LLM-as-judge, which is a soft instrument. And it tested procedural tasks specifically, which are the sequential case where a graph should not help anyway. It does not test the one thing graphs are good at, which is work that splits cleanly into independent parts.

So it is not the last word. It is a real experiment with a stated method, published before the argument started, finding the opposite of what the fabricated studies claimed. It appears nowhere in the viral tier I swept.

The paper that was already sitting there

There is a second one, and its date is the interesting part.

In 2025, a team at UC Berkeley published Why Do Multi-Agent LLM Systems Fail?. Seven frameworks, over two hundred tasks, six expert annotators hand-labelling more than 1,600 execution traces. Out of that came a taxonomy of fourteen distinct failure modes in three groups: bad specification, agents talking past each other, and nobody checking the final result. Inter-annotator agreement was 0.88, which for hand-labelling work like this is high.

It is the most rigorous study of why systems built out of coordinating agents break. It went through NeurIPS. It was a year old by the time the internet started inventing evidence about graphs.⁴4The most quoted statistic about multi-agent failure rates, a range of 41 to 86.7 percent, traces to a Substack summary of this paper rather than to the paper. I could not verify it against the source, so it is not in this piece. The taxonomy, the trace count and the kappa are confirmed. Those two numbers are not.

This is what David Khourshid, who wrote the XState library, was pointing at when he called graph engineering a rebrand of 1990s workflow engines and said builders are re-inventing the state machine badly. Grady Booch put it less gently: "Most are entirely ignorant of the existing literature in this space."

Three different graphs are wearing one word

Separate these before you argue with anyone about this, because much of the heat comes from people defending different objects.

There is a graph as control flow, which is orchestration and the actual subject of the argument. There is a graph as retrieval index, which is a code graph, a way of finding things. And there is a graph as memory, which is a knowledge graph. They share a noun and nothing else.

The conflation is not theoretical. Several viral threads slide between all three inside a single post, which is a large part of why the term produced three competing definitions in forty eight hours.⁵5I had a concrete example here and cut it, because verifying it would have meant citing three SEO aggregator pages of exactly the kind this piece spends a section discrediting, and the primary route I would have used to check it properly was returning an HTTP 403 on a spending limit. An absent result is a statement about your instrument. A retrieval index and a control-flow graph have different failure modes, different costs, and nothing to say about each other.

When someone says graph engineering, establish which of the three they mean before engaging.

What it is actually like to run one

I am not writing this from the sidelines. Since the start of June I have run parallel fan-out as a daily default, which is the graph pattern under a different name, and wrote up the seven-week mark in July. My standing rule now is that I do not decide to fan out. I decide not to.

The primitive I use makes the distinction concrete in a way no five-layer diagram does. There are two ways to run multi-stage work across a set of items, and picking the wrong one is the mistake:

// Barrier. Every item finishes stage one before any item starts stage two.
// Correct only when stage two needs cross-item context from all of stage one.
const found = await parallel(items.map(i => () => review(i)))
const deduped = dedupe(found.flat())
const checked = await parallel(deduped.map(f => () => verify(f)))

// No barrier. Item A can be in stage three while item B is still in stage one.
// Wall clock is the slowest single chain, not the sum of slowest-per-stage.
const checked = await pipeline(items, i => review(i), r => verify(r))

That choice is the loop-versus-graph decision, already solved, sitting in the harness. It has been there longer than the vocabulary has. Almost every barrier I have written turned out to be unnecessary, because I reached for one when I wanted to flatten a list, not because stage two genuinely needed all of stage one.⁶6The test is whether stage two's prompt refers to the other items. Dedup across a full result set, or an early exit when the total count is zero, are real reasons for a barrier. Needing to map and filter first is not, and that transform belongs inside a pipeline stage.

Two things the experience taught me, neither of which appears in any hierarchy.

The topology was never the hard part. The judgment about when to use it is. I have fanned out a simple rename that one careful pass would have finished faster and cleaner. I have run one careful pass on a discovery job that needed five independent searchers, and missed a third of the surface as a result. Neither mistake announces itself. Over-orchestrating costs money. Under-orchestrating hands you a confident, incomplete answer.

The gap this exposed in my own setup is probably in yours too. My fork thresholds gate on volume: more than five files, more than three state commands, fan out. Volume is easy to count and it is the wrong variable. Independence is what predicts whether the fan-out helps, and nothing in my rules measured it until this argument sent me looking.side quest

None of that is a graph problem. It is the same problem the loop had, wearing a new diagram.

The version that survives

The strongest form of this argument is better than the one going around, and it is not agents arranged in an org chart. It is making the control flow explicit and inspectable instead of leaving it implicit inside a prompt where nobody can review it. Ben Cochran, formerly a distinguished engineer at NVIDIA and AMD, built a system called Statewright on exactly that premise: constrain a small model with a formal state machine rather than reaching for a bigger model. Each state fixes which tools the model may touch, how many attempts it gets, and where it is allowed to go next.

That version is not multi-agent, so the inter-agent misalignment half of the Berkeley taxonomy does not reach it. The specification and verification failures still do. A graph of deterministic tool calls driving one model is a different animal from a swarm, and the skeptics quoted above are mostly describing swarms.

It answers every criticism in this piece. It is careful, it is grounded in forty years of prior art, and it is not what went viral.

The best statement of the difference came from an account with twelve likes, which is usually where the good lines are:

What to ask instead

You are not going to settle whether graphs beat loops, and you do not need to. The move that survives is the one that works on any architecture arriving with a name, a five layer diagram, and no benchmark.

Ask what result would have made this false, and ask who ran it. If the answer is a viral post and a study nobody can produce, that is the whole answer. The question costs nothing and it works on every wave, including the next one.

Two rules come out of this that hold up in a design review.

A graph earns its complexity only when the pieces are truly independent. If the parts need each other's answers, arranging them in a diagram does not make them parallel. It just makes the diagram.

And measure the loop you already have before restructuring it. Steps per completion, where it retries most, wall clock per completion, token cost per successful task. I run 90 skills, 27 agents and 48 scheduled jobs, and not one of them records those four numbers, which means every restructuring decision I have made was guesswork in a confident tone. Without them the graph-versus-loop question is not answerable for your own fleet at all, which makes the measurement the prerequisite for the entire argument rather than a footnote to it.

The harness is still the moat. What changed in three weeks was the vocabulary, not the engineering.

Related reading on this site: Three Sessions, One Company for what parallel actually costs once the coordination surface shows up on the boundaries nobody owns, Inside Anthropic's Multi-Agent Research SystemshippedAI Development & Agents·Jun 16, 2025Anthropic's Multi-Agent Research System: Engineering Autonomous Scientific DiscoveryDeep dive into Anthropic's engineering approach to building a multi-agent research system that autonomously conducts scientific research. for an orchestration write-up that does publish its failure modes, and The Control-Plane BetshippedAI Systems & Architecture·Jun 2, 2026The control plane bet: search and agents converging on code-as-actionPerplexity and Anthropic shipped different products in the same week and made the same architectural bet, treating the model as a control plane that writes code against an SDK rather than a tool caller in a loop. for the version of explicit control flow that ships as code rather than as a diagram.