循环工程之后：从信任循环到可验证图结构

An agent ran for an hour, reported SUCCESS, and shipped the wrong number. It did not crash. It did not warn anyone. It did exactly what you built it to do: keep going.

That gap, between a loop that keeps going and a loop you can trust, is what this article is about. For a year we have gotten very good at the first half, and barely asked the second.

So here is the plan. First we grant the loop everything, because it earned it. Then we walk the four walls every loop hits, the four things it structurally cannot do, each one proven with a real number.

Then we build the four properties that fill those walls, the thing people call a graph or a harness. We run ninety lines of real code and watch a loop and a graph reach different answers on the same task. And at the end, the twist: the frontier already moved, and it is not what the hype is selling.

I'm Phosphen. I write long-form breakdowns of how the best labs actually build the systems you use. Every number here is checked, and every line of code runs, so you can reproduce it to the digit.

Let's begin.

Look at the picture above, because it is the whole argument in miniature. On the left, the loop circles back on itself and hands you 747, stamped SUCCESS, which is wrong by 132.

On the right, the same work runs through a verify gate before anything counts, and it returns exactly 615. Same task, same tool. The only thing that changed is the structure around the model. Hold that contrast in your head; everything below is a slower version of it.

Before we take the loop apart, let's give it its due, because it earned every bit of the hype.

Start with what a loop actually is. Anthropic wrote the cleanest definition: an agent is a model using tools in a loop. Picture it. There is an environment, some tools, a system prompt, and then the model gets called again and again, and each time it decides what to do next. That last part, the model doing the deciding, is the whole magic. It is also, as you are about to see, the whole problem: the moment the deciding moves inside an opaque model call, you get autonomy and unaccountability in the same box. It can do almost anything, and it cannot tell you why it did.

Notice that the people who built the loop already knew this. ReAct bolted a thinking step onto it. Reflexion bolted on the first rough versions of everything this article is about: a checker, a memory of past failures, a retry limit. And it worked: 91% on a coding benchmark where GPT-4 sat at 80.

But read the fine print and the cracks are already there. Reflexion's memory holds only a handful of items, and its own self-written tests wave a wrong answer through about one time in six. The walls we are about to walk were poured on the very first day.

A loop is a control-flow primitive, not an architecture. Every account selling you "just add a loop" stops the sentence one clause early.

Here is the mistake almost everyone makes first, and you have probably made it too. The long runs fall over, so you reach for a smarter model. Before you do, look at what the measurements actually say.

StaminaBench ran coding agents over a hundred turns and found three things, all measured, not guessed. Every model tested fails within five or six turns. Just letting the agent retry on test feedback stretches how long it survives by up to 12x. And a single strong model swings up to 6x between its best and worst harness.

Sit with that last number for a second. The weights are frozen. The model is identical. And the result still moves by an order of magnitude, on nothing but the wrapper you put around it. A second study, this one across 200,000 conversations, said it plainly: going from one turn to many costs you a little skill and a lot of reliability, and once a model takes a wrong turn, it usually never finds its way back.

If a fixed model swings sixfold on the wrapper, the wrapper is the product.

Now the diagnosis. Every failure a loop cannot fix comes down to one of four walls. Look at them together first, then we take them one at a time.

Notice what they share: not one is a thing a bigger model solves. That is the whole point. Here they are, up close.

Wall one, the plan lives in a window that rots.

You will recognize this one. You tell the agent to run the tests only after it edits the code, a simple rule. Eighty turns later it runs them first, on stale code, and reports green. What went wrong? That rule, "B after A," only ever existed as a sentence in the context window, and the model had to keep remembering it. But that window is rotting as it fills: Chroma tested 18 models across 194,480 calls, and every one degrades as the input grows. Here is the part that stings: the instruction file is sitting right there in the folder the entire run. The loop just stops reading it.

If the only thing enforcing the order is the model remembering, that is not a dependency, it is a wish.

Wall two, it spins and cannot tell hard from impossible.

Picture the run an hour in, the token meter climbing, and the agent issuing the same call with the same arguments for the fortieth time. Nothing tells it to stop, because nothing bounds the retries. And it gets worse than wasted money: in StaminaBench, one harness's own loop-detector fired, poisoned the shared session, and took down 13 of 20 scenarios for one model.

The loop cannot tell a hard node from an impossible one, so it treats them the same way: try again.

Wall three, the checker is a vote the maker wins.

Watch this failure closely, because it is the quietest. The agent writes the code, writes the tests, the tests pass, and the code is wrong. How? Because verification lives in the same transcript the maker controls, so a wrong-but-plausible answer just gets added in without a fight. And you cannot escape it by buying a smarter model, because reliability multiplies against you. Look at the math:

Read those the slow way. An 85%-reliable step, run ten times, is not a 10% problem, it is a 20% one. Real steps are not even independent, so the truth is worse than the table. You cannot out-scale that curve. You out-architect it: shorter chains, and a check the maker cannot write.

