Loops Built Your First Agent. Graphs Will Run Your Company.

The Founders’ AItrained on 25 years of our work

Want this made concrete for your company? Ask me — or pick one:

Do we need agent orchestration — loops or graphs? What should I do first? Take the 90-second readiness read

Ask

The week the builders argued about shapes

On July 18, Peter Steinberger — creator of OpenClaw, the open-source agent platform running on roughly half a million machines, who joined OpenAI in February to build agent and multi-agent systems — asked his feed a question that sounds like an inside joke:

Within days it was the argument of the week. Two days after the post, the project-management company Linear shipped a feature literally named Loops — recurring, autonomous agent workflows — which poured fuel on a debate it wasn’t actually part of. An older DeepLearning.AI course on knowledge graphs started circulating again as ammunition. Essays with titles like “From Loop Engineering to Graph Engineering” followed. By the weekend, the vocabulary had hardened into camps.

If you run a company rather than a codebase, your first instinct is the right one: this sounds like a developers’ quarrel about shapes. Here’s why we’re writing about it anyway. Underneath the jargon, the two shapes describe a decision your company is going to make this year — probably without noticing it’s being made. A loop is what you have when one AI agent does useful work. A graph is what you have the day your agents start depending on each other. You may never write a line of either. But the moment your one useful agent becomes five, you own the answer to this debate — and the research on what happens to companies that answer it accidentally is not comforting.

So this briefing does what we did for the five steps of AI adoption two weeks ago: take the engineering conversation seriously, translate it honestly, and then point at the part the engineers keep leaving out — the humans who have to hold the structure up.

Loops and graphs, in plain language

Start with the loop, because it’s the architecture you almost certainly already have.

In December 2024, Anthropic published a piece of engineering guidance that became the founding document of the loop era. Its core sentence: “Agents are typically just LLMs using tools based on environmental feedback in a loop.” Plain version: you give one AI a goal, access to tools, and a way to see the results of its own actions — and it plans, acts, checks, and repeats until the job is done or a human steps in. No org chart of AIs. One capable worker in a cycle. (Full disclosure, as always: we build on Claude, so the loop philosophy runs deep in our own systems — you should know that as you read our take on its limits.)

And here’s the detail that makes Steinberger’s July question so telling: he was the loop era’s loudest preacher just six weeks earlier. His June post became a rallying cry for exactly the philosophy we covered in the piece on loops replacing prompts:

When the person who taught the internet to build loops starts asking whether the world has moved to graphs, that’s not a trend piece. That’s the ladder’s own author noticing the next rung.

The loop’s superpower is that it lets you defer architecture. You don’t design a system; you hire a worker. One agent handles research, then drafting, then checking — until the day it can’t, and you spin up a second agent, and a third. That day is where the graph begins.

A graph, in this debate, means declared structure: multiple agents whose relationships are decided upfront. Who owns which task. What depends on what. What happens when a branch fails. Which agent checks which other agent’s work. The essayist Carlos E. Perez, whose “From Loop Engineering to Graph Engineering” became the debate’s intellectual spine, put the distinction in one line we’d frame on the office wall:

“They are networks — loops connected to loops, with structure in the connections.” The graph isn’t a replacement for the loop. It’s what honest loops become when there’s more than one of them.

Perez’s essay is worth an executive’s ten minutes because it’s really about improvement systems, not code. A single loop, he argues, fails in four characteristic ways: a metric optimized hard enough stops measuring what it once did (Goodhart’s law, wearing overalls); a loop can’t question its own target (“nothing inside the loop can ask whether the reference is right”); loops built independently fight each other; and the loop’s own measurement decays “with no loop watching the watcher.” His answer is structure: paired metrics, audit loops watching operational loops, hierarchy with a purpose. If that sounds less like software and more like how you’d design a management system — that’s exactly the point, and we’ll come back to it.

One honesty note before we go further, because precision is the house style: Linear’s “Loops” feature launching two days after Steinberger’s post was naming coincidence amplifying a debate, not a company taking an architectural side. The feature itself — describe a recurring job in plain language, let an agent run it on a schedule — is a loop in exactly Anthropic’s 2024 sense. The timing just made the vocabulary trend.

The debate is old. The deciders are new.

Now the critique you should hear before you buy any of this, because the sharpest person covering the debate made it well and it’s substantially correct.

Ksenia Se of Turing Post looked at the graph-engineering excitement and said the quiet part precisely: “None of this is new to software engineering. State machines, DAGs, workflow engines, and orchestration systems have been doing versions of it for decades.” She went further — mathematically, “a loop is already a graph. It is simply a graph whose path returns to an earlier node.” And she flagged something else worth respecting: a viral claim was already circulating that week attributing spectacular accuracy and cost numbers to graph adoption at major labs, and it was, in her words, simply not true. A debate five days old had already grown its own fabricated statistics. (We checked her receipts; she’s right on all counts. LangChain, to name one, has been shipping graph-based agent orchestration as a product for years — its founder was writing “how and when to build multi-agent systems” guidance a full thirteen months before this debate had a name.)

