Formalising Fermat's Last Theorem took 11 days once. A thousand agents did it in 30 hours

Formalising Fermat's Last Theorem took 11 days once. A thousand agents did it in 30 hours.

A frontier lab reported that result this week, and I'd treat the headline number as the least interesting part of it. It's a single run, it's self-reported, and it hadn't been independently verified at the time of writing. Numbers like that tend to travel faster than the caveats attached to them, so I'd hold this one loosely until others have looked at it closely.

What holds my attention is something else: why this particular task suited the approach so well, and what that tells the rest of us about putting agents to work.

Why a proof was the right job for a thousand agents

A formalised proof is checked line by line by a machine. Every piece of work any agent produces gets accepted or rejected without anyone's opinion involved. There's no debate about whether a step is good enough, no reviewer having a slow afternoon, and no ambiguity about what done looks like.

When checking is that cheap and that reliable, a thousand workers can run in parallel and the result still means something. Each agent can try, fail and try again, and the checker quietly throws away whatever doesn't hold up. The number of agents stops being a risk and becomes a lever. You can add more of them without adding more doubt.

That's the part I think gets lost in the coverage. The impressive thing isn't only the speed. It's that the task came with its own referee.

Most business work has no referee

Most business work doesn't have a checker like that. Think about a product spec, a migration plan or a customer journey. Nothing tells you objectively whether an agent's output is right. Two experienced people can read the same spec and disagree about whether it's finished.

So every extra agent produces more material for a person to review. Ten agents writing migration plans give you ten plans to read, compare and reconcile. The review becomes the bottleneck long before the compute does, and the people doing the reviewing are usually the ones you can least afford to tie up.

This is where a lot of agent pilots quietly stall. The demo looks great because one agent produced one convincing draft. Scaling it up just moves a pile of unchecked work onto someone's desk. Our recent piece on tools that coordinate several coding agents looked at splitting work up; checking what comes back is the other half of the same problem.

Find your proof checker

That makes me think the useful question for any team adopting agents is where their equivalent of the proof checker sits. It doesn't need to be as rigorous as a formal proof. It needs to give a reliable yes or no without a person in the loop.

Plenty of teams already have pieces of this, even if they don't think of them that way:

• Automated tests. A good test suite tells you whether a change broke something, the same way every time.
• Type systems. They reject whole categories of mistakes before the code ever runs.
• Reconciliation against a ledger. The numbers either match or they don't.
• Regulatory rules encoded as code. If a requirement can be written as a check, it can be applied to every output, not just the ones someone happens to read.

Teams with those in place can spread work across many agents with confidence. Teams without them will mostly be generating a lot of unreviewed output.

What this means for founders and product teams

If you're deciding where to use agents first, I'd start from the checker rather than from the task that sounds most exciting. A few practical steps:

• Map your processes by how they're verified. For each one, ask how you currently know the output is correct. If the answer is "someone senior reads it", that's a weak first candidate for running many agents in parallel.
• Invest in the checker before the agents. Better test coverage, stricter types and automated reconciliation pay off with or without AI. With agents, they decide how far you can scale.
• Write down what correct looks like. Many processes have never been specified tightly enough to check automatically. Doing that work is often the real project.
• Measure review time, not just output. If agents double what gets produced but also double the review queue, you haven't gained much.

None of this needs a research lab's budget. It needs the unglamorous discipline of defining success in a way a machine can confirm, which is the same groundwork we start with in our AI product and automation work.

A question worth sitting down with

Whatever the Fermat result turns out to be once others have examined it, it's a neat illustration of a simple idea. Parallel agents are only as useful as your ability to check what they produce.

I'm curious how many of the processes we build software for could be given a checker like that, if someone sat down and defined what correct looks like. My guess is more than most teams assume, and the teams that do that work first will get far more from agents than the ones that simply add more of them.