What Anthropic actually published
The setup: "Dozens of Claude agents collaborated to define concepts, prove intermediate theorems, and use those theorems to prove ever harder statements." The harness was Claude Code-based, and the run consumed "about six billion output tokens from a general-purpose internal research model roughly comparable to Claude Fable 5.1." Human mathematical input was minimal — Anthropic quotes the entire genre of it: "Jacobian as a scheme sounds high priority," "push [the] Mazur [theorem] to be done soon."
Then the failure, and the fix. "The effort succeeded when we switched to using Prove2Me, an open collaborative platform for formalizing mathematics designed by Tianyi Peng and his collaborators at Columbia University." Anthropic lists exactly what Prove2Me contributed, in three bullets:
"Maintaining a directed acyclic graph (DAG) of theorem statements that agents used to decide what proofs they should attempt next. This was particularly helpful for mitigating memory degradation and allowing multiple agents to work in parallel."
"Speeding up Lean compilation and minimizing resource consumption by separating theorem statements and proofs into different files, with the links between them maintained independently."
"Enabling search and reuse by maintaining a natural-language description of each theorem statement, resulting in a simpler proof path."
Read those as three properties of a store rather than three features of a math tool.
The first is externalization with dependency structure. The record of what is proved, and what each result depends on, lives outside every agent. Anthropic's phrase for what this fixed is worth keeping: "mitigating memory degradation." Not "coordinating work" — mitigating degradation of what the agents held.
The second is separating the claim from the evidence. Statements go in one place, proofs in another, and "the links between them maintained independently." Anthropic frames the benefit as compilation speed and resource consumption, which is true. The consequence for an agent is that you can read the entire set of established claims without dragging along the bodies of the proofs. The index stays cheap to consult as the corpus grows past thirteen million lines.
The third is plain-language descriptions for retrieval. Every theorem statement carries a natural-language description, and the stated purpose is "enabling search and reuse." Formal statements are exact and terrible to search. A description is inexact and findable. Without it, an agent needing a result that already exists cannot locate it and proves it again.
And then the detail that says most about which of these mattered. Anthropic ran a smaller version of the whole thing: "Anthropic researchers did a small experiment using three personal Claude Max plans to formalize applications of the Hardy-Littlewood Circle Method. Collaborating entirely through Prove2Me, the agents jointly completed a formalization of Vinogradov's Three Primes Theorem in just three days." Their conclusion: "We think with the right scaffold, collaborative formalization of major results with consumer AI subscriptions is achievable."
Three consumer subscriptions and the same scaffold produced a named theorem in three days. The scaffold was doing a lot of the work.
What this does and doesn't change
It does not show that agents need external memory to be capable. The agents were extremely capable, including in the failed attempts — Anthropic notes their unsuccessful work still contributed a real share of the non-boilerplate lines in the final proof. Capability was never the bottleneck.
It does show what breaks first at scale, and it is not reasoning. It is knowing what is already true. Every one of the three Prove2Me properties is about that question: what is established, what does it depend on, and can I find it. When a run has dozens of participants and thirty thousand established results, "what do we already know" becomes the dominant cost, and no participant can hold the answer.
It does not mean context windows are irrelevant. A bigger window helps any individual agent do more per session. It also does not scale to this: thirteen million lines of Lean and 30,300 proved theorems are not a context-window problem at any plausible size, and more importantly they are not a retrieval solution — having material in a window is not the same as knowing which part of it settles your current question. That distinction is the whole argument in why long context isn't memory.
And it does not mean this generalizes to a claim about all agent memory. Formal mathematics is an unusually friendly domain for a shared record: statements are unambiguous, dependencies are explicit, and a checker decides truth. Your codebase has none of those properties. What transfers is not the DAG; it is the three properties, which hold anywhere.
What people will take from this, and shouldn't
"It's a to-do list." The DAG is the part that answers "what next," and it is the least transferable of the three. Your work does not decompose into a dependency graph of provable statements. The transferable parts are the separation of claim from evidence and the plain-language description, both of which are about finding what is settled, not about assigning work.
"So we need a graph database." No. The graph exists because theorem dependencies are genuinely a graph. What you need is a record of established conclusions that is cheap to consult and possible to search. The data structure follows from your domain.
"Consumer plans are enough now." Anthropic said something narrower and hedged it: with the right scaffold, collaborative formalization "is achievable." The claim is about the scaffold's leverage, not about plan tiers being interchangeable.
"Claude has a memory problem." Wrong reading of a company publishing its own failed attempts. Anthropic documents memory features across its products, and this run used an internal research model in a custom harness. The accurate statement is architectural and applies to every vendor: dozens of parallel agents working for eleven days on one artifact cannot hold a shared, growing record of what is established, and the fix is to put that record outside all of them. Anthropic's willingness to publish the failure is what makes the finding usable.
The Fix: build the record with the three properties, not the graph
Step 1: Write down conclusions, and keep them separate from the work that produced them
The Prove2Me move that matters most for ordinary projects is separating statements from proofs "with the links between them maintained independently." The engineering equivalent: keep the conclusion in one place and the evidence where it already lives.
The conclusion is one sentence. "The reconciliation job must not use the batch endpoint." The evidence is the incident ticket, the pull request, the thread where you worked it out. Do not copy the evidence into the record — link it. An agent that needs to know the constraint reads one sentence. An agent that needs to know why reads one sentence and then follows one link.
This is the discipline that keeps a record usable as it grows. The common failure is the opposite: a store full of transcripts and long documents, where finding the settled answer means reading the whole argument again. That is an archive, and an archive of everything resolves nothing.
Step 2: Give every entry a plain-language description written for the search you will actually run
Prove2Me attached a natural-language description to each theorem statement specifically to enable "search and reuse." The formal statement was already there. It was not findable.
Your equivalent problem is worse, because your conclusions are already in prose and you will assume that makes them searchable. It does not, if the prose uses your vocabulary from the day you wrote it. A record entry titled "streaming parser decision" will not be found by an agent working on a memory regression in the ingest path six months later.
Write the description with the words someone would use to look for it, including the failure symptoms. "Ingest path uses the streaming parser, not the batch loader, because the batch loader held the full payload in memory and caused OOM restarts under large uploads." That reads redundant and it is exactly what makes it retrievable.
Step 3: Put it where every participant reads the same copy
The failed attempts failed because each agent was maintaining its own picture. One shared, external record was the fix — and "shared" has to include the participants you add later, and the humans.
Practically this means one store, reachable over a protocol rather than baked into one tool. If the record lives in a folder in one repository, the agent in the next service cannot see it. If it lives in one editor's local store, your teammate cannot. Both of those are how a good record quietly becomes a personal one, which is the failure mode we walked through in Claude Code agent teams and context.
Setting this up in MemoryLake
MemoryLake is a store built around those three properties: conclusions held separately from the material behind them, described for retrieval rather than for filing, and readable by every agent and person on the project over one interface. It is not a proof assistant and it does not do formal verification; it is the ordinary-work version of the layer Anthropic's run could not do without.
Step 1: Create an API key
Generate a key and make your first request in about thirty seconds. One key is what makes "every participant reads the same copy" true rather than aspirational.

