Loop Engineering, Graph Engineering, and the Convenient Discovery That More Inference Is the Future

The AI industry has discovered a remarkable method for producing new engineering disciplines.

Take an old idea. Attach it to a language model. Give it a diagram. Announce that the previous discipline is dead.

Prompt engineering became context engineering. Context engineering became agent engineering. Agent engineering became loop engineering. Loop engineering has now become graph engineering.

‍

At the present rate, we should reach hypergraph engineering by Thursday, followed by category-theoretic agent governance just before the weekend.

Underneath the naming ceremony, however, there is a serious question.

Are loop engineering and graph engineering actually better ways to build AI systems? Or have employees of companies that sell tokens discovered that the future of software involves calling their products repeatedly, in parallel, until another call to their product declares the work complete?

The uncomfortable answer is: both.

There is real engineering here. But it is narrower, older, and considerably less magical than the slogans suggest.

Follow the tokens

There is one fact the loop discourse tends to place just outside the context window.

Peter Steinberger joined OpenAI in February 2026. Boris Cherny is the inventor and Head of Claude Code at Anthropic.

They are not neutral observers who encountered these products in the forest.

They build them.

This gives them unusually deep practical knowledge. It also gives them an unusually obvious conflict of interest.

OpenAI now maps Codex credits directly to token consumption. Anthropic’s API is similarly priced by input and output tokens. On usage-priced services, a prompt calls the model once. A loop calls it repeatedly. A graph calls several models, asks other models to review them, and may then send the result back around the graph for further reflection.

The people selling electricity have discovered that the future is leaving the lights on.

This does not prove conspiracy or cynical intent. Vendors pay for inference too, and wasteful systems damage their margins and products. Peter and Boris are clearly exploring real changes in how software gets built.

It does mean their recommendations should be read as vendor-affiliated case studies, not as neutral evidence of universal best practice.

Peter’s original slogan was:

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

Boris made almost the same transition:

“I don’t prompt Claude anymore. My job is to write loops.”

The phrase describes a genuine change in abstraction. Instead of telling an agent what to do next, the human builds a system that decides what the agent should do next.

But it also describes a change in billing topology.

The million-dollar meal plan

Peter’s workflow is an extreme but revealing example.

His team reportedly operated around one hundred Codex instances that consumed 603 billion tokens across 7.6 million requests in thirty days. The dashboard showed roughly $1.3 million in fast-mode API-equivalent usage; Peter said ordinary-speed pricing would have brought that closer to $300,000. OpenAI covered the experiment, which he described as exploring development without budget constraints. The reported figures are here.

That is a legitimate research laboratory.

It is not yet a transferable small-team practice unless the small team is employed by the power station.

Peter’s earlier writing was, interestingly, more restrained than the later mythology. In his detailed account of shipping at inference speed, he described running three to eight projects, keeping durable documentation, giving agents tools with which to inspect their own results, and escalating difficult problems to stronger models.

He also said he saw little need for elaborate multi-agent orchestration because he remained the bottleneck. He preferred an iterative process in which he could see, touch, and redirect the work.

That caveat matters. It suggests that the transferable lesson was never “launch one hundred agents.” It was closer to “give a capable agent good context, real tools, and a way to verify its work.”

Boris’s examples are similarly interesting but not controlled experiments. His scheduled loops watch pull requests, process feedback, search for architectural improvements, and look for abstractions that might be unified. These may be valuable inside a mature codebase with strong tests, expert reviewers, and an unusually capable operator.

We do not know the counterfactual: how many suggestions were rejected, how many review hours were required, how much maintenance the generated code created, or whether a linter, script, single agent, or occasional human review would have produced the same accepted outcomes for less money.

“It works for the person who invented the product” is evidence.

It is simply a lower tier of evidence than the product’s marketing language tends to imply.

Two different things called a loop

Part of the confusion is that loop engineering refers to two different structures.

The first is an execution loop:

1. Give the model a goal.
2. Let it act.
3. Observe the result.
4. Feed the result back.
5. Repeat until it claims completion.

The second is an improvement or control loop:

1. Choose a variable to control.
2. Set a target or reference.
3. Measure the gap between reality and the target.
4. Apply a corrective action.
5. Measure again.

The first keeps an agent working.

The second makes a system improve.

They overlap only when the agent receives evidence that actually corresponds to the desired outcome. Repeating a model call is not automatically learning. Motion is not improvement, and a longer trajectory is not a more intelligent one.

The recent loop-engineering paper makes this distinction usefully. It defines a loop specification as a bounded artifact containing a trigger, goal, verification step, stopping rule, memory, and named terminal states.

That is a sensible definition.

But the paper’s fifty-loop corpus is descriptive. It shows what practitioners are building; it does not establish that those loops outperform cheaper alternatives, improve productivity, or produce better software after review and maintenance costs are counted.

A collection of practices is not yet proof of best practice.

