The model did not get smarter. The scaffolding around it did.

Three results, zero new models

September has been a strange month in AI.

On 8 September, OpenAI announced that roughly 10,000 agents, running for 88 hours, had produced a proof for a variant of the Navier-Stokes problem. The agents sent nearly five million messages to each other, and the compute bill ran to several million dollars.

Worth stating plainly up front: Navier-Stokes is one of the seven Millennium Prize Problems, but what OpenAI proved is not the formulation the prize covers. The Clay Institute has not accepted the result and still lists the problem as unsolved. The proof has been machine-checked in Lean, but independent peer review takes years.

Days later, two research papers on the same theme arrived from opposite sides of the world. The Last AI Built by Humans, 75 pages from Shanghai Jiao Tong, Tsinghua, ByteDance and Shanghai AI Lab, setting out five levels of self-improving AI. And Dream-RSI from the University of Maryland, Google DeepMind and the University of Virginia.

The headlines are not the interesting part. The interesting part is a detail that runs through all three and that almost nobody is discussing:

None of them used a better model.

The weights, meaning the model itself, stayed fixed. What changed was the scaffolding around it. How the work was divided, who checked whom, what got recorded, and when it was acceptable to give up.

That is a claim we have made for a long time: structure comes before technology. The difference now is that we are not the ones making it. The research labs are demonstrating it.

What a loop actually is

Boris Cherny, the man behind Claude Code, said something in an interview in June that has been circulating ever since:

"I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."

A loop is not complicated. It does four things, over and over:

1. It asks the model to try something
2. It reads what came back
3. It decides whether the task is actually done
4. If not: it asks for another attempt, informed by what it learned

That is all. And yet this four-step mechanism sits underneath every one of the results above.

Example 1: 30 of 60 agents produced nothing

The best documented case is Anthropic's work on the Riemann hypothesis in August.

The model generated and tested 650 ideas without succeeding at anything. Then, over about a day and a half, it coordinated roughly 60 subagents that ran 2,400 shell commands, wrote hundreds of Python scripts and refereed each other's work. Thirty-one million output tokens in total.

The breakdown of those 60 subagents is the most instructive thing in the whole story:

Half of them produced nothing.

That is not a weakness in the setup. That is the setup. The structure is what made 30 wasted attempts cost almost nothing, and what caught the 2 that landed instead of letting them drown.

Note as well that 13 agents, the same number that developed supporting ideas, had exactly one job: to check whether the arguments held.

The result was moving a lower bound from 41.6 to 67.2 per cent. The Riemann hypothesis remains unsolved, and Anthropic states plainly that they do not expect the technique to solve it. Some weeks later the mathematician Youness Lamzouri published a simpler proof of the same bound, without AI.

That last sentence is worth reading twice.

Example 2: 423 Firefox security fixes in a month

Mathematics is a long way from most people's working day. This one is closer.

Mozilla set up a loop against the Firefox codebase that ended in 423 security fixes shipped in one month. The loop had three stages:

Prioritising. A model went through millions of lines of code and gave every file two scores: how likely it was to contain memory safety issues, and how reachable it was from a web page. The agents spent their time where the risk was.

Attempting. The agents tried to make the program crash. Some bugs took "14, 15, 20 different approaches" before they could be reproduced.

Checking. Two gates before a human got involved. First, an actual crash had to have happened, described as "a crystal-clear signal". Then a separate verifier agent had to confirm the bug report made sense.

The result was that almost no false positives reached the developers.

And then the honest caveat, which is at least as interesting: when the agent fixed a bug, it usually fixed only that one location. The humans looked at it and said: this is right, but we should check three similar places too.

Example 3: the logs are the asset

The Dream-RSI paper takes this one step further, and this is where it becomes relevant to how you work.

Normally, if you want to test a new strategy for how the loop should search, you have to run the whole loop again. That costs money and time.

The paper's point is that this is unnecessary if you kept a record of what was tried last time. The code that was written, the score it got, whether it crashed. With those logs, you can test thousands of new strategies against them without running a single new computation. The researchers call it dreaming.

Concretely: a lasso solver was developed in 1,879 agent calls, against 51,200 generations for the method that held the record. On one of the tests, total compute dropped by 42 per cent.

And again: the model was never touched. Only the code deciding what to try next was rewritten.

The hard part is not the loop. It is the stopping condition.

Here is the point for you, and it is not the one you would expect.

Writing the loop itself is trivial. A few lines of code. The hard part is answering one question:

How does the loop know it is finished?

Firefox had a crystal-clear answer: the program crashed, or it did not. The Riemann work had thousands of numerical checks against known values. Dream-RSI had a score for how fast the code ran.

In all three cases there was a signal that could not be argued with.

Most business processes have nothing of the sort. "Is this proposal good enough?" has no fuzzer that crashes. "Is this invoice coded correctly?" actually does, if the chart of accounts and the rules exist in writing. "Is this document current?" does, if somebody has decided what current means.

That is where the work is. Not in the model, not in the loop, but in making the criteria explicit enough that a machine can check them.

It is also why "we should use more AI" rarely goes anywhere, while "we should write down what actually counts as correct here" does.

Four things to take away

You do not need a better model. You need a verifiable definition of done. That is something a person inside the business has to decide, not something a vendor can deliver.

Expect most of it to fail. 30 of 60 agents produced nothing, and that was fine because it was cheap. Build things that tolerate failure rather than chasing something that lands every time.

Keep the logs. What was tried, what came out, what did not work. That is the raw material the next round builds on. Businesses that do not document pay for the same discovery twice.

Keep control. In both documented examples, humans had a role that could not be automated away: seeing what the agent did not. That pattern is not temporary.

And one more thing, about where your work goes

Every example above has something in common that is easy to miss: the work happened inside a vendor's model.

That is worth a question, and it does not only apply to mathematicians.

When you run your own problems, documents and customer data through an AI tool, where does it go? Who has a data processing agreement with whom? What is shared, and what is not?

This is not a question of distrusting the vendor. It is a question of knowing the answer before it matters rather than afterwards. It is the same work that sits underneath everything else here: the structure has to be in place before the technology.

A loop is not magic. It is a tidy way of working, put into a system. That is exactly why it works.