Wall four, when it is wrong you cannot replay it.

Last wall, and it is the one that bites a week later. The agent merged the change on Tuesday, it broke on Friday, and the plan it followed is gone, flushed with the context. You had rubber-stamped the merge, because the transcript was too long to read and already deleted.

If you cannot point at the exact plan that governed the exact action, you did not run a process, you ran a rumor.

Take a breath, because here is the reframe that makes the rest simple. A 2026 paper looks at the agent loop and calls it a single-ready-unit scheduler. In plain words: at any moment, only one thing can run, and an opaque model call picks which one. The scheduler's whole policy is the model, a black box.

Once you see it that way, the fix stops being "a smarter box" and becomes "a better rung." Watch the ladder climb: naive loop, parallel loop, planner loop, structured loop, graph harness.

Follow it left to right. You can bolt a planner on, then a critic, then a memory, and each one makes the policy a little more visible. But look at the label under each box: one thing ready at a time, the whole way up. Only the last rung, the graph, changes that, and lets more than one unit be ready, scheduled, and checked at once.

What comes after the loop is not a leap. It is the next rung.

Now we build. And the nice part is you already know the shape, because each property answers exactly one wall. Here is the whole map on a single card:

Read it as four promises, left to right, and let me walk you through each.

Explicit dependencies fill wall one. Instead of leaving the plan as a sentence in the window, you lift it into a static graph, so what-runs-next is read off the graph's shape, not remembered. Does it actually help? Yes, and there is one hard number: a Neo4j paper compiled prose "skills" into a typed graph and pulled a Claude Sonnet model from 53% to 67% on a public benchmark. Because each node was addressable, they fixed one node and took a broken demo from 0-of-5 to 5-of-5 with nothing else breaking.

Can you name the node this one waited on, without asking the model? If not, it is not explicit.

Bounded recovery fills wall two. You replace "retry, skip, or replan, the model's call" with a fixed staircase: retry the node, then patch its config, then ask for a new plan, and you cannot skip a step. Because the budget is finite, the run provably ends, it cannot spin forever. And this is not a whiteboard idea: Temporal raised $300M at a $5B valuation selling exactly this.

A real recovery says "I tried this node five times and stopped, here is the input that beat it." A loop only says "still going."

An immutable log fills wall four. You freeze the plan per version and write every action to an append-only record you can replay and point at later. Temporal does this today: crash a run and it replays the log and resumes at step 48, not step 1. The program you are about to run keeps a hash-chained log, and if you flip one committed value, re-verification returns false and tells on you.

Can you point at the exact node that said yes, a week from now? If not, "immutable" was just a word.

A verifier gate fills wall three. You make the checker a node the output has to pass through to count, not a message the maker can talk past. But here is the honest part, the part a thinker says and an aggregator skips: verification is not free. Your correctness is only as good as your validators, and a model judging a model can be fooled. So this is the right direction, not a magic wand.

If the maker can talk the checker out of it, it was never a gate.

Enough claims. Let's run it and watch, because this is the part you can check yourself.

The task is deliberately dull: ask a flaky tool for the square root of every number from 1 to 99, then add them up. The true total is 615. We wrap the exact same tool, with the exact same seed, first in a loop and then in a graph, and change nothing else.

Look at the loop's answer first: 747. It is wrong by 132, a 21% error, and, worst of all, it reports SUCCESS. Now let me show you why, because it is not bad luck, it is the loop's shape. Two bugs: 18 values got double-counted, because the running total is mutable state that a half-finished step corrupted, and 14 corrupted outputs got waved through, because nothing was checking them.

Now the graph, same task: exactly 615. It caught and rejected 12 corrupted outputs at the gate, shrugged off 51 tool errors, and got there in fewer calls than the loop spent being wrong. Turn the flakiness up and the gap gets louder: the loop grinds to a confident, wrong 776, still SUCCESS, while the graph tries one impossible node five times, then stops cleanly and names the exact input that beat it.

Here are the two cores and the real output. Read the comments; they point at each bug the moment it happens.

# THE NAIVE LOOP  ·  implicit deps, one mutable total, no verifier, no real bound
def naive_loop(seed=7, p_fail=0.25, p_corrupt=0.08):
    total, i = 0, 0                  # mutable state + an implicit "where am I" pointer
    while i < len(N):
        n = N[i]
        try:
            x = tool(n)              # ask the flaky tool
        except ToolError:
            continue                 # retry the same record, unbounded
        total += x                   # mutate BEFORE the step is durable...
        try:
            _persist(seed, i)        # a second flaky action, after the mutate
        except ToolError:
            continue                 # ...the retry re-adds x  ->  DOUBLE COUNT
        i += 1                       # only now advance
    return total                 # 747, stamped SUCCESS, and wrong by 132