Step 2: Upload your first memories
Drop in the documents, images, and files that already hold your settled conclusions — postmortems, architecture decision records, the design review everyone cites. Then add the one-line conclusions those documents actually established, so the short version is retrievable without reading the long one.

Step 3: Connect your AI & agents
Give Claude, Codex, OpenClaw, and other agents access over MCP or the API. Read at the start of a task, write back the conclusion when a decision is made, and the record stays current without anyone scheduling a documentation day.

What this changes in practice
Parallel agents stop duplicating work. This is the exact benefit Anthropic reported — the DAG "allow[ed] multiple agents to work in parallel" — and it does not require a graph. It requires that an agent about to solve something can find out that it is already solved.
Long projects stop degrading. "Memory degradation" is a good name for what happens on week three of any agent-heavy project: the shared understanding thins out, and the same questions get re-litigated with worse information. An external record does not fix everything, but it removes the class of problem where nobody can say what was decided.
Model changes stop being resets. The FLT run used one internal model in a custom harness; your project will change models several times a year. When the record is external, the change affects speed and cost rather than accumulated knowledge.
And the cost of adding a participant drops. Anthropic's three-subscription experiment is the strongest evidence of this in the post: the scaffold made a small setup productive on a serious problem. A new engineer, or a new agent, joining a project with a real record is doing work on day one instead of absorbing context for a month.
Best practices for a shared record on long agent projects
One sentence per conclusion. If it needs a paragraph, the paragraph is the evidence and belongs behind a link.
Always attach the reason. A conclusion without its reason is a rule, and rules get overridden. Anthropic's agents needed dependencies for the same reason: a result you cannot justify is a result you cannot safely build on.
Describe for the search you will run later. Include failure symptoms and the vocabulary of the problem, not the vocabulary of the day you solved it.
Record supersessions explicitly. When a decision reverses, say so and when. A record that silently drops the old version cannot explain the new one.
Keep it outside any single repository or editor. The moment it is local to one, it stops being shared, and shared was the entire fix.
Conclusion
The headline result is a mathematical one, and it deserves the attention: the first complete computer-checked proof of Fermat's Last Theorem, produced in eleven days, verified by Lean against Mathlib's own statement of the theorem. Anthropic's excerpt of Claude's thinking at the moment it landed — "The FLT root reads PROVED on prove2me" — is a remarkable thing to read.
The operational result is smaller and more portable. The first attempts failed because dozens of agents "quickly lost track of the project's state," and what fixed it was a record outside all of them with three properties: dependency structure so results could build on results, claims stored separately from the evidence behind them so the record stayed cheap to read, and a plain-language description on every entry so anything already established could be found again. Then the same scaffold, running on three consumer subscriptions, produced another named theorem in three days.
None of that is about mathematics. It is about the fact that on any long project with more than one participant, the binding constraint stops being capability and becomes knowing what is already true. Anthropic's run needed a place to write that down. So does yours.