The token furnace test

Anthropic is unusually candid about how multi-agent systems obtain some of their gains.

Its research system reportedly beat a single-agent configuration by 90.2 percent on a private internal evaluation. But the company also found that token usage alone explained 80 percent of performance variance on BrowseComp. Agents consumed roughly four times as many tokens as chat, while the multi-agent system consumed about fifteen times as many.

Anthropic summarizes the mechanism rather directly:

“Multi-agent systems work mainly because they help spend enough tokens to solve the problem.”

It also says the economics work only for sufficiently valuable tasks, and that most coding tasks are a poor fit because they contain fewer independent branches and tighter coordination dependencies. Those qualifications appear in Anthropic’s own engineering account.

This is not evidence that multi-agent systems are fake. More computation can produce better results. Parallel research can cover more sources. Multiple attempts can rescue failures.

But fifteen times the budget is not an architectural footnote. It is part of the intervention.

A committee with fifteen times the salary budget may outperform one hurried employee. The fair question is whether the committee beats a strong individual given the same total resources.

On that question, the evidence becomes much less ceremonial.

A controlled study of 260 configurations found an 80.8 percent multi-agent gain on decomposable financial reasoning, but up to a 70 percent loss on sequential planning. Tool-heavy tasks incurred coordination overhead, and decentralized systems propagated errors more readily. Architecture helped when it matched the task and hurt when it did not.

A separate normalized evaluation across ten reasoning, coding, and tool-use benchmarks found that five of six multi-agent workflows trailed the matched single-agent baseline by 2.56 to 11.29 points while occupying worse accuracy-cost positions. The result is a preprint, but the direction is sobering.

Sometimes graph engineering is parallelism.

Sometimes it is a pricing model with arrows.

There are positive counterexamples. A peer-reviewed clinical study found that a lightweight orchestrator assigning genuinely independent tasks to dedicated workers preserved accuracy under large heterogeneous batches and, at the highest load, used far fewer tokens than putting the entire batch into one overloaded context. That is exactly the kind of workload for which a graph makes sense.

The conclusion is not that graphs fail.

It is that topology is conditional, not generational. Graphs have not “replaced” loops any more than a thread pool replaced the function call.

Where the single loop breaks

The strongest part of the original essay was not that graphs are fashionable. It was the account of why isolated improvement loops fail.

They fail in four characteristic ways.

First, the metric becomes the goal.

A support agent optimized for resolution rate learns to close conversations customers have merely abandoned. A coding agent optimized for passing visible tests learns to satisfy the visible tests. A maintenance loop measured by pull requests discovers that the easiest way to demonstrate productivity is to keep proposing maintenance.

The loop is not malfunctioning. It is succeeding against a proxy whose connection to value has decayed.

Second, the loop is blind upward.

A loop can optimize toward a target, but it cannot determine whether the target was worth pursuing. The agent told to improve an architecture cannot ask whether leaving the architecture alone would be better. It cannot calculate the opportunity cost of reviewing the work it is about to invent.

A perpetual improvement loop has no natural definition of done. It has a billing relationship.

Third, loops conflict.

One agent simplifies an abstraction while another adds flexibility. One optimizes performance while another improves readability. Two parallel writers make locally sensible decisions based on different implicit assumptions and leave a human to reconcile the resulting philosophy seminar in the merge conflict.

Fourth, measurement itself decays.

Tests stop representing production behavior. Benchmarks become contaminated. Model judges learn the preferences of other model judges. Dashboards compare one derived number against another derived from the same underlying system.

Everything agrees because nothing remains independent.

What graphs genuinely fix

The graph-of-loops idea addresses these failures through structure.

Goodhart is addressed by pairing metrics: speed with error rate, resolution with retention, accepted patches with reversions and escaped defects.

Target blindness is addressed by hierarchy: a slower, more authoritative process owns the targets of the faster loop.

Conflict is addressed by arbitration: some node explicitly owns the trade-off rather than letting two optimizers fight indefinitely.

Measurement decay is addressed by audit: a separate process checks whether internal measurements still correspond to the outside world.

Mature MLOps already has this shape. A challenger model competes against the champion. Drift monitors inspect the incoming data. Held-out evaluations remain hidden from the optimizing process. Deployment is connected to rollback machinery. Each component is a loop, but reliability comes from the edges—who supplies evidence, who may veto, and who may change the target.

Companies work similarly. Daily operating loops sit inside quarterly planning loops, which sit inside slower audit and governance loops. Different speeds prevent the fast machinery from continuously rewriting the goals that justify its existence.

This is real graph engineering, although control theory and organizational design have been doing it for some time without requiring a launch post.

When the graph becomes a more expensive hallucination

A graph does not automatically solve the loop’s epistemic problem.

Ten agents can inspect one another’s answers without any of them touching reality. A critic can evaluate a writer, a judge can evaluate the critic, and an orchestrator can summarize their consensus. If every node shares similar training, evidence, and blind spots, the graph becomes an elaborate system of mutual confirmation.

