“Are we still talking loops or did we shift to graphs yet?” The joke needs no explanation to anyone building agents, which is exactly why it landed: a whole field caught itself mid-stride, one foot on the pattern it was leaving and one on the pattern it was reaching for. But the meme flattens two different crafts into a costume change, and I want to pull them apart — because loop engineering and graph engineering are not fashions that replace each other. They are two answers to the same question, and the question is older and harder than either.
The question is this: how does anything get better without fooling itself?
Swipe or scroll sideways to flip through the 15-slide deck →
The loop is the atom of getting better
Strip any improvement process to the bone and you find the same four-stroke engine: choose something to control, set a reference for where you want it, measure the gap, act to shrink it, and go around again. A thermostat is the purest form — temperature, setpoint, difference, heat. So is a team running weekly evals and tuning whatever scores worst. So is weighing yourself each morning. The loop earns its dominance: simple enough to teach in a sentence, cheap to build, and genuinely powerful. Almost anything measured and iterated on improves, at least at first.
What loop engineering actually is
Think about a compiler. We describe it by what it makes — source into something runnable — but to the person using it, a compiler is a thing that refuses to let you be wrong in a particular way. Write a type mismatch and it stops you cold. You cannot sweet-talk it, you cannot rephrase the mistake until it relents, and its verdict is public: run the same code on another machine, same answer. A compiler is three things welded together — something that pushes back when you err, something that cannot be argued out of its judgment, and a verdict that is public and repeatable.
Programming gets all three free, bundled with the language. That is the quiet reason coding agents work as well as they do — not because the models are sharper at code than at prose, but because code is the rare domain where reality checks the work for you, every time you hit run. Loop engineering is what you do when that gift is absent. It is the work of noticing a task has no compiler and building the closest thing you can: the tests that push back, the independent reviewer who did not write the work, the audit trail anyone can check. Good loop engineering is those three rebuilt by hand. Bad loop engineering is an agent talking to itself — a compiler with the resistance, the independence, and the public verdict all quietly removed.
Where a single loop breaks
One good loop is a real skill, and it fails on schedule, in four ways that are all consequences of its shape. A loop can only see its metric, so it will find every way to move that metric — including the ways that betray its purpose. A support team optimizes ticket resolution rate for five months, watches the line climb, and then renewals crater: the bot learned to “resolve” tickets by deflecting them, closing conversations fast and marking abandoned problems solved. The loop worked flawlessly; that was the problem. That is Goodhart’s law, and it is structural, not a bug. A loop also cannot ask whether its reference is right — the thermostat cannot wonder whether sixty-eight degrees is correct. Loops built independently fight — the speed loop undermines the thoroughness loop. And the loop’s own measurement quietly rots while the dashboard stays green.
The graph is the wiring
Graph engineering is the answer to those four failures, and the crucial thing is where the answer lives: in the edges. Look at any mature system and it is never one loop; it is a network of loops that watch, feed, constrain, and correct one another. A serious deployment pipeline pairs a champion-challenger loop with drift monitors, rollback machinery, and a held-out evaluation set the training loop is never allowed to see — a deliberately blinded loop whose whole job is catching the optimizing loop cheating on its own test. A well-run company is the same shape: fast operational loops inside slower planning loops inside an independent audit loop inside a board asking whether the targets themselves are still the right targets.
The failures get topological answers. Goodhart is answered by pairing — resolution rate gets renewal rate riding shotgun; speed gets error rate. Blindness upward is answered by hierarchy — a slower loop owns the faster loop’s target. Conflict is answered by arbitration — a loop above the fighting loops that owns the trade-off. Decay is answered by audit loops whose only job is checking that the other loops’ numbers still touch the world.
So here is the difference, plainly. Loop engineering builds a single honest verifier where the domain gave you none. Graph engineering wires verifiers together so no metric travels alone and no watcher grades its own work. The loop is the node; the graph is the wiring. One craft manufactures resistance; the other arranges it.
The trap: everything consistent, nothing verified
Here is the part the meme leaves out. More loops, better arranged, is not the cure. Imagine a company that builds the full graph — paired metrics, audit loops, meta-loops tuning the lower loops — where every loop consumes reports and no loop touches the ground. The audit loop checks operations numbers against finance numbers drawn from the same systems; the meta-loop tunes thresholds off dashboards built on all of it. That graph is circular: an elaborate mutual-confirmation machine where everything is consistent and nothing is verified. It fails exactly as the single loop failed — only later, more expensively, with far more green lights on the way down.
The same rot has a name inside loop engineering: independence is the property that is easy to fake. Reach for a second agent to review the first and you have built a checker that emits crisp pass/fail verdicts but lives in the same kind of head as the worker, so the two agree, confidently and silently, on the same blind spot. A verdict from something that shares your framing is theater dressed as verification. A thing can be shaped exactly like a compiler — same inputs, same crisp outputs — and still not be one, because the property that made the compiler trustworthy was the invisible one, and the invisible one is the first to go.
Grounded versus ungrounded
Which is why the durable axis was never loops versus graphs. It is grounded versus ungrounded — whether the machinery, whatever its shape, keeps touching the reality it claims to improve. Graphs need anchors no arrangement of edges can supply: measurements that cannot be argued with (money that landed in the bank, tests that actually ran, customers who actually stayed), frozen rules the optimizer is never allowed to tune, and — from outside the machinery entirely — a human answer to what “better” even means. Keep climbing the ladder of verifiers and you reach claims like “is this the wise strategy” and “is this even the right question,” where there is no external referent left to compile against at all. The tower has a top floor.
Build your loops. Then build the graph. But mark the place where your own authority ends, because the most sophisticated improvement architecture in the world will still fool itself — consistently, plausibly, with the dashboard glowing green — if nothing in it is allowed to say no and mean it.