The practitioners’ replies wrote the critique in real time, too. LangChain’s founder Harrison Chase — whose company has sold graph orchestration for years — reacted with barely-contained amusement: “I didn’t really know what graph engineering is, and I still don’t really… but it’s basically just langgraph?” The creator of XState, a state-machine library, was drier still: “First it was loops. Now it’s graphs. Next month it’ll be something else.” And one analyst compressed the whole backlash into a sentence we’ll spare you the unedited version of: just type stuff and hit enter — it’s not that deep. (All as captured in coverage of the week’s threads.)

So is the whole thing vocabulary theater? About the words — largely yes. About the stakes — no, and here’s the distinction that matters for you.

When state machines and DAGs were the tools, the people making the defer-or-declare-structure decision were engineers, trained for it, inside systems that made the decision explicit. What changed is not the computer science. What changed is that AI made spinning up another agent so cheap that the structure decision migrated out of engineering — to the operations lead who added a second automation, the marketing manager whose assistant now feeds three other workflows, the founder who bolted a fifth agent onto four others one Friday afternoon. The decades-old decision is now being made by people who have never heard of a DAG, at companies with no architect on staff, one convenient agent at a time. The vocabulary is a rebrand. The population making the decision is genuinely new — and that’s you.

The graph moment

There’s a specific day this stops being abstract, and most companies can name it in hindsight.

It’s the day your assistant agent’s output becomes another agent’s input. The research agent feeds the drafting agent. The intake automation routes to the quoting agent, which triggers the follow-up agent. Nobody declared an architecture; the connections just accumulated, because each one made sense on the day it was added. Congratulations: you have a graph. You just never designed it.

Readers of our adoption-roadmap piece will recognize this as the Step 2-to-3 climb wearing different clothes: the transition where one person orchestrating a handful of agents becomes a system where agents hand work to agents — and where, as we argued then, the bottleneck stops being your attention and becomes trust and structure. The loops-vs-graphs debate is the engineering world discovering the same transition from its own side, and giving it a shape-name.

It’s also the sequel to something we wrote three weeks ago. In the piece on loops replacing prompts, we argued that the human job in the loop era is defining “good” — the quality bar the loop checks itself against. That job doesn’t go away at the graph moment. It multiplies, and it changes character: at loop scale you define good for the work; at graph scale you design the structure that keeps many definitions of good from quietly fighting each other. Perez’s third failure mode — independent loops undermining each other — is what “we automated a lot of things” feels like from the inside a year later. We named that condition before this debate had vocabulary for it: agent sprawl, where accumulation replaces architecture and every added agent makes the system less intelligible.

Why do multi-agent LLM systems fail?

Because this isn’t hypothetical, there’s now real research on exactly what goes wrong — and it’s the most useful reading in the whole debate.

In 2025, a UC Berkeley-led team (Cemri and colleagues, with systems heavyweights like Ion Stoica and Matei Zaharia on the author list) hand-annotated 150 execution traces from seven different multi-agent frameworks, checked their labels against each other rigorously, and released the first empirical taxonomy of multi-agent failure — fourteen distinct failure modes, since expanded into an open dataset of over 1,600 traces. The paper’s title is the question every graph owner eventually types into a search bar: “Why Do Multi-Agent LLM Systems Fail?”

The fourteen modes sort into three families, and every one of them will sound familiar to anyone who has ever managed people:

Two things about that list deserve a leader’s attention. First: none of the three families is a model problem. Smarter AI doesn’t fix a wrong org chart, a broken handoff, or an absent auditor — these are design failures, and design is a responsibility, not a feature you can buy. Second: the “graph camp” itself disagrees about the cure. Cognition’s advice from the trenches is to not build multi-agent systems for most work — one agent with full context beats a committee of partially-informed ones. Anthropic’s engineering team, having built a multi-agent research system that works, reports it excels precisely where work parallelizes cleanly — and costs roughly fifteen times the tokens of a chat interaction, which is why we’ve argued your architecture decisions are budget decisions in disguise. When the two most credible practitioners of the loop era disagree that visibly, the honest conclusion isn’t “one of them is wrong.” It’s that the answer is structural, situational — and yours to own.

The grounded graph

Which brings us to Perez’s deepest point, the one the engineering debate keeps stepping past — and the reason this article exists.

After making the case for graphs — loops watching loops, audits auditing audits — Perez turns around and names the failure mode of his own solution. A graph of mutually-checking loops can drift into what he calls circularity: a closed network of confirmations in which every part validates every other part and the whole thing slowly detaches from the world. His resolution: “The durable axis was never loops versus graphs at all. It is ungrounded versus grounded: whether the improvement machinery keeps touching reality.” And the ground, he insists, can’t be manufactured inside the graph: “Some measurements must be the kind that cannot be argued with.”

