The Past and Present of Gödel Machines: The Research Path Toward RSI

A coding agent can fix a program, yet the next time it encounters an error, it may still follow the same process of debugging, editing, and testing. The task outcome may have changed, but the method that produced it may not have. When the bottleneck lies precisely in that method, who is responsible for improving the program responsible for improvement? Gödel Machine (GM) [1] framed this as a proof problem concerning future utility. Over the following two decades, researchers have further rewritten programs with language models, preserved exploratory paths through version archives, and attempted to improve search and evaluation mechanisms together. The real advance along this historical path has been in making the capacity for improvement itself a designable, inheritable, and testable object. 1. Theoretical Starting Point 1.1 Self-Reference In September 2003, Jürgen Schmidhuber proposed a GM that established a rigorous formal framework for self-improvement: the system would both perform tasks and run a proof searcher. The searcher would attempt to prove that a particular program rewrite was worth executing; once the proof succeeded, the rewritten program would take over subsequent operation. The most important design choice here was placing the proof searcher itself inside modifiable software. Ordinary learning algorithms can change their policies while usually retaining a set of update rules written by humans; Gödel Machine, by contrast, allows those rules to be rewritten, so even the methods for finding and justifying the next modification can change. The name Gödel comes from Kurt Gödel's idea of self-reference: a formal system can encode statements about itself. Schmidhuber borrowed this idea to construct a machine capable of discussing, analyzing, and rewriting its own programs. The original paper's primary classification was computer logic, with artificial intelligence as a cross-classification; its contribution was a concrete formal setup and proof of properties. Figure 1.1: The original Gödel Machine places the task program, proof searcher, and rewriting program within a single analyzable system. The system preserves the initial task program, proof techniques, candidate rewritten programs, and axioms describing the hardware, initial software, environment, costs, and objectives. The proof searcher can read these descriptions and construct arguments about the effects of program execution; once approved to run, the rewritten program can modify both the task program and the proof searcher. The system does not need to keep adding an immutable meta-layer: the program responsible for making modifications is itself an object of modification. The original theory placed the effects of subsequent modifications into the current decision's utility comparison, allowing self-reference and recursive improvement to occur within the same setup. 1.2 Utility Proofs Proving that a modification is worthwhile is far stricter than proving that a new program can run. The original Gödel Machine compared two possible futures: executing the rewrite now, or continuing to run the original program, including continuing to search for other possible rewrites. The second future already includes the opportunity to wait, search, and adopt another program later. The current modification must therefore outperform the expected returns from continuing the search under the given utility objective and system description. Time spent on proof search also affects utility, competing with task execution for the machine's limited lifespan and resources. This does not require enumerating every program in the world and selecting the best one; it requires proving that switching now is better than maintaining the existing search process. Under assumptions such as consistency of the axiomatic system, the guarantees that hold are relative to the given utility function and resource conditions, and they can cover only provable modifications. GM even allows the utility function and target theorem to be modified, provided that the change is still proven beneficial under the original valid utility. Thus, modification behavior, modification methods, and the criteria for judging modifications are all constrained by the same self-referential principle. GM also explicitly addresses the limits of proofs: some genuinely useful modifications cannot be proven within the current axiomatic system, and some proofs exist but cannot be found in finite time. Adding computational resources cannot eliminate the provability boundaries inherent in a formal system expressive enough to represent arithmetic. Provably improving and actually finding an improvement are two different problems. 1.3 An Experimental Entry Point Before GM, Schmidhuber's team had already experimented with allowing policies to modify themselves. The Success-Story Algorithm (SSA) looked back on a sequence of self-modifications to determine whether they had increased the rate at which sustained returns were obtained, reverting ineffective modifications and preserving a history capable of supporting subsequent modifications. Empirical feedback and recovery mechanisms had long participated in this kind of exploration. What GM added was the requirement to place the future value of a modification within a formal proof. Thereafter, theoretical guarantees and executable self-improvement practices continued to confront their respective problems: the former require sufficiently effective proof search, while the latter require concrete systems capable of proposing modifications, testing outcomes, and handling failure. Language models provided a new general-purpose modifier capable of reading programs, interpreting runtime feedback, proposing solutions, and writing those solutions back into code. Programs thereby became objects that agents could continually manipulate. Research could use the same model component to try different tools, workflows, and diagnostic programs, then observe which changes helped subsequent tasks. Accordingly, acceptance testing had to shift from utility proofs within given axioms toward experimental comparisons under concrete tasks, budgets, and feedback conditions. In 2024, the Gödel Agent provided a self-referential agent implementation within this context. 2. The Agent Turning Point 2.1 Mutable Methods The Gödel Agent (GA) [2], published at the main ACL conference in 2025, was proposed by researchers from Peking University, the University of California, Santa Barbara, and the University of Arizona. It allows an agent to read and modify its own code, and it places routines for analyzing feedback, deciding on actions, and implementing modifications within a modifiable space. We can understand the motivation behind its design along three levels: Answer updates change this particular output; Program updates change how future tasks are completed; Update-method updates change how future problems are diagnosed, how actions are selected, and how program updates are produced. The first two kinds of updates are already common. Reflection and retries adjust answers, while automated agent design searches for new workflows. GA asks a further question: if the program that generates new workflows is itself unsuitable, can that program be rewritten as well? Figure 2.1: GA contrasts the different modifiable scopes of a fixed agent, fixed optimization rules, and a self-referential agent. When different paradigms are placed within the same diagram, the abilities provided by goal feedback, initial tools, and the underlying model still affect what solutions they can find. 2.2 A Self-Inspection Entry Point GA implements self-reference in a Python runtime. The agent reads functions, classes, and variables to obtain the current implementation; the language model proposes modifications based on the code and feedback; those modifications are then dynamically substituted through monkey patching, allowing subsequent calls to execute the new logic. GA uses self-awareness to represent inspection of its own code and runtime state, forming a program-level introspection interface. Figure 2.2: GA's perception and execution capabilities point back to its own modules, making its own program an object of operation. Recursive invocation carries the modified logic into the next round. After the current execution finishes, the new implementation continues running; errors can also be carried back into subsequent decisions as feedback. The language model's analytical capabilities begin to influence subsequent behavior through the replacement of executable programs. Figure 2.3: GA reads the runtime implementation, generates modifications, and executes the updated logic in subsequent iterations. 2.3 Shifting Strategies The “24 Game” provides a clear example of such a shift: given four numbers, combine operations to obtain 24. In one path recorded in the paper, the agent initially used an LLM-based solution method. After six unsuccessful optimization attempts, it rewrote the solution component as program search and achieved complete accuracy under that case's task setup. The set of numbers and operations in this task was suitable for enumeration, making program search an effective strategy. The approach of having the model directly reason about the answer was replaced by an enumerable, inspectable computational process. The gain came from connecting the agent to a more suitable solution program, demonstrating that an editable system can change the category of its method rather than remaining confined to its initial solution strategy. Other paths retained LLM-based solving while adding code verification and retries; improvement routines also developed finer-grained error tracking, logging, and parallel optimization. These provided observable examples of both “changes in task strategy” and “changes in the program that produces modifications.” Nevertheless, code changes in an instance cannot substitute for an independent measurement of the improver's capability. Merely rewriting a program to be more complex does not automatically show that it is better at generating subsequent improvements. Future research needs to isolate this question in its own experiments. 2.4 Failure Leaves a Trail GA's main experiments ran self-improvement loops on tasks such as DROP, MGSM, MMLU, and GPQA, then tested the resulting agents. The main control condition uniformly used GPT-3.5 for testing; in unrestricted runs, some of the higher scores came from agents proactively requesting assistance from stronger models. Program-design changes and contributions from additional model capability must therefore be considered separately. Stability observations are more explanatory. Across 100 optimization trials on MGSM, 92% experienced a temporary performance decline, 14% ultimately finished below the initial strategy, and 4% terminated unexpectedly. These categories are not mutually exclusive and cannot be added together. Unexpected termination often occurred after an agent modified the recursive-improvement module: it had broken the entry point through which it continued improving itself. Error-recovery tools therefore play a substantive role. Failure information must be preserved so that later rounds can diagnose the problem, repair it, or return to a previously effective method. Another constraint comes from the initial strategy: in the Game of 24, a stronger starting point converged more quickly, while a weaker starting point made more changes without surpassing the result of the strongest initial method. Open modification scope and an effective initial structure are complementary design choices. GA showed how a self-referential agent can operate, while leaving the problem of search processes taking wrong turns or stagnating for subsequent research. 3. Open-Ended Evolution 3.1 Darwinian If a modification goes wrong and the system retains only the current version, it may lose another path worth exploring. By 2025, open-ended archives had become an important organizational approach for this line of research. In May 2025, the Darwin Gödel Machine (DGM) [3] was proposed by researchers from UBC, the Vector Institute, and Sakana AI. It came from a different team than GA and explicitly compared its self-referential approach with GA's in the related work. DGM focuses on organizing code self-modification as open-ended exploration: select an agent from the archive, analyze evaluation logs, propose and implement modifications to its own program, run the new version, and then add versions that remain functional to the archive. The Darwin prefix carries a clear methodological meaning. Agent versions correspond to individuals, code rewrites correspond to mutations, task evaluations influence selection, successor versions inherit their parent's implementation, and the archive preserves different paths. Empirical observations drive the exploration, while intermediate versions that may become useful later are also retained. Figure 3.1: DGM alternates between implementing its own modifications and performing task evaluations across historical agent branches, accumulating versions that can continue to be explored. “Darwinian” does not mean that every generation is stronger. A version with a currently lower score may introduce new tools or structures that enable its descendants to go farther. DGM therefore preserves opportunities to select usable nodes in the archive rather than continuing only from the most recent or highest-scoring version. 3.2 Historical Value In staged-subset evaluations of SWE-bench Verified, DGM reported an improvement from 20.0% to 50.0%: candidates were first checked on 10 problems, then expanded to 60, and strong candidates were expanded further to 200. On the full Polyglot benchmark, the initial and final agents scored 14.2% and 30.7%, respectively. The two sets of results came from different task scopes and evaluation procedures. The improvements involved finer-grained file-inspection and editing tools, multiple attempts, and workflows that used another model to review candidate answers. The underlying model remained frozen, while updates occurred primarily within the agent program. In ablations, removing self-improvement or open-ended archive exploration weakened the system's ability to continue generating gains. During SWE-bench searches, iterations 4 and 56 both produced scores below their parent versions, yet continued exploration along the relevant paths still produced descendants that surpassed earlier versions. Program history therefore has two kinds of value: a version can directly perform a task, or it can serve as the starting point for producing the next generation of programs. The significance of the archive is to preserve improvement opportunities that have not yet been realized. In this implementation, DGM's archive maintenance, parent-node selection, and generation of improvement instructions are still organized by predesigned mechanisms. The agent can rewrite its own task program, but how open-ended search operates remains another layer of design. 3.3 The Selection Dilemma DGM also relies on a very natural assumption: an agent that writes better code should also be better at rewriting its own code. This assumption supports the self-improvement loop in coding tasks, but “can solve the current problem” and “will produce useful descendants next” are not exactly the same thing. As the archive grows, deciding which node to expand determines where the remaining budget is directed. A node that has already earned a high score may be difficult to improve further, while another node that currently performs modestly may contain a more extensible implementation. 4. Descendant Potential 4.1 A Lineage-Scale View In October 2025, the Huxley-Gödel Machine began shifting this scale of selection from the current individual to its descendant lineage. The Huxley-Gödel Machine (HGM) [4] was proposed by the KAUST team. Huxley refers to Julian Huxley; the paper borrows his concept of a clade, meaning an evolutionary branch originating from a common ancestor. HGM asks: should a node's value be determined solely by its present score, or should it also reflect the descendants that might be obtained by continuing the search from that node? The paper calls the mismatch between current task performance and improvement potential the Metaproductivity–Performance Mismatch. The agent that is currently best at solving problems is not necessarily the one most likely to produce better descendants. This statement advances this research path from “how to achieve a higher score” to “how to identify improvers worth investing in further.” Figure 4.1: HGM uses existing evaluations within a lineage to estimate expansion potential, distinguishing this from looking only at a current node's score. 4.2 Future Estimation The paper calls lineage-level metaproductivity clade metaproductivity, or CMP. The theoretical question is: given the remaining budget and search strategy, how good an agent can ultimately be selected from a node's lineage by continuing to explore from that node? The actual algorithm cannot directly read this future. HGM aggregates the successes and failures already observed within the current lineage, uses historical success rates to approximate future expansion value, and then allocates selection opportunities through Thompson sampling. Future lineage value, estimates derived from historical statistics, and a current node's score are three different quantities. The researchers also used descendant scores after the search ended as a reference to test whether these estimates were useful. During comparisons, they excluded evidence that directly exposed the optimal descendant, avoiding the use of the answer to predict the answer. On SWE-Verified-60 and Polyglot, the weighted Pearson correlation coefficients between the HGM metric and this retrospective reference were 0.778 and 0.626, respectively, compared with 0.285 and 0.383 for the DGM metric. Current task scores also had predictive value, but lineage evidence provided stronger signals in these settings. HGM also separates “generating a new version” from “further evaluating an existing version.” Once an experiment ends, the system can choose to expand or continue reducing uncertainty around existing candidates; a newly generated version no longer automatically consumes an entire consecutive evaluation budget. These two changes work together: lineage evidence helps select the starting point for expansion, while fine-grained evaluation helps control which candidates are worth testing further. HGM's advance comes from researchers redesigning the outer search rules and then using those rules to organize agent self-modification: the programs within a lineage evolve, while the CMP estimates and scheduling rules remain fixed in these experiments. 4.3 Theoretical Echoes HGM's relationship with DGM goes beyond citation. It adopts the initial agent from DGM's official implementation and adjusts the interfaces and runtime restrictions; the paper also thanks the DGM authors for sharing implementation experience. Schmidhuber, who proposed the original Gödel Machine, is also one of HGM's authors. This creates an interesting theoretical echo. The original GM compared the future utility of modifying now with that of continuing the search; HGM approximates the value of continued improvement with lineage statistics within a limited agent-development setup. Under assumptions such as evaluating only the final agent, allowing task trials to be repeated, and charging one unit of budget for each self-modification, the paper shows that access to the true CMP is sufficient to implement Gödel Machine decisions in that setup. This theoretical analysis does not charge proof-search budget, whereas the original GM includes proof costs in utility, so the correspondence between them is established specifically within an agent-development setup. Actual HGM still uses estimates derived from historical evaluations, whose value must be tested against task and budget controls. 5. Research Branches By this point, history has left behind three distinct objects: rewritable agent programs, accumulable version archives, and redesignable search policies. Research in 2026 is beginning to branch across more components rather than simply adding a higher layer of agents. 5.1 Improvement Mechanisms First released in March 2026, Hyperagents [5] directly extends DGM. Its specific implementation is DGM-Hyperagents, abbreviated DGM-H; DGM's authors Jenny Zhang and Jeff Clune also participated in this follow-up research. Hyperagents is the name of an agent form: a task agent performs the target task, while a meta-agent modifies the task agent and itself; both reside in the same editable program. DGM-H uses DGM's open-ended archive exploration to implement this form. Hyperagents names the agent form, while DGM-H names the specific implementation: the title emphasizes the new concept, whereas the implementation name explicitly preserves DGM's lineage. It addresses another limitation of DGM: improved coding performance may help an agent modify code, but improved paper-review capability does not automatically make it better at diagnosing and rewriting programs. Task capability and improvement capability require distinct observation positions and cannot be tied together merely because both involve coding. Figure 5.1: DGM-H retains the open archive and places the task agent and the meta-agent responsible for producing modifications into a shared editable program. GA had already opened improvement routines to modification; Hyperagents adds value by further separating the task agent from the meta-agent and organizing experiments around the transfer of improvement capability. The researchers selected agents from runs involving review and robot reward design, then transferred the entire implementation to Olympic mathematics scoring: the meta-agent was frozen, while the transferred task agent served as the starting point for producing successor versions. Across 50 rounds of agent generation, only successor task agents were allowed to continue changing; the final candidates were selected based on validation performance, after which test gains were examined. Freezing the meta-agent allowed the researchers to observe how acquired improvement methods performed in a new domain without mixing in the gains from continued self-modification within the target domain. The target task was to score existing Olympic mathematics solutions, with performance measured by agreement between predicted scores and expert scores. In the transferred implementation's initial test scores, the median was 0; after generating successors, the median across five repeated runs reached 0.630, with a 95% bootstrap confidence interval of 0.540–0.630. The initial zero included insufficient handling of the task format. Because the task and the meta-agent's source-domain implementation were transferred together, this gain describes successor-generation performance under the entire transferred starting point and cannot be treated directly as the isolated benefit of replacing only the meta-agent; a more meaningful control is that fixed improvers using the initial or DGM-custom approach still made almost no progress in the corresponding transfer setup. Openness also does not automatically outperform every manually designed structure. Hyperagents allows the system to rewrite the parent-node selection policy. It performed better than random selection, but did not surpass carefully designed handcrafted selection rules; the main experiments therefore retained fixed parent-node selection to isolate the contribution of meta-agent self-modification. 5.2 Co-Evolving Evaluation The Red Queen Gödel Machine (RQGM) [6], from June 2026, incorporates evaluators into evolution as well. It combines HGM's lineage-search ideas with Hyperagents' editable workspace, with each node simultaneously housing a task agent, an evaluator, and a meta-agent responsible for making modifications. Red Queen comes from the Red Queen hypothesis: participants face environments composed of other equally evolving participants and must continually adapt. Applied to AI, coding agents face code reviewers, paper writers face referees, and proof generators face graders; changes in the behavior being evaluated can also expose flaws in the evaluation mechanism. Fixed tests can provide clear feedback, but for the quality of papers or proofs, relying on a single set of permanently unchanging review rules may leave blind spots. GM theoretically already allowed utility objectives to change; RQGM addresses how evaluators can evolve in a controlled manner within an empirical system, and which historical evidence remains valid after an evaluator is replaced. Figure 5.2: RQGM fixes the evaluator within each stage, accepts replacements at checkpoints, and purges score records that depend on the replaced evaluator. It uses controlled utility evolution. The evaluator is fixed within a stage so that search faces the same criteria; at stage boundaries, candidate evaluators undergo tests based on independently annotated or objective outcome anchors. A generator's high score under the new scoring system is not, by itself, grounds for promoting an evaluator. After a replacement occurs, evidence records such as scores and samples that depend on the old evaluator are purged, and node and lineage statistics are recalculated; program artifacts and unrelated records are retained. For example, an article once accepted by an old reviewer may remain, together with the writing program, but its old score cannot simply be accumulated alongside scores under the new standard. As needed, the system reevaluates existing outputs with the new evaluator, avoiding the need to regenerate every work. The value of history increasingly depends on who evaluated something and under what conditions. Evaluation updates do more than replace a scoring function; they change which evidence subsequent search can trust. This also limits the meaning of the results. For example, the paper-writing experiment's reviewer acceptance rate reflects acceptance by an experimental evaluator or review panel, not actual conference acceptance rates. For difficult-to-verify tasks, the generator's progress and the evaluator's reliability need separate validation evidence. 5.3 Comparative Mutation In August of the same year, the Mendel Gödel Machine (MGM) [7] followed another branch. It inherits HGM's selection, evaluation, and expansion framework, while changing the diagnostic evidence used when generating modifications. Mendel refers to Gregor Mendel, and the name draws on the idea of identifying genetic effects through controlled comparisons. Agent code and the execution framework are treated as the genotype, while execution traces and task results are the phenotype, with different tasks corresponding to different environments. In a class of earlier implementations, editors often modified programs based on a single failure trace. Archives had already accumulated many runs, but these were mainly treated as leaderboards for selecting candidates. MGM begins turning this history into a basis for modification: how the same program fails across tasks, and how different programs act on the same task, can both help produce more targeted rewrites. Figure 5.3: MGM uses cross-task and cross-lineage evidence from version archives for three types of program modification, respectively. It retains three operators. Cloning mutation rewrites code based on a single failure trace; Reactive normative mutation compares an agent's performance across multiple tasks; Cross-lineage hybridization uses another lineage agent's trace on the same task to guide modifications to the current agent. Repeated exposure to a particular error across multiple tasks by the same agent is more likely to indicate a shared defect than an isolated failure; behavioral differences between different agents solving the same problem may provide transferable solutions. All three operators reuse traces already accumulated through routine evaluation, without requiring the tasks to be rerun specifically for comparison. Comparative evidence enters the editor's context, while the actual code modification is still produced by an LLM. Between identifying behavioral differences and correctly rewriting the program lies another step: diagnosis and implementation. “Hybridization” therefore uses another lineage's behavior to guide modification; the correspondence between genotype and phenotype in real tasks is an analogy for explaining program inheritance, not a direct blending of the underlying model's weights. The paper analyzes the benefits of comparative modification under an additive fitness-landscape model, then tests it through controlled simulations and programming experiments. The theoretical model helps explain the mechanism, while whether real code search benefits is answered through task controls and transfer results. The archive's role expands from “deciding whom to modify next” to “helping determine how to make the modification.” MGM and RQGM thus extend different responsibilities: one enriches modification evidence, while the other enables the evaluation mechanism to update. They cannot be arranged into a replacement relationship merely according to publication order. 6. The Recursive Problem 6.1 Lineage Convergence Looking back along this path, the names already reflect clear design motivations. Darwin emphasizes mutation, selection, and diverse paths; Huxley shifts the scale of selection toward descendant lineages sharing a common ancestor; Mendel brings behavioral comparison into the modification process; Red Queen allows evaluators and task agents to change togeth…

RSI GödelMachine 自我改进开放式进化 Agent