Suppose your research agent finishes a costly computation and hands you an answer. Would you inspect the runtime first, or test the answer? In a Google DeepMind working paper, the first complete root produced during the formal 1024-bit run was wrong. An earlier 498-bit rehearsal had already computed roots for several targets; a storage-index overflow appeared only at full scale.
That incident makes the paper useful beyond its cryptographic result. It documents what the agents were allowed to do, how spending was gated, and how a failed answer was diagnosed. If you want an agent to carry a research job beyond a short demo, the question is not just whether it can finish. It is what would let you accept the result.
The experiment computed a root, not an RSA private key
The working paper is titled “Modular Roots from a Restricted Oracle: Faster Affine Roots and a 1024-bit Computation.” Its oracle is a mathematical service, not a vendor: it returns e-th roots modulo a fixed composite number for allowed inputs.
The setup grants temporary access. During an offline phase, the computation chooses queries and saves the answers. Only after the oracle is withdrawn is a random target drawn. The online phase must compute that target's root without asking further questions. “Online” here means the target-dependent stage, not internet access.
The reported reproduction used a 1024-bit modulus and exponent e = 65537. A separate oracle program, the only program holding the factorization, answered 4,055,916,065 advance queries. The final test checked that raising the computed x to the e-th power modulo N recovered the target t. It did not recover a private key. This is a computation with substantial prior access, not an attack on an arbitrary RSA public key alone.
Less CPU work is different from a shorter calendar
For the first root, including offline preparation, the authors report 391 CPU core-years. A core-year adds up runtime across cores, rather than describing how long one machine ran; the paper counts user and system CPU time on virtual cores. The earlier computation reported 1,380 core-years, giving a factor of about 3.5. The modulus, polynomials, factor-base bounds and algorithm were the same. The comparison measures implementation and execution, not the experimental benefit of a new algorithm.
The accounting matters. CPU usage covers jobs whose outputs were used; GPU linear algebra is listed separately, and probes and rehearsals are outside the main total. Charging linear algebra at the earlier computation's CPU cost and then including the new trial work reduces the comparison to about 3.3. That is a more informative qualification than treating the headline ratio as a complete resource bill.
The run took 3.2 days from the first full-scale sieving job to a verified root, or 3 days and 22 hours from the start of design. Peak resources were about 300,000 CPU cores and 16 GPUs. Against the earlier run's roughly five months, the authors attribute the calendar difference mainly to parallelism and explicitly do not count it as an efficiency gain. You need both clocks: one measures work, the other how aggressively resources compressed its schedule.
The useful division of labor came with spending gates
The main models are identified only as Model A and Model B. The supervisor maintained the design, budgets and acceptance checks, reviewed results and made go/no-go decisions. The executor wrote and tested code, launched distributed jobs, monitored them and diagnosed failures. A specialist handled one focused subtask. The human researcher chose the problem and instance and approved conditions for irreversible steps, but wrote no code, launched no jobs and diagnosed no faults.
What makes this more than a two-agent diagram is the order of operations. Stages began with a small probe or a 1% canary slice. Scaling required passing checks fixed in advance. The optimized program had to be checked against the original on identical inputs, so that speed did not come at the expense of records or work items needed later (matching relations in full runs, or the same prime ideals when stopping early). Before launching the oracle batch, the system also had to check that its queries covered the data the later calculation would use (the relations referenced by the linear system).
The researcher sent about 20 short messages, mostly approvals. That is a striking record of limited intervention in this case, not evidence that research agents generally need little supervision. The job had existing software, a precise mathematical objective and a large cluster. My reading is that the transferable idea is to attach resource permissions to inspectable artifacts, rather than to expect autonomy simply from naming a supervisor and an executor.
A successful rehearsal did not replace the final check
Before drawing the target, the online code had completed a rehearsal at 498 bits and computed roots for several targets. Full scale still exposed failures the rehearsal could not reach. Table 4 describes stalled descent work, an unexpectedly expensive final combination and the failed first complete answer.
In the last case, a 32-bit byte offset into stored oracle answers wrapped beyond 4 GiB. The root calculation read incorrect answers. The agents checked an identity in the saved descent state, isolated its rational and algebraic parts, and localized the error to the offset. Using a 64-bit offset fixed it without repeating the withdrawn oracle batch.
This is not a story about agents becoming error-free. It is a case for making correctness checks part of the job. A rehearsal cannot exercise every scale-dependent failure, but intermediate state can make a failure diagnosable, and an independent final constraint can reject an apparently completed result. For less determinate research, where evidence is incomplete and no single equation settles the answer, you would need a different acceptance mechanism. This example does not supply that guarantee for free.
The theoretical advance is not the computation that was run
The paper also asks how much a fixed input format restricts an oracle. It distinguishes unrestricted inputs from an affine oracle, where the caller controls a short variable part inside a fixed format. The authors prove that, once the input window reaches the square-root scale required by their theorem, two affine-oracle queries can simulate one unrestricted-oracle query after re-randomization. That is what the reduction does: it uses the restricted interface to answer a question that would otherwise go to the unrestricted one. The concrete boundary case with exactly half the modulus's bits variable rests on measurement, not that same proof. The short-window algorithm's cost analysis also assumes the paper's stated number-field-sieve heuristics.
Those results should not be spliced into the runtime experiment. The implemented computation used the unrestricted algorithm and did not test the short-window affine algorithm, which the authors have not run at cryptographic sizes. Mechanisms that hash inside the device are outside both oracle models. The paper explicitly says its results do not threaten current RSA deployments using 2048-bit or larger keys; cost estimates at that size remain asymptotic.
I would read this as an acceptance-test example for research agents, not a general capability claim. When you next evaluate a long-running agent, ask what intermediate evidence you can inspect, how a wrong result can be localized, and what independent test accepts the output. The elapsed-time chart can wait.