Read that again with your company in mind, because it’s the whole game. You can wire agents to check agents, add an audit loop, add a loop that audits the auditor — and at every level, the same question recurs: what does this structure ultimately touch that isn’t itself? In business terms: the customer who did or didn’t buy. The invoice that did or didn’t get paid. The claim a named human verified against the primary source. The moment when someone with calibrated judgment reads the output and says “this is wrong,” and the system has to listen.

That last one is the part we’d add to Perez, and it’s the same column we found missing from Cherny’s adoption map: the ground wire in a business graph is a human with preserved judgment and a designed place in the structure. Not a human rubber-stamping everything — that’s just a slow loop. A human positioned at the anchor points: owning the definitions of “good,” reading the exceptions, empowered to overrule the graph and be celebrated for it. This is what Humans First means at graph scale. The question who owns your AI adoption asked about the org chart, the graph now asks about the architecture: who audits the auditors — and does that person’s judgment still touch the actual work often enough to stay sharp?

The practical version of “anchors” has a name you’ve read here before: a standing evaluation harness — representative tasks, your quality bar encoded, run against the system on a schedule. When we wrote about testing a new model without switching, that harness was the cure for release-day anxiety. At graph scale it’s more: it’s the audit loop that answers to reality instead of to another agent, the closest thing a business graph has to Perez’s measurements-that-cannot-be-argued-with. Verification, it turns out, is the load-bearing wall of the whole agentic era — MAST’s data says its absence is how graphs die, and our experience says designing it is where the real work lives.

What to do at your size

The honest guidance, by where you actually are — because the worst outcome of this debate would be mid-market companies building graph bureaucracies they don’t need.

If you’re running zero or one real agent: stay in the loop, proudly. The loop is not the junior varsity version of the graph; it’s the correct architecture for this stage, and the discipline that matters is the one we described three weeks ago — defining “good” precisely enough that the loop can check itself. A single capable agent with a well-built skills library will outperform a premature committee of agents every time, and Cognition’s engineers would back you up. Deferring architecture is a feature. Defer it on purpose, though — know that the graph moment is ahead, and you’ll recognize it when it arrives.

If agents have started feeding agents: the graph exists — draw it. Not in software; on a whiteboard. Every agent and automation, every arrow of who-feeds-whom, and two annotations per node: who owns this, and what checks it. Most leadership teams who do this exercise discover connections nobody decided and at least one loop nobody is watching. That drawing is your real architecture, and every fix follows from seeing it: vague roles get owners (system-design failures), dropped handoffs get contracts (misalignment failures), and unwatched outputs get verification (the family MAST says kills graphs most quietly).

Wherever you are: install the anchors before you scale the graph. One honest evaluation harness on your most consequential workflow. One human whose overrule is structurally welcome. One metric per major loop that cannot be argued with. Then — and this is the discipline — grow the graph only as fast as the anchors grow. Anthropic’s fifteen-times token math is a useful brake here: every layer of structure you add costs real money to run, so structure has to earn its seat the same way headcount does.

Some of this is genuinely hard to do from inside — not because the drawing is complicated, but because the graph grew politically: every arrow on that whiteboard was somebody’s Friday-afternoon decision, and auditing it means auditing colleagues. Pattern recognition helps too; the failure shapes repeat across companies, and you only develop the eye by seeing many graphs. That’s the work of our AI agents and automation engagements — and whoever you’d bring in for it, apply our standing test: when the engagement ends, do your people own the map, the anchors, and the design decisions? If the answer is a retainer, keep looking.

Sources

• Carlos E. Perez — From Loop Engineering to Graph Engineering — Intuition Machine / Medium, July 2026
• Ksenia Se — Is Graph Engineering Real? Why Everyone Is Talking About It — Turing Post, July 20, 2026
• Cemri et al. — Why Do Multi-Agent LLM Systems Fail? — arXiv 2503.13657, UC Berkeley and collaborators, 2025 (MAST taxonomy: 14 failure modes, 3 categories, 150 annotated traces)
• Anthropic — Building Effective Agents — December 19, 2024 (“agents are typically just LLMs using tools based on environmental feedback in a loop”)
• Anthropic — How we built our multi-agent research system — June 13, 2025 (multi-agent ≈15× chat tokens; where multi-agent excels and doesn’t)
• Walden Yan / Cognition — Don’t Build Multi-Agents — June 12, 2025
• Harrison Chase / LangChain — How and when to build multi-agent systems — June 16, 2025
• Linear — Introducing Loops — changelog, July 20, 2026
• explainx.ai — Graphs vs. Loops: the agentic AI orchestration debate — July 21, 2026 (Steinberger post as captured in coverage)
• Chris Lema — What “Loops to Graphs” Looks Like in Production — July 20, 2026
• DeepLearning.AI — Knowledge Graphs for RAG — the course the debate pointed to
• a16z — How 100 Enterprise CIOs Are Building and Buying Gen AI — June 2025

Frequently Asked Questions