How 1,000 AI Agents Coordinated via PostgreSQL, Git & Lean to Prove Fermat's Last Theorem

Laying Out the Work

Anthropic ran an early version of Claude Fable 5.2 with 1,000 agents (1 lead, 999 helpers) to reproduce the Lean formalization of Fermat's Last Theorem. The team started with 60 propositions, 47 already-proven lemmas, and a high-level proof sketch. The lead agent created five shared PostgreSQL tables in the first 10 minutes: Announce – broadcast instructions to all agents Assign – record which agent leads or assists each proposition Notes – store plans, reasoning, and progress Subtasks – list concrete, claimable work items Landed – log completed work, corresponding commits, and team verification status

The lead wrote 999 assignment rows into Assign, picked a group leader per proposition, and had helpers estimate difficulty in Notes. Based on those estimates, at minute 27 the lead reassigned helpers from 47 propositions deemed too hard to the remaining 10, increasing group sizes from ~17 to 46–139 agents each. By minute 70 those 10 were done, and the lead moved helpers back to the hard problems.

Separating Reassignment from Task Claiming

At hour 3 the lead told idle helpers "don't wait for me" – they could cross groups and claim next tasks themselves. Helpers read Assign to see their new group, Notes for the plan, and Subtasks to pick a work item. This decoupled the lead's strategic rebalancing from tactical task pickup. By hour 5.6, 73 helpers had created 756 subtasks (only 16 by group leaders). Over 30 hours the system logged 36,612 database writes and 311,734 reads; helpers wrote to Subtasks 14,769 times versus 2 by the lead.

Claiming a task required atomic "check-then-set" on a subtask row to avoid races; the article notes the exact SQL was not published. Duplicate work could still occur if two helpers created separate subtasks for the same logical work – mitigated by reading plans and noting ownership.

Completion Requires a Commit

Each helper had a lightweight VM with Lean toolchain and a private Git branch. Workflow: write proof locally, verify with Lean, push to own branch, open PR to main, mark subtask done, update progress notes. An independent merge job handled PRs, rejecting on conflicts or history anomalies. The Landed table recorded which task was finished, the commit hash, and team check status – so the next agent could fetch the exact code version that passed verification.

Three distinct events: subtask marked done (helper reports finish), code merged to main (Git records merge), Lean grader on main verifies proof (final authority). The article warns these can desynchronize (e.g., code merged but task table not updated) and that production systems need explicit reconciliation.

Hard Problems Need Further Decomposition

At hour 18 most propositions were done; remaining were Langlands–Tunnell and dependents. The lead reassigned ~750 helpers to Langlands–Tunnell, admitting low confidence. The group leader split it into 10 directions; helpers recursively decomposed oversized tasks, growing a task tree 10 layers deep with 2,418 nodes. A key pattern: one subgroup proved "if A then B" while another proved A – interface-first parallelism analogous to frontend/backend contract-driven development.

Nicholas Carlini's earlier 16-agent C compiler experiment showed that without clean decomposition agents duplicate fixes and overwrite each other; splitting compilation via GCC boundaries resolved it. The lesson: each piece must be independently advanceable and integrable.

Conditions for Thousand-Agent Operation

Earlier 100-agent shared-machine runs failed from resource exhaustion. This run gave each agent a dedicated VM; model, Git, and SQL requests routed through a gateway that tagged caller identity, prevented impersonation, blocked direct internet, limited SQL to 5 seconds and bounded write size. Agents used a shared low-privilege DB role – task ownership in tables did not grant extra permissions. The lead received 19 time-remaining reminders from the system. Total output tokens were ~1/3 of a prior run, proof length ~1/7; the article cautions that model, materials, headcount, and environment all changed, so per-agent contribution cannot be isolated.

Relay in Development

The article maps the patterns to a two-agent frontend/backend task: add status filter to an order page. Human defines acceptance criteria; both agents work from a single issue containing the exact contract (three statuses, default behavior, 400 on invalid, pagination reset, shared filter for list and total, existing permissions). Backend task records: baseline commit + interface spec + code locations; scope (query endpoint + backend tests); deliverables (commit/PR, check commands + results, open issues). Frontend uses mock responses; each agent works in a separate Git worktree/branch; containers isolate conflicting runtime dependencies. Integration: merge both branches, run API tests and UI flows, verify permissions and pagination, record commit and CI results. Unlike Lean's theorem checking, software tests cover selected behaviors – human-confirmed acceptance criteria and end-to-end flow checks remain essential.

Integrating into Agent Systems

Lance Martin (Anthropic) emphasizes long-horizon tasks and context persistence via files and Git history. For handoff: new agent reads requirements, short progress notes, and linked commits; notes specify which commit changed query logic, which test cases passed, what remains (e.g., list/total consistency), and failed attempts with commands/log pointers. This lets the next agent resume from the exact point and re-verify completed parts via commits and test records.

System design sketch: task service stores contracts, claims, artifact locations; executor prepares workspace, branch, tools; verifier checks out specified commit, runs pre-approved test cases, writes result + commit hash back. For concurrent claiming, make claim an atomic DB operation. For interruptions: track execution ID and last-active timestamp; on timeout, inspect branch, commit, and runtime state to decide resume vs. re-dispatch; accept state updates only from current execution ID.

The "don't wait for me" directive thus means: next agent opens task, knows starting commit, scope, and prior agent's leftovers; lead focuses on blocked interfaces and hard problems. Two or three agents can relay this way; adding more agents just gives them a place to start helping.

References: Anthropic "Safely scaling multi-agent teams with Claude Fable 5.2"; Anthropic "Formalizing Fermat's Last Theorem"; Wilson Lin "Scaling long-running autonomous coding" (Cursor); Nicholas Carlini "Building a C compiler with a team of parallel Claudes"; Lance Martin "Agent design patterns" and X posts.