AI is solving open math problems: what a business can copy from the method

In nine months of 2026, AI went from digging up forgotten solutions to Erdős problems in the literature to OpenAI publishing what it presents as a complete proof of Navier-Stokes, one of the seven Millennium Prize problems. Along the way, a Fields medallist left academia for OpenAI, a Princeton mathematician stopped working on Erdős problems because there is “no point anymore”, and the keeper of the largest catalogue of those problems admitted that some proofs will never be read by a human.

We are not going to solve the Riemann hypothesis. But the method behind these results is the same one that separates an AI agent that works in production from one that never leaves the demo stage, and almost nobody is telling the story from that angle. This post covers what happened, why it worked and what a company can copy for its own software.

What happened in 2026, in order #

The table mixes two different things, and they are worth separating. The Erdős problems are hundreds of questions of very uneven difficulty, many of which almost nobody had looked at seriously. Navier-Stokes has resisted the best mathematicians for decades. The first group falling says a lot about the method. The second falling, if confirmed, says something about the raw capability of the models. For a business, the first matters most.

Why Erdős problems fall and others don’t #

Paul Erdős left more than a thousand papers and a habit: posing problems, sometimes with a cash prize attached. Thomas Bloom, now at the University of Manchester, started collecting them at erdosproblems.com in early 2023 with a couple of hundred. By August 2025 there were almost a thousand. According to Quanta Magazine, in August 2026 the database listed 565 solved and 652 open.

Quanta gives three reasons why AI is making progress here and not in other areas:

1. The terrain : the problems are mostly in number theory, combinatorics and graph theory, the areas where language models have proved most capable.
2. Uneven difficulty : some problems are trivial for a specialist and others nobody has touched. A technology with equally uneven abilities will always find some within reach.
3. The public catalogue : a single, ordered, accessible repository is a free test bench. Jared Duker Lichtman, from Stanford, puts it this way: “labs realized that this could effectively be a benchmark”.

There is a fourth, less flashy reason. Some of the “open” problems weren’t open at all: the solution had been published and nobody had connected it to the question. Problem 333 is the extreme example. Barreto posted an AI-generated proof on Christmas morning, and a few hours later another user linked the 1977 paper in which Erdős had already solved it. His takeaway for the community was to ask for “greater focus on literature search”.

A detail about who is doing this work: Barreto is an undergraduate. Liam Price, who works with him, left university without finishing. Wouter van Doorn works in customer service. Price admits, according to Quanta, that he lacks the training to check the proofs he gets out of the models himself. What he does have is a procedure.

The recurring pattern: generate a lot, verify cheaply #

Price’s procedure is to ask a chatbot for a solution, hand it to a fresh instance to review, and repeat. David Woodruff, from Carnegie Mellon, describes the same principle in the work he did with Google on a gravitational wave problem: “if I call it many times, then maybe one of those times it’ll get it right”. In his system the model proposes hypotheses, an automatic verifier checks the maths and a researcher does the final review.

In the most solid results on the list, the verifier is Lean, a proof assistant in which every step of a proof is checked mechanically. OpenAI published Astra’s ten results with Lean 4 certificates and zero sorry, the keyword Lean uses to mark a step accepted without proof. With that, nobody has to trust the model: if Lean compiles the proof, the proof is correct with respect to the formalized statement.

Knuth’s note follows the same scheme, with humans as the verifier. Claude Opus 4.6 found a construction to decompose a directed graph into three Hamiltonian cycles when the parameter is odd. Filip Stappers tested it by computer for every odd value up to 101, and then Knuth wrote the general proof.

The three stories share a structure:

• The model can’t be trusted , and nobody treats it as if it could.
• There is an independent verifier that says yes or no without interpreting: Lean, a program that tests a hundred cases, another instance of the model told to look for flaws.
• Because verifying is cheap, you can generate many proposals and keep the ones that pass.

That is the part a company can take home. Astra’s mathematical ability isn’t available, and most business problems don’t need it anyway.

Where your company’s “Lean” is #

The useful question for any process you want to automate with AI is what plays the role of verifier. If one exists and it is cheap, the model can be wrong nine times out of ten and the system still works. If it doesn’t exist, every mistake reaches the customer.

The last row is there on purpose. Some tasks have no mechanical verifier, and for those Price’s technique (another instance reviewing) is the best there is. We explain it in detail in LLM as a judge: it works, but it has to be calibrated against human judgement and its biases watched. The higher up the table, the more the problem resembles an Erdős problem, and the better AI does.

For any process in the left-hand column, the practical rule is to write the verifier before the prompt. A team that starts with the prompt ends up tuning it by eye with five examples. One that starts with the verifier can try four models and ten prompt variants in an afternoon and keep whichever passes the most cases.

AlphaEvolve: when the verifier is a cost function #

There is a variant of the pattern for optimization problems, where there is no correct answer, only better and worse ones. Google DeepMind introduced it in May 2025 with AlphaEvolve: an agent that writes programs, runs them against an evaluator that scores them, and evolves the ones that score best.

In mathematics, the team later applied it to 67 problems, matched most of the known constructions and improved several, with Terence Tao and Javier Gómez-Serrano taking part. But the first result DeepMind published wasn’t mathematical: a scheduling heuristic for Google’s data centres that, according to the company, recovers on average 0.7% of its worldwide compute capacity.

What matters for a business is the shape of the result. AlphaEvolve doesn’t make each assignment. It writes a short, readable program that makes them, and that program is reviewed, deployed and maintained like any other. Route allocation, shift assignment and stock replenishment work the same way: if there is historical data to replay past weeks and a metric that says which plan is better, you can set up a loop like this without touching the production system until you have a winner.

The long list of problems nobody looks at #

Before AI, most Erdős problems weren’t open because they were hard. They were open because they weren’t worth anyone’s time: a specialist could solve many of them in a week but had more important things to do. Noga Alon, from Princeton, said as much in Quanta when explaining why he has stopped working on them: “Once AI started to solve them, there is no point anymore”.

Every company has its own list of Erdős problems. The integration someone does by hand every Monday with a spreadsheet. The 2,000 products with an empty description. The report someone rebuilds every quarter by copying from three places. The 2014 script nobody dares touch. None of them justifies a project, which is why they have sat in the backlog for years.

What has changed is the cost per problem. DeepMind’s agent solved each Erdős problem for a few hundred dollars. Astra’s ten results cost, according to SiliconANGLE, about $2,000 at API prices. At the other end, TechCrunch estimates that the Navier-Stokes proof consumed 300 billion output tokens, about $22.5 million at Astra’s rates. Cost grows with difficulty, and most of what sits in a backlog is at the cheap end. We break down the numbers for each model in what it really costs to run LLMs in production.

To prioritize that list, the same criterion applies as with the maths problems: first the ones with a cheap verifier and little individual value, because nobody was ever going to tackle them by hand and a mistake gets caught before it does damage.

Before solving, search #

Problem 333 leaves a more mundane lesson. A large part of what was celebrated as “AI solves an open problem” was AI finding a solution that had already been published. Bloom said so in October 2025, when OpenAI claimed GPT-5 had solved ten Erdős problems: they were literature finds.

That has value, and in a company it is the most common use case. The answer to a customer’s question is usually in a PDF from 2019, in an email thread or in the head of someone who retires next year. A system that finds it and cites it saves more hours than one that reasons from scratch, and gets things wrong less often. But it only works if the knowledge lives somewhere searchable, which is what preparing a knowledge base for AI is about.

The practical order is search first, reason second, and always flag which of the two the system did. A cited answer is verified by opening the source. A reasoned one needs another verifier.

The bottleneck moves to review #

Thomas Bloom, in Quanta, on one of the generated proofs: “But no human has read it, and no human is going to read it. It’s a huge challenge now.” In early October OpenAI published hundreds of manuscripts at once, and part of the mathematical community responded by calling for a boycott. Generating stopped being the expensive part. Reviewing costs as much as it always did.

The same happens in a company, at a different scale. An agent that opens forty pull requests a day or proposes two hundred product listings an hour speeds nothing up if the team can review ten. Changes pile up, review becomes superficial and errors slip through.

What works is to split review into layers:

1. Automatic verification of everything that can be checked mechanically. Whatever fails never reaches a person.
2. Evaluation by another model against a rubric for what remains, ranking it by risk.
3. Human review of whatever the evaluator flags as doubtful, plus a random sample of the rest, to detect whether the evaluator has drifted.

With the Navier-Stokes proof even that isn’t enough, because the result is new and nobody has anything to compare it against. NPR summed it up in a headline: AI solved one of math’s hardest problems and humanity learned nothing (yet). In a business process the equivalent is accepting a change that works without anyone on the team understanding why. For code someone will have to maintain, that is debt.

Data and authorship: what the Navier-Stokes dispute teaches #

On the day of the announcement, TechCrunch published the account of Tristan Buckmaster, an NYU mathematician who was working on the problem with Levent Alpöge, from Anthropic. Buckmaster says that Sébastien Bubeck, from OpenAI, asked him to remove Alpöge’s credit. Buckmaster had used Codex, OpenAI’s coding tool, during his work. According to TechCrunch, OpenAI’s post says: “While unlikely, we cannot rule out that de-identified data derived from their usage of our products helped improve our models.”

Whatever the outcome, that sentence applies to any company putting its code, contracts or customer data into an AI tool. Before doing so you need to know whether your plan excludes training on your data, what is retained and for how long, and where it is processed. The enterprise plans of the main providers allow this; the free plans and some paid individual ones don’t always. It is a checkbox in a contract, and it should be ticked before the first prompt.

How to tell if your problem is “Erdős-shaped” #

Five questions to decide whether a process is a good candidate for AI, in the order we ask them:

1. Is there a cheap verifier? A test, a sum that has to reconcile, a schema, a constraint. If the only way to know whether the result is right is for an expert to look at it, AI works as a first draft, not as a system.
2. Can you generate many attempts? If each attempt has real-world effects (an email sent, an order placed), you first need an environment where it doesn’t.
3. Is it already solved somewhere? In the internal documentation, in the ticket history, in a library that already exists. Searching is cheaper than reasoning.
4. Who is going to review the volume that comes out? If the answer is “the same team that can’t keep up now”, designing the review is part of the project.
5. Can you put your data into the tool? Check the terms of use before the proof of concept, not after.

A process that scores well on the first three looks more like an Erdős problem than like Navier-Stokes, and is usually done in weeks.

What we do with this #

In our AI agents projects we treat evaluation as a discipline of its own: before choosing a model or writing prompts, we define what counts as a correct result and how to check it automatically. That lets us compare models on data rather than impressions, and tells us whether a provider’s version change has made something worse before a customer notices.

If your backlog has a list of tasks nobody tackles because they aren’t worth it, tell us about three. We’ll tell you which ones have a verifier, which need one built and which are better left to a person. You can reach us from our artificial intelligence page.