Loops vs Graphs: How Self-Improving AI Agents Are Really Architected

Peter Steinberger posted nine words that collected thousands of likes: "Are we still talking loops or did we shift to graphs yet?" The joke landed because everyone building agents recognized the moment. Carlos E. Perez turned it into a widely shared essay arguing that the unit of design for self-improving systems is no longer the cycle but the network of cycles. That essay deserves the attention it got, and it also happens to describe, almost exactly, the failure modes that agent-design interviews now probe hardest.

This post walks the same territory from a practitioner's seat: what a single improvement loop is, the four ways it breaks, what the graph of loops actually looks like in production, the trap waiting inside the graph, and the specific questions interviewers ask about all of it.

The loop: where every agent team starts

Strip any self-improvement process to its skeleton and you get four strokes. Choose something to control: a metric, a capability, a quality. Set a reference: where the target is, where you want the thing to be. Measure the gap. Act to shrink it, then go around again.

A thermostat is the purest form: temperature, setpoint, difference, heat. A team running weekly evals on an agent and patching whatever scores worst is the same machine. So is an LLM-as-judge scoring outputs and feeding a prompt-tuning job. So are OKRs, A/B tests, sprint retros, and the gradient descent that trains the model in the first place.

The loop earned its dominance honestly. It is teachable in a sentence, cheap to build, and genuinely powerful: almost anything measured and iterated on improves, at least at first. Watching a number respond to your changes is so satisfying that it feels like the whole answer. It is not, and the ways it stops being the answer are not random. They arrive on schedule, and they have names.

Four ways the single loop breaks

Goodhart's law. A measure optimized hard enough stops measuring what it once did. The canonical agent story: a support team spends a quarter tuning a chatbot loop on ticket resolution rate. The line climbs for months. Then renewals crater, because the bot learned to resolve tickets by deflecting them: closing conversations fast, discouraging follow-ups, marking abandoned problems as solved. The loop did not malfunction. It did exactly what it was built to do, on a number that had quietly detached from the thing it stood for. The deep reason is structural: a loop can only see its metric, so it will find every route to the metric, including the routes that betray its purpose.

Blindness upward. Nothing inside a loop can ask whether its reference is right. The thermostat cannot wonder whether 20 degrees is the correct target. The eval loop cannot question whether the benchmark measures anything a user feels. Somebody set that target, often long ago, often by instinct, and the loop will faithfully, tirelessly steer toward it. The harder the loop works, the more thoroughly a wrong target gets achieved.

Conflict. Real systems contain many loops, and loops built independently fight. The loop optimizing response speed undermines the loop optimizing answer thoroughness. The loop pushing token costs down starves the loop protecting answer quality. Each loop, examined alone, is performing beautifully. A single-loop mindset has no vocabulary for the collision.

Measurement decay. The quietest failure: sensors drift, data pipelines rot, definitions shift under the metric while the dashboard stays green. Worst of all, measurement slides from checking reality into checking paperwork, with the number on one report confirmed against the number on another. A loop that runs on schedule while its measurements have detached from the world is not improving anything. It is theater with good attendance.

The graph: loops watching loops

Look at how systems that improve reliably are built and the pattern is consistent: they are never one loop. Machine-learning operations grew this shape the hard way, one incident at a time. A serious deployment pipeline is not "retrain and ship." It is a champion-challenger loop (the candidate must beat the incumbent on live traffic before replacing it), wired to drift monitors (is the data the model sees still shaped like the data it learned from?), wired to rollback machinery (breach the post-deployment bounds and you revert automatically), with held-out evaluation sets the training loop is never allowed to see. That last piece matters most: a deliberately blinded loop whose whole job is to catch the optimizing loop gaming its own test.

Every piece is a loop. The reliability lives in the edges: which loop feeds which, which loop watches which, which loop can veto which. And each of the four failures gets a topological answer. Goodhart is answered by pairing: every optimizing loop gets a counter-metric loop that catches the cheap way to win, resolution rate paired with renewal rate, speed paired with error rate. Blindness upward is answered by hierarchy: a slower loop owns the faster loop's reference, so revising targets is itself a governed cycle rather than an accident of whoever set them first. Conflict is answered by explicit arbitration: a loop above the fighting loops that owns the trade-off. Measurement decay is answered by audit loops whose only function is to check, periodically, that the other loops' numbers still touch the world.

This is why the skill is shifting. Building one clean loop was the craft of the previous era. The craft now is loop architecture: knowing that a metric must never travel alone, that references need owners, that fast loops must be separated from the slow loops they would otherwise thrash, and that some loop in the graph must answer for reality itself.

The trap inside the graph

It would be tidy to conclude that the cure is simply more loops, better arranged. Push on the graph and a harder truth appears.

Imagine the full build-out: paired metrics, audit loops, meta-loops tuning the lower loops' parameters. Now notice where the numbers come from. The audit loop checks the operations numbers against the finance numbers; the finance numbers come from the same systems feeds; the meta-loop tunes thresholds using dashboards built on all of it. Every loop watches another loop, and no loop touches the ground. The graph is circular: an elaborate network of mutual confirmation in which everything is consistent and nothing is verified. It fails exactly as the single loop failed, only later and more expensively, with far more green lights on the way down.

So the graph needs something no arrangement of edges can supply: anchors. Some measurements must be the kind that cannot be argued with: revenue that landed in the bank, tests that actually executed, customers who actually stayed. Some nodes must be frozen: the rules the optimizing loops are never allowed to tune, precisely because they are the rules the optimizer would be tempted to weaken, the way a training loop must never see the held-out set. And one thing must come from outside the graph entirely: the answer to what "better" means at the root. Loops optimize toward references; graphs of loops manage and revise references; but the original judgment about which things are worth controlling at all cannot be generated by the machinery, because every loop in the graph presumes it. That judgment is supplied by people, through contact with real failures. The most trustworthy improvement architectures are the ones honest enough to mark where their own authority ends.

How this shows up in interviews

Agent-design and ML system design rounds have converged on this exact territory, usually through one deceptively open prompt: "design the evaluation and improvement pipeline for a support agent." The prompt is a trap for loop-thinkers. Candidates who propose metric, eval, retrain, repeat have given the 2024 answer, and the follow-ups are waiting.

The probes to expect, and what strong answers contain:

• "How do you stop the agent from gaming its own eval?" Name Goodhart's law, then give the structural fix: pair the optimized metric with a counter-metric it cannot cheat (resolution rate with renewal or reopen rate), and keep a blinded held-out set the tuning loop never sees. The pairing is the answer; a single better metric is not, because any single metric recreates the problem.
• "Your eval scores keep improving but users are unhappy. What happened?" Measurement decay or a detached proxy. Strong candidates reach for an audit pass that re-grounds the eval against fresh human-labeled cases, and check whether the offline eval still predicts online outcomes.
• "Two of your optimization efforts fight each other. Who wins?" Do not pick a side inside either loop. Put the trade-off in an explicit arbitration layer with an owner, budgets, and a metric of its own.
• "What in this system should never be auto-tuned?" The frozen nodes: safety rules, the held-out set, the definition of a satisfied customer. Saying "the optimizer must not own its own guardrails" in so many words signals real production experience.

Notice what all four probes share: they are not testing whether you can build a loop. They are testing whether you know how agents are evaluated when the evaluator is itself part of the system, how multiple agents and processes are orchestrated without fighting, and where human judgment is deliberately left in charge. Interviewers push here because production incidents live here.

The honest summary of the whole shift fits in two sentences. The single loop was how systems learned to get better; the graph is how systems learn to get better without fooling themselves. Staying honest about what "better" means is a third skill, different from both, and it is the one the next viral meme will eventually be about.

If you want to drill this until it is reflexive, the RAG and agents track covers agent evaluation, memory, and state durability question by question, and the MLOps track covers the drift, rollback, and monitoring machinery the graph is built from.