# THE GRAPH HARNESS  ·  bounded retries, a verifier gate, an append-only hash-chained log
def run_node(self, name, fn, verify_fn, inputs):
    for attempt in range(1, self.max_attempts + 1):
        try:
            out = fn(inputs)
        except ToolError as e:
            self._append(name, attempt, "TOOL_ERROR"); continue  # logged, then retry
        if not verify_fn(inputs, out):       # the gate the maker can't skip
            self._append(name, attempt, "VERIFY_FAIL"); continue  # corruption rejected
        self._append(name, attempt, "OK"); return out
    self._append(name, attempt, "ABORT")             # bounded: fail loud, never hang
    raise NodeAborted(f"{name} exhausted {self.max_attempts} attempts on {inputs}")

TASK: sum(floor(sqrt(n)) for n in 1..99)   GROUND TRUTH = 615

SCENARIO A  ·  moderate flakiness  (p_fail=0.25, p_corrupt=0.08)
NAIVE LOOP    -> {'answer': 747, 'correct': False, 'reported': 'SUCCESS', 'tool_calls': 169}
   +132, reported SUCCESS.  cause: 18 double-counts (mutable state)
                                 + 14 corrupted values accepted (no verifier)
GRAPH HARNESS -> {'answer': 615, 'correct': True,  'reported': 'SUCCESS', 'tool_calls': 162}
   immutable log verifiable: True.  rejected 12 corrupted outputs; absorbed 51 tool errors
   chain head: 6e133d166388

SCENARIO B  ·  severe flakiness  (p_fail=0.45)
NAIVE LOOP    -> {'answer': 776, 'correct': False, 'reported': 'SUCCESS'}  +161, still SUCCESS
GRAPH HARNESS -> ABORTED: isqrt[50] exhausted 5 attempts  (89 calls, then it stops)

Count the lines: the loop is about 30, the harness about 46. That 16-line difference is the entire price of the four guarantees. And swapping the seeded stub for a real model call is a one-line change, which is the whole thesis in one sentence: the model is just a node, and the engineering that comes after the loop is the graph around it.

Here is the part most of the loop talk misses, and it is a report, not a prediction. This year, three major agent frameworks quietly converged on graph execution. The most-starred one is graph-first by design, with checkpointing and rollback built in. Google's and Microsoft's both moved to explicit workflow graphs. And a $5B company sells the audit pillar on its own.

But the sharpest evidence is the frontier's own answer, so look closely. Anthropic's dynamic workflows have Claude write its own harness for each task, a small JavaScript file that spawns and coordinates subagents, with named patterns built to beat named failure modes. Read that again. The loop is not dead. It got promoted to the thing that draws the graph.

Keep the graph that stores what happened. Let the model draw the graph of what to do.

Before you go build one, let me argue against myself, because a piece with no opposition is just propaganda. Eric Xing draws a line between systems whose skill lives in the harness and ones whose skill lives in the model, and argues most of today's are the first kind. The Codex camp goes further: heavy scaffolding is coping, not scaling, and a better model just dissolves it.

They have a real point, and it is worth conceding cleanly: a hand-drawn reasoning graph is exactly the kind of thing the bitter lesson erases, which is precisely why the frontier answer hands the drawing to the model, not to a human. But separate two things they blur. Durable state, an immutable log, and a verifier are infrastructure, not reasoning, and even the minimalists run them.

And the brake you actually need, because it is part of the thesis and not a hedge: most people shipping loops today do not need a graph yet, and the accounts selling you one will not tell you that.

Before the close, keep this. It is the whole diagnosis on one card, and each line names the property that fixes it. Save it, and the next time an agent burns you, find your failure here.

Remember the agent from the very first line, the one that ran for an hour and reported SUCCESS on a wrong answer? It is still out there, running in a thousand repos right now. Whether it keeps going was never the question. The loop solved that a year ago. The question is whether, when it hands you a green check at nine in the morning, you are right to believe it.

Here is the part that should stay with you. Two people can build the exact same loop and end up in opposite places. One wraps it around work they understand to the bone and moves ten times faster. The other wraps it around work they have quietly stopped reading, and turns, one merge at a time, into a rubber stamp for a machine. Same loop. It cannot tell the two of them apart. Only you can.

So do not try to build the whole graph tonight, and do not feel behind if you never do, because most loops genuinely do not need one yet. Just pick the one wall that actually cost you this week. The runaway bill. The wrong number that shipped green. The merge you approved without reading. Put the single property that closes that one wall around the loop you already have. One wall, tonight.

The loop taught your agent to keep going. Everything after the loop exists so that you, not the loop, get to decide what counts.

A year ago, the edge belonged to whoever could write the best loop. It is already shifting to whoever can trust what their loops did while they slept. The loop you are proudest of should be able to tell you, a week from now, exactly why it said yes. Go build the part that can.