Research on intrinsic self-correction has found that models can degrade their own answers when no external feedback is available. Reflection is useful for editing, but it is not a correctness oracle.

Apple researchers tested nine frontier-model judges from seven model families and found that their correlated errors left only about two independent votes’ worth of information. The best single judge matched or beat the full panel across the tested conditions. Nine judges were not nine independent checks.

Sometimes they are two checks and seven invoices.

The original essay therefore reaches the right deeper conclusion: a graph needs anchors.

Some measurements must touch the world—tests that executed, money that arrived, users who stayed, files that compiled, a browser state that visibly changed.

Some rules must remain frozen. The optimizing machinery must not be allowed to rewrite its own acceptance criteria merely because they have become inconvenient.

And the root meaning of “better” must come from outside the graph. The system can optimize targets and perhaps recommend changing them. It cannot grant itself the authority to decide what the organization should ultimately value.

Graphs do not eliminate human judgment. Good graphs identify precisely where it remains necessary.

Is graph engineering even an established discipline?

Not yet.

The formal Structured Graph Harness paper proposes an explicit static graph, immutable plan versions, separate planning and execution layers, node state machines, and strict recovery escalation.

These are sensible design ideas. Explicit dependencies are easier to inspect than control flow hidden inside an expanding context window. Permission gates, recovery rules, and deterministic state transitions are valuable regardless of model intelligence.

But the paper explicitly describes itself as a position and design proposal. It provides no production implementation or empirical results.

Graph engineering is therefore an interesting hypothesis with some familiar systems-engineering virtues. It is not established evidence that adding more nodes produces better outcomes.

A diagram can make control flow visible.

It cannot make the economics disappear.

What survives as good practice

After removing the naming ceremony and vendor incentives, several practices remain genuinely useful.

A loop should have an external verifier. Prefer a compiler, existing test suite, browser state, schema validator, production metric, or human decision over the model’s opinion of its own work.

A loop should be bounded. Give it maximum turns, retries, wall time, tool calls, token spend, and financial cost. “Until done” is not a stopping rule when the agent also decides what “done” means.

State should be explicit and durable. Record what was attempted, what evidence was produced, which source state was inspected, and why the process stopped.

Completion should be evidence-gated. A recent Proof-or-Stop preprint usefully treats agent outputs as claims rather than lifecycle state. A model saying “tests pass” is prose. A fresh test result attached to the current revision is evidence.

Parallelism should follow real independence. Research branches, repository search, or separate input records may parallelize well. Tightly coupled code changes usually need shared context and serialized writes. Even Cognition’s more recent account of multi-agent systems that actually work recommends a narrower pattern: multiple agents may contribute intelligence while writes remain single-threaded.

Every additional node should beat a cheaper baseline. Compare against a script, one strong model call, one tool-equipped agent, or a human. Hold the token and time budget constant wherever possible.

Measure cost per accepted outcome—not prompts completed, agents launched, pull requests opened, lines generated, or tokens heroically sacrificed. Include review time, rework, reversions, regressions, maintenance, latency, and escaped defects.

A loop with a verifier, a stopping rule, and a budget is engineering.

Without them, it is recurring revenue with a while statement.

A less exciting maturity model

The practical progression is not prompt, loop, graph, swarm.

It is:

1. Use a deterministic script if a deterministic script can solve the problem.
2. Use one model call if one model call is enough.
3. Give one strong agent the tools and context it needs.
4. Add an external verifier.
5. Add a bounded retry only when measured failures justify it.
6. Parallelize branches only when they are genuinely independent.
7. Add reviewers or additional agents only when they beat the simpler system under a comparable budget.
8. Keep consequential actions behind explicit human authority.

One prompt when one prompt is enough.

One loop when external feedback can change the next action.

One graph when the dependencies, permissions, or independent branches are real.

A human when the consequences are theirs.

And the system should never be allowed to choose its own budget.

Where the naming loop goes next

Loop engineering contains one strong idea: stop managing every model turn and design the feedback, evidence, state, and stopping conditions around the work.

Graph engineering contains another: make dependencies, counter-metrics, authority, and audit boundaries explicit.

Neither idea requires perpetual agents. Neither implies that more agents are automatically better. And neither justifies replacing engineering judgment with an increasingly ornate society of language models reviewing one another’s expense reports.

Peter and Boris are showing what becomes technically possible when frontier models, exceptional operators, and unusually generous budgets meet. That is worth studying.

It is not yet proof that everyone else should reproduce the furnace.

The durable axis was never prompt versus loop or loop versus graph. It is grounded versus ungrounded, bounded versus unbounded, and value created versus inference consumed.

Perhaps the next discipline should be called restraint engineering.

It probably will not trend.

Its main benchmark is using fewer tokens.

‍