Claude Formalized Fermat: Four Lessons for Long-Running AI Agents
On September 4, 2026, Anthropic published what it describes as the first complete computer-checked formalization of Fermat’s Last Theorem. Claude worked largely autonomously for 11 days, generated 13 million lines of Lean, and proved 30,300 intermediate theorems, 29,500 of which were used in the final result. The work did not discover a new proof of the theorem. It translated the established Frey–Serre–Ribet–Wiles–Taylor-Wiles route into code that proof-checking software can verify.
That distinction is the reason the result matters beyond mathematics. The headline is about Claude, but the operational breakthrough is the system around it: a dependency graph, persistent external state, small independently checkable tasks, aggressive reuse, and a deterministic acceptance test. For teams building long-running AI agents, the project is a rare, concrete example of how to make a huge workflow auditable instead of merely impressive.
Reader value: Use the Fermat formalization as an architecture review for long-horizon agents. The transferable lessons are not about theorem proving; they are about decomposing work, preserving state, enforcing machine-checkable gates, and making failures useful.
What Anthropic actually shipped
Anthropic’s report says dozens of agents collaborated through Prove2Me, an open platform for formal mathematics, using an internal general-purpose model roughly comparable to Claude Fable 5.1. The run consumed about six billion output tokens. Its result is not a prose explanation that experts are asked to trust. It is a public Lean repository whose declarations can be compiled and checked.
The released repository pins Lean 4.33.1 and Mathlib 4.33.0. Its default verification target rejects the proof unless it depends on exactly Lean’s three standard axioms. A comparator checks that the proved statement matches Mathlib’s statement of Fermat’s Last Theorem, while a second, independently implemented kernel called nanoda accepted an export containing more than one million declarations.
This is stronger evidence than a benchmark score or a polished demo, but it is also narrower than the phrase “AI proved Fermat.” Claude formalized a known mathematical argument using a large body of prior human work, including Mathlib, the Imperial College London FLT project, and the flt-regular project. The novelty is the scale and speed of the formalization, plus the fact that the final artifact can be checked mechanically.
Lesson 1: Move the plan out of the model
The project reportedly started to work at scale after the team switched to Prove2Me. Its most important feature was a directed acyclic graph, or DAG, of theorem statements. Agents used the graph to decide which proof obligations were ready and which dependencies were still missing.
That design solves a general agent problem: a model’s context window is a poor source of project truth. Long conversations accumulate obsolete assumptions, incomplete summaries, and plans that no longer match the artifact. A durable graph does the opposite. It makes prerequisites explicit, exposes parallel work, and tells the orchestrator when a branch is blocked.
The public proof-path document illustrates the benefit. Each theorem statement lives separately from its proof, and imports identify the theorems it cites. If prose and Lean disagree, the Lean is authoritative. That is a useful rule for any agent system: human-readable plans explain the work, but machine-readable dependencies govern it.
For software, research, or compliance workflows, represent each work item with at least four fields: inputs, dependencies, acceptance test, and artifact location. Let the model propose updates, but let an external controller determine whether a task is ready or complete. This prevents “I think I finished” from becoming a state transition.
Lesson 2: Make verification the unit of progress
Most agent benchmarks grade the final answer. The Fermat project could grade every proof obligation. Lean either accepts a term for an exact theorem statement or it does not. That turned verification from a final review stage into the basic unit of progress.
The repository’s FinalCheck.lean is an unusually clear acceptance contract. It imports the final theorem, prints its axioms, and derives Mathlib’s formulation from it. The broader verification procedure also rebuilt the project from source, ran a statement comparator, scanned for escape hatches such as sorry and added axioms, and checked the environment with another kernel.
You may not have a proof assistant for your domain, but you can still improve the gradient. Replace broad goals with small claims that have executable tests:
- A coding agent should close a failing test without weakening the test suite.
- A data agent should produce a query whose totals reconcile to a known control.
- A research agent should attach source-backed claims to exact passages and dates.
- A deployment agent should prove that health checks, rollback, and observability all pass before traffic moves.
The key is to reject self-reported completion. Agent output becomes progress only after an independent mechanism validates the artifact.
Lesson 3: Separate interfaces from implementations
Prove2Me separated theorem statements from proof files and maintained the links independently. That made compilation faster, reduced resource use, and allowed agents to work against stable interfaces while proof implementations changed.
This is the same design principle that keeps large software systems tractable. In agentic workflows, the “statement” is a typed contract: a schema, test, API, or declared result. The “proof” is the agent’s implementation. Freeze the contract early enough that parallel workers can depend on it, then allow implementations to be retried or replaced without rewriting the whole plan.
The pattern also limits blast radius. A failed attempt in the Fermat run was not necessarily wasted; Anthropic says failed efforts contributed about 7% of the non-boilerplate lines in the final proof. Because artifacts were modular and searchable, useful fragments could be recovered and reused. In a chat-only workflow, the same partial result would often disappear inside a discarded conversation.
Store artifacts in addressable, versioned units. Index them with short natural-language descriptions so agents can search for prior work. Require dependencies to reference stable identifiers, not vague phrases such as “the earlier analysis.” Reuse should be a retrieval operation, not a memory test.
Lesson 4: Verify the verifier’s boundary
Machine checking does not eliminate trust; it makes the trust boundary smaller and more visible. The Lean kernel checks whether the final statement follows from the declared axioms and definitions. It does not decide whether every intermediate name is pedagogically accurate, whether the proof is elegant, or whether the system deserves credit for mathematical discovery.
The repository is explicit about this boundary. It notes that tools cannot check whether each intermediate theorem means what its name suggests; readers must judge that correspondence. It also documents borrowed material and pins tool versions. Those details matter because a validator is only useful when teams can state exactly what it guarantees.
For a production agent, write a verifier contract before claiming reliability:
| Verifier | What it can establish | What remains outside the boundary |
|---|---|---|
| Test suite | Defined behaviors pass | Missing tests and wrong requirements |
| Schema validator | Output has the expected shape | Whether the content is true or useful |
| Citation checker | A source contains the cited text | Whether the inference is fair |
| Policy engine | Declared rules allow an action | Undeclared hazards and bad policy design |
| Human review | Judgment on sampled or high-risk cases | Unreviewed branches and reviewer error |
The best systems combine several validators whose failure modes do not fully overlap. Anthropic’s repository uses a Lean build, a statement comparator, forbidden-construct scans, and a second kernel. That layered approach is more persuasive than repeating the same check twice.
A practical architecture for durable agents
The Prove2Me paper describes mechanisms that let many agents build on one another’s work and reuse existing results. The transferable architecture is straightforward:
goal
-> dependency graph of typed work items
-> scheduler selects ready nodes
-> agents create versioned artifacts
-> deterministic validators accept or reject each node
-> accepted artifacts unlock downstream nodes
-> independent final checks verify the assembled result
Add budgets and stop conditions to every node. The Fermat run’s six billion output tokens are a warning as much as a demonstration. Massive parallel search can make progress, but without cost attribution it can also hide inefficiency. Track attempts, validator failures, reused artifacts, and cost per accepted node. A team should know which branches produced durable value and which merely consumed context.
Before increasing autonomy, require four pieces of evidence from a pilot: the graph can resume after an interrupted run; a rejected artifact cannot unlock downstream work; two agents cannot silently overwrite the same contract; and a reviewer can reconstruct the cost and provenance of every accepted node. These tests expose orchestration weaknesses that a successful final demo can hide.
Start with one workflow where correctness can be expressed clearly. Build the graph and validator before adding more agents. If a single agent cannot tell whether a node is complete, ten agents will only create uncertainty faster.
Limitations and open questions
Anthropic produced and described the result, so its claims about the run’s autonomy, token use, and internal model are not independently reproducible from the public repository alone. The proof artifact can be checked; the full orchestration process cannot yet be replayed from the published materials.
Scale is another caveat. Thirteen million lines and six billion output tokens are extraordinary, but they do not establish that the approach is economical for ordinary engineering work. Formal mathematics offers unusually crisp validators. Product strategy, scientific interpretation, and policy analysis have fuzzier acceptance criteria, so human judgment remains essential.
Finally, machine-checked correctness is not the same as comprehension. A gigantic formal artifact may be reliable while remaining difficult for humans to learn from or maintain. Anthropic itself argues that formalization should accompany, not replace, human-readable exposition. Long-running agents need both layers: an artifact machines can validate and an explanation people can challenge.
The Bottom Line
Claude’s Fermat formalization is best understood as a systems result. The model mattered, but the decisive ingredients were external project state, dependency-aware scheduling, modular artifacts, reuse, and validators that did not accept the model’s word for success.
Teams building long-running AI agents should copy that shape. Put the plan in a graph, turn completion into a testable claim, preserve every accepted artifact outside the conversation, and document what each verifier cannot prove. More autonomy becomes useful only when it produces more evidence.
