Eleven Days Alone: What Claude's Mathematical Proof Reveals About Autonomous Agents

On September 4, 2026, Anthropic published a research post that caused a stir even in the fast-moving AI industry: in a little over eleven days, Claude largely autonomously produced the first complete, machine-verified proof of Fermat's Last Theorem - formulated in the proof language Lean. A mathematical problem whose original proof by Andrew Wiles took years of work back in 1995, and whose complete, machine-readable formalization experts had until now considered a multi-year research goal.

For mathematicians, this is a historic moment. For you as a business owner in the Mittelstand, it's something else: an unusually well-documented case study of how autonomous AI agents actually work today - with all their strengths, all their limits, and one constraint that ultimately matters more for deployment in your business than the mathematics itself. This article breaks down what actually happened, what the numbers behind it mean - and what you can take away for your own agent projects.

What Anthropic actually demonstrated

Let's take this step by step: Anthropic did not claim that a single agent worked uninterrupted on one problem for eleven days. In fact, several dozen Claude agents were working in parallel, organized in a multi-agent workflow. The "eleven days" describes the wall-clock time of the overall project - not the runtime of a single, continuous agent thread. According to press reports, an internal research model was used, described as roughly comparable to Claude Fable 5.1 - not a publicly named regular production model version. This exact designation comes from secondary press sources and should be checked against Anthropic's original material before any further reuse, if in doubt.

This is an important clarification, because public perception quickly forms the image of a single, day-long-running "super agent." The reality is more of a division of labor, and closer to what happens in a well-organized team: many specialized workers tackling sub-tasks in parallel, while an overarching process continuously merges the results and checks them against the next open sub-problems.

There was human oversight involved - but in a specific, very hands-off form. Anthropic's lead researcher Tianyi Peng did not intervene in the Lean code itself and did not correct details in the proof. His role consisted of occasional, high-level prioritization hints such as "Jacobian as a scheme should be prioritized" or "push forward the Mazur theorem." In other words, he set the strategic direction without controlling every single work step in detail. This exact ratio - few but effective human interventions at a high altitude, no detail correction - is one of the two central patterns from this project that carry over to your business.

The numbers behind the headline

What was actually produced in eleven days can be expressed in sober numbers - and these numbers deserve more attention than the headline itself. The formalization effort generated roughly 13 million lines of Lean code, according to press reports the largest known file or codebase of its kind. A total of 30,300 individual theorems were proved, of which 29,500 were actually used in the final proof - the gap shows that even in a process this well orchestrated, part of the work doesn't end up in the final result but instead represents dead ends or intermediate steps later replaced by more elegant proof paths.

A comparison helps put this scale into perspective: Mathlib itself has been built up over many years by a dedicated, worldwide community of mathematicians and computer scientists working together - line by line, checked and discussed in open reviews. That a single, project-focused fleet of agents produced, in eleven days, a volume of code that exceeds this community effort built over years by more than fivefold shows one thing above all: where intermediate steps are automatically verifiable, assembly-line-style work can be done at a pace unreachable for humans alone. That - not a leap in mathematical creativity - is where this project's actual leverage lies.

Roughly 6 billion output tokens were consumed for this volume of work, summed across all agents working in parallel. For context: before the project, mathematicians had expected a complete formalization to take several years of effort. Claude got it done in eleven days of wall-clock time.

This scale is also an important reality check for the Mittelstand: a project of this magnitude - dozens of parallel agents, billions of tokens, a dedicated research model built specifically for it - currently still requires massive computing resources that no mid-sized business has on hand, nor needs to have on hand. What's relevant for your business isn't projects of this size, but smaller, clearly scoped agent use cases that work on the same verification logic while getting by on a fraction of the computing effort.

How autonomous was the process really?

One detail from Anthropic's post is left out of many summaries, yet is particularly instructive for translating this into a business context: the first formalization attempt failed. Only the use of Prove2Me, an open-source tool from the Columbia University environment, made completion possible partway through the ongoing project.

That means: even a flagship project this elaborately orchestrated and well funded did not proceed linearly from start to finish, but iteratively - with a setback, a course correction, and an additional tool that was only added midway because it became clear during the process that it was needed. If you're planning the entry into agent workflows in your business, you should bring exactly this expectation with you: the first approach rarely works perfectly right away. What matters isn't whether the first attempt already delivers the final result, but whether the process is set up so that a failure becomes visible early and can be corrected, without immediately putting the entire project into question.

The crucial limitation: formal versus substantive verification

This brings us to the actual core of this article - a limitation that often gets too little attention in coverage, but is central to translating this into your business. Lean verified the finished proof purely on formal-logical grounds, against its three standard axioms. That means: every single logical step in the proof is demonstrably correctly derived from the previous step, without gaps, without unproven intermediate assumptions.

What Lean does not check is semantic correctness - that is, whether the individual intermediate statements actually name and capture the mathematical concept they claim to represent. According to several expert reports, this substantive check remains the job of human experts. A system can therefore be perfectly formally consistent and still end up proving something different from what was actually intended - if the definition itself wasn't captured correctly at the start. Formal correctness and substantive accuracy are two different questions, and only the first is answered fully automatically here.

Kevin Buzzard of Imperial College London, a recognized Lean and Mathlib expert, called the achievement an "extraordinary autoformalization achievement" and a major step toward automatically formalizing the modern mathematical literature - which could in the future help spot errors in the mathematical corpus and take work off reviewers' hands.

This assessment is favorable, but it also confirms the limit at the same time: even the most prominent external commentary on this project describes progress in formalization - not the replacement of human expert review. Claude did not rediscover or replace Andrew Wiles's proof. The actual achievement lies in the complete, machine-readable formalization and verification of an already existing proof, whose formalization had previously been considered a multi-year research goal.

It's also worth noting how the evidentiary basis itself looks: the central figures - the 13 million lines of code, the 30,300 and 29,500 theorems, the 6 billion tokens - come essentially from Anthropic's own research post, supplemented by the single external quote from Kevin Buzzard. A broader, independent third-party verification of these numbers by the expert community, or a formal review of the code in a peer-reviewed journal, has not been documented so far. That, too, is a lesson for the business context: impressive metrics about an AI project are, at first, self-reported claims from the provider - a healthy dose of verification is warranted before building decisions on them.

What the transferable principle is for your business

The obvious but wrong lesson from this project would be: "AI can now independently solve highly complex tasks, so we can just let agents loose in our business too." The actually relevant lesson is more precise and more useful: long, multi-step tasks become delegable to agents once every intermediate step is made machine-verifiable.

In the Fermat project, Lean played this role of machine-based intermediate verification - every single logical step had to pass the system's rules before the next step could build on it. In your business, those could be other mechanisms: structured rule checks in bookkeeping, checklists in order processing, a defined posting logic in financial administration, or a parser that systematically checks contract clauses against defined criteria before a document is approved. The common denominator is always the same: an agent doesn't just "work autonomously somehow," but operates within a system that can objectively and automatically check every intermediate step before the next one builds on it.

A concrete example makes this tangible: an agent that matches incoming supplier invoices against purchase orders and delivery notes can formally check every single line item against stored rules - do quantity, price, and tax rate match, is there a valid cost center, is the amount within the agreed range. If this check passes, that proves the invoice is consistent with the stored rule set - just as a Lean proof step formally follows from the previous ones. Whether the rule set itself is still current, whether a new contract clause has been accounted for, or whether there's a special case the rules don't cover, remains a different question - and that is exactly the semantic layer that still belongs to human responsibility.

The second transferable principle concerns the role of people in the process. Tianyi Peng's oversight was minimal, but not absent - he set strategic priorities without controlling every work step in detail. That's a realistic target picture for deploying agents in your business: direction set by people, detailed execution by agents, verification built in rather than bolted on afterward. The goal isn't the complete absence of human control, but shifting it from the detail level to the strategic level - where human judgment actually makes the biggest difference.

And third: the semantic gap is the central warning you should take with you when applying this to bookkeeping, contract review, or customer communication. An automated, "passed" check doesn't prove that the underlying question was correctly framed. If an agent, for example, checks an invoice against a rule set and the check passes, that only means the invoice is consistent with the rule set as formulated - not that the rule set itself asks the right question or correctly reflects the actual business transaction. That's exactly why the substantive task definition and the spot-checking of intermediate results remain the job of your subject-matter experts, just as they remain the job of human mathematicians at Anthropic.

The failed first formalization attempt and the switch to Prove2Me are perhaps the most useful detail in this entire story for you as a mid-sized business. They show: even a team of AI researchers with considerable resources doesn't plan every step perfectly in advance. Instead, the approach is iterative, a failure is used as information, and an additional tool is added as soon as it becomes clear during ongoing operation that it's needed.

That's the mindset you should bring to yourself and your team when you start with agent-supported workflows: expect a first approach that needs adjusting. Build in checkpoints where you and your experts can tell whether an agent is actually doing the right thing - not just whether it's working formally error-free. And start with clearly scoped task areas where intermediate steps can be checked well, instead of trying to fully automate an entire, unwieldy process right away. The Fermat project's scale factor - dozens of agents, billions of tokens - shouldn't intimidate you here: it merely shows what's possible with maximum resource deployment, not what a sensible entry point requires.

Conclusion: it's not the mathematics that counts, but the principle behind it

Claude's proof of Fermat's Last Theorem in Lean is a remarkable technical achievement - eleven days of wall-clock time, dozens of parallel agents, 13 million lines of code, 30,300 proved theorems, more than five times the size of Mathlib. But for your business, it's not the mathematics that counts - it's the pattern behind it: long tasks become delegable to agents once every step stays machine-verifiable. Human oversight shifts from detail control to strategic prioritization, but doesn't disappear entirely. And a formally passed check doesn't replace substantive review by experts.

Anyone who understands these three principles can read the Fermat story for what it actually is for the Mittelstand: not proof that agents can now do everything on their own, but a well-documented example of what sensible division of labor between human, agent, and built-in verification can look like - at a scale that suited Anthropic's research goals, and transferable to a scale that's actually achievable for your business.