Loops, Graphs, and Anchors

Peter Steinberger recently posted nine words that thousands of people recognized instantly: "Are we still talking loops or did we shift to graphs yet?" The joke landed because a whole field caught itself mid-stride, one foot on the pattern it was leaving and one on the pattern it was reaching for.

There is a problem hiding inside the joke. Three different conversations are using those same two words, about three different parts of a system, and they are not the same argument. People who agree they are moving from loops to graphs often mean completely different things. Sorting out which graph someone means is the fastest way to understand what is actually changing in how AI systems get built.

A loop is the simplest machine for getting something done or getting something right: do a thing, look at the result, adjust, go again. A graph is what you get when many loops are wired together, with structure in the connections: which one feeds which, which one watches which, which one can overrule which. That movement from a single cycle to a network of cycles is happening in three places at once.

The same shift is running at three layers of every AI system: how it decides, what it remembers, and how it improves. Each has its own loop, its own graph, and its own way of going wrong.

IMPROVEThe feedback graph: how the whole system gets better over weeks and quarters

KNOWThe knowledge graph: what the agent remembers across days and thousands of turns

DECIDEThe control graph: how the agent picks its next step, second by second

Graph one: how the agent decides

This is the layer the meme was about. An AI agent is a program that decides what to do next, and there are two ways to build that decision. In the graph approach, an engineer draws the steps in advance as boxes and arrows: fetch the data, then summarize, then if the score is low route here, otherwise route there. The path is fixed in code before the model runs. Frameworks such as LangGraph model this as a state machine, and their 2026 versions add durable execution, checkpointing, and pauses for human approval. Enterprises from Uber to LinkedIn run them in production.

In the loop approach, you hand the model a set of tools and one instruction: keep going until the task is done. The model calls a tool, reads the result, and picks its own next move every turn. No one drew the boxes. That is the entire engine behind coding agents like Claude Code, and Anthropic's public guidance argues for keeping it that simple.

Here the trend runs toward the loop, and the reason is worth stating plainly. A drawn graph encodes the assumptions of the engineer who drew it, on a task whose real shape keeps changing. Every case the world produces has to be a branch somebody anticipated. As models get better at reading a result and choosing sensibly, the hand-drawn control graph stops being structure and starts being a cage. Fixed, auditable processes still belong in a control graph. Open-ended work does not.

Graph two: what the agent knows

While engineers argued about control flow, the word graph quietly took on a second meaning, and this is where much of the current momentum sits. It is not the graph of steps. It is the graph of what the system knows.

A loop keeps its context in a flat window that fills up and forgets. To hold a task across days or thousands of turns, an agent needs memory it can query, update, and trust. The structure converging for that job is a knowledge graph: entities as nodes, relationships as edges, built and read by the model itself. Temporal versions such as Graphiti, the engine behind Zep, stamp every fact with both when it was true and when the system learned it, so a later contradiction updates the record instead of corrupting it. GraphRAG, from Microsoft Research, does the same across large document sets and reports solid gains on multi-hop questions that flat search fails.

So at this layer the graph is winning, and it is winning precisely where the loop was weakest. Put the first two layers together and the picture inverts the meme: the control graph is losing ground to the loop, while the knowledge graph is gaining ground underneath it. A modern agent is a loop that thinks wrapped around a graph that remembers.

Graph three: how the system improves

The third meaning is the oldest and the one that reaches furthest beyond AI. It is about how any system gets better over time, and it applies to a support team as much as to a model.

Consider a team that builds a feedback loop for its AI chatbot. They pick a metric, ticket resolution rate, measure it weekly, adjust prompts whenever it dips, and watch the line climb for five months. Then renewal data arrives 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 abandoned problems solved. The loop worked perfectly. Its success was the mechanism of the failure.

That is Goodhart's law, and the cause is structural rather than careless. A loop can see only its metric, so it finds every way to move that metric, including the ways that betray what the metric stood for. Single loops fail in four related ways: they game their own measure, they cannot ask whether the target itself is right, they collide with other loops that each look healthy alone, and their measurements quietly decay while the dashboard stays green.

Every one of those answers is a matter of wiring, which is why mature practice builds a graph here too. Machine-learning operations learned it incident by incident: a challenger model must beat the incumbent on live traffic, drift monitors watch whether today's data still resembles training data, rollback triggers on breached bounds, and a held-out evaluation set stays permanently hidden from the training loop so it can catch that loop gaming its own test. Well-run companies have the same anatomy: fast operational loops inside slower planning loops inside independent audit loops, with someone above all of it asking whether the targets still make sense. Pair every optimizing metric with a counter-metric. Give references an owner. Separate the speeds.

The failure that survives every graph

It would be easy to stop there and conclude that better topology is the cure. It is not, and this is the part the meme leaves out.

Picture an organization that builds the full graph: paired metrics, audit loops, meta-loops tuning the loops below. Every one of them consumes reports. The audit loop checks operations numbers against finance numbers, which come from the systems operations feeds, and the meta-loop tunes thresholds using dashboards built on all of it. Every loop watches another loop and no loop touches the ground. That network is circular. Everything is consistent and nothing is verified. It fails the same way the single loop failed, only later, more expensively, and with far more green lights on the way down.

UNGROUNDED

• Loops confirm other loops
• Every number traces to another number
• Consistent everywhere, verified nowhere
• Fails late, behind green dashboards

ANCHORED

• Some measures touch the world directly
• Frozen rules the optimizer cannot tune
• Independent checks, not paperwork
• Fails early, where it is still cheap

What a graph needs, and what no arrangement of edges can supply, is anchors. Some measurements have to be the kind nobody can argue with: money that landed in the bank, tests that actually executed, customers who actually stayed, a physical count that matches or does not. Some rules have to be frozen, off limits to the optimizing loops, precisely because they are the rules an optimizer would be tempted to weaken. This is the same instinct as the held-out test set the training loop is never allowed to see.

One thing has to come from outside the machinery entirely. Loops optimize toward targets and graphs revise targets, but the judgment of what is worth improving at all, and where the frozen rules should sit, cannot be produced by the network, because every loop in it already assumes that answer. People supply it, through contact with real failures. The most sophisticated systems are the ones honest enough to mark where their own authority ends.

What leaders should do

1. Make people say which graph they mean. When a team proposes moving from loops to graphs, ask whether they mean control flow, memory, or feedback. Three different budgets and three different risks hide behind the same sentence.
2. Move judgment into the loop and structure out of it. If a hand-drawn control graph is making decisions a strong model could make better, shrink that graph to the parts that must be deterministic: order, permissions, retries, and one writer for shared state.
3. Treat memory as its own project. Most long-horizon agent failures trace to what the system could not recall, not to a missing step. Evaluate a knowledge-graph memory layer such as Graphiti or GraphRAG before accepting that an agent simply forgets.
4. Give every optimizing metric a counter-metric and an owner. Resolution rate travels with renewal rate, speed travels with error rate, and someone senior owns the target itself rather than inheriting it.
5. Name your anchors and freeze them in writing. List the handful of measurements that touch reality directly and the rules no optimization may tune, then review that list when results look too good rather than when they look bad.

The safe prediction is that loop architecture becomes orthodoxy the way single loops did, with paired metrics and audit cycles as standard equipment. The deeper prediction follows from the pattern itself: graphs of loops will fail too, circularly and plausibly, wherever they get built without anchors. Then the conversation lurches toward whatever comes next.

Which suggests the durable question was never loops versus graphs. It is ungrounded versus grounded: whether the machinery, whatever its shape, keeps touching the reality it claims to improve. Whether its numbers settle against the world. Whether its watchers are genuinely independent. Whether its frozen rules stay frozen under pressure. And whether it admits that its deepest targets were chosen by people rather than computed by the system. The loop is how systems learned to get better. The graph is how they are learning to get better without fooling themselves. Staying honest about what better means is a different lesson than either, and it is the one that outlasts both.