Recursive Evolution•Florian•editedOpinion PinnedRSI: Evolution Goes Beyond Models
AI has already entered code writing, algorithm optimization, and model development. But after a task is completed, what remains may be reusable capability—or merely an answer and scattered logs. The difference becomes apparent only when a similar problem comes up again: can the system reuse what it learned, or must it pay the cost of exploration all over again? Recursive Self-Improvement (RSI) concerns how improvements are preserved, validated, and inherited. EvoMap connects experience, execution mechanisms, and organizational strategy: new experience first informs the next action and may later be consolidated into the model’s long-term capabilities; organizational experience produced through collaboration also informs the next division of labor. This continuous learning does not require every loop to operate at the same speed. Instead, experience and capability can propel one another at different rates. 1. Objects of Improvement 1.1 Execution Loops Start with the smallest Agent loop. The system receives a task, reads context, chooses actions, calls tools, and feeds environmental feedback into its next decision. The Model provides understanding and generation capabilities, while the Harness organizes prompts, memory, tools, and operating rules so that the model’s judgments can enter real execution. This loop can adjust its actions based on feedback. If code throws an error, the Agent revises it; if retrieval lacks evidence, it changes the query. Such adjustments are valuable, but they mainly serve the current task. Continuing execution does not mean that an inheritable change remains after the task ends. A system can be excellent at retrying while rediscovering the same problem in every session. For the next attempt to benefit, another path is needed: propose candidate updates from outcomes and trajectories, test them, and then let subsequent tasks use the updated state. What is added here is not merely a step called “reflection,” but distinct responsibilities for proposing candidates, accepting them, and inheriting them. Reflection explains; acceptance establishes the scope in which the explanation is useful; inheritance incorporates it into subsequent behavior. Going one step further, if the updated improvement mechanism helps generate successor updates, it begins to touch on constrained recursion. But being able to modify itself again does not mean it is more likely to produce effective improvements. It may simply repeat the same search or use a larger budget to generate more candidates. Fully autonomous development of the next generation of frontier foundation models is an even stronger proposition than this constrained chain. Execution capability, persistent improvement, and successor-improvement efficiency therefore need to be assessed separately. Architectural feedback loops indicate which changes the system permits; real gains depend on where those changes go, who uses them, and whether they improve later tasks. This also explains why different companies can all discuss self-improvement while their public results cannot be placed directly on the same capability leaderboard. 1.2 Local Gains Public materials available as of October 2026 show that the division of labor in R&D has already changed. Anthropic reports that, as of May 2026, more than 80% of code lines merged into production can be attributed to Claude; this does not cover all ad hoc scripts and experimental code. The body of its article also states that a typical engineer’s daily merged code volume in Q2 2026 was about eight times the 2024 level.[1] Models have moved from suggesting code to modifying, executing, and testing it, but an eightfold increase cannot be translated directly into an eightfold gain in R&D productivity. Lines of code measure quantity rather than quality, and Anthropic itself warns that the metric may overstate real productivity gains. Even after code output increases, goal selection, experiment interpretation, production migration, and resource allocation may still constrain R&D progress. Anthropic then used a task automation index to examine another layer of change. As of August 2026, in a fixed task basket with R&D work shares aggregated by weighting agents according to personnel input, about 26% reached the level of “AI-led, human-supervised,” while more than 90% reached “AI-collaborative” or above. No tested task category was fully autonomous.[2] These figures are not proportions of task counts or measured hours of fully unmanned R&D. The weights come from personnel’s weekly work and are approximately divided among their tasks, rather than measured item by item. Volume, division of labor, and overall progress are therefore different metrics. The September Claude Opus 5.5 system card says that internal metrics did not show a sustained, attributable twofold acceleration in overall R&D progress, and that the model could not fully replace research scientists or research engineers.[3] OpenAI’s October GPT-6 Sol / Luna system card likewise says that neither version met its AI Self-Improvement High threshold.[4] Because the two frameworks differ, their results cannot be combined into a unified RSI score, nor can they be used to deny all forms of local self-improvement. Google’s AlphaEvolve demonstrates the distinction between local and overall gains in a production system. It uses Gemini to generate and rewrite algorithms, selecting candidates through automated execution, scoring, and evolutionary search. According to the official report, a critical matrix-operation kernel in Gemini was accelerated by 23%, while total training time decreased by only about 1%; the improved Borg scheduler also continuously reclaimed about 0.7% of global compute resources on average.[5] This does not mean optimization is ineffective; it means the denominator differs. A local operation may become faster, but overall gains must be scaled by its share of the whole. More efficient resource scheduling does not show that the model is better at selecting research questions. Attribution is needed among the kernel, execution tools, model capabilities, and research process; the best local multipliers cannot simply be multiplied together to produce a recursive acceleration factor. Zhipu’s Infra Agent case further illustrates how feedback supports improvement. GLM-5.3 participated in building the GLM-5.3-Flash inference system, and the team reported that it took less than two weeks from initial adaptation to production readiness, with end-to-end throughput about three times the initial baseline.[6] This was a joint result of engineers, the Agent, and the experimental environment. The baseline was not the industry’s best implementation, so the gain cannot be attributed entirely to the Agent alone. The methodological emphasis is “dense feedback”: numerical correctness tests check for calculation errors; traces and concurrency events help locate waiting; microbenchmarks test local modifications; and end-to-end tests determine whether the gains can reach production. Each layer of assumptions has a different testing entry point, rather than asking the model to stare at a single throughput number and guess the cause. A diagnostic process that previously depended on engineers connecting the steps can therefore be better organized as an experimental process that an Agent can execute continuously. These cases show substantial progress in reliable execution and local optimization. The next design question is whether discoveries can persist and what state subsequent calls should invoke to reduce repeated exploration. 1.3 Five Kinds of State The most direct carrier of learning is model weights, but execution performance is not determined by weights alone. The same model may perform differently with a different context, tool organization, or retry rules; the same tools may produce different results when assigned to different members or organized with different communication and aggregation methods. To explain who is learning, mutable states must be separated. In the component-recombination experiment involving Microsoft Research and other collaborators, pairing the improved Harness with the original policy, and the improved policy with the original Harness, both retained gains; their combined gains also exceeded the sum of their individual gains.[7] This supports an interaction between execution mechanisms and parameter policies within the experiment’s scope, rather than attributing every change to a single model score. EvoMap divides these states into five categories of responsibility: • Data, D: experience, data, and reusable assets, determining what the system can inherit. • Harness, H: prompts, memory, skills, tools, and runtime orchestration, determining how capabilities enter execution. • Model, θ: parameters, architecture, and successor artifacts, responsible for internalizing capabilities. • Swarm, S: members, roles, communication, decomposition, aggregation, and termination policies, determining how capabilities are organized. • Meta, Π: cross-loop selection, sequencing, budgeting, and stopping policies, determining what to improve next. These are responsibility boundaries first—not a maturity checklist or five mutually exclusive physical directories. Organizational knowledge can be preserved as an explicit Organization Gene or, through controlled Model training, internalized into θ. The latter action actually writes into parameters, after which it must still be accepted based on whether it improves organizational decisions; a goal involving the organization does not exempt it from model admission criteria. Likewise, one trajectory may affect multiple states, but the same overall gain cannot be counted as an independent gain for multiple loops. A candidate must state what was actually written, while its effect is attributed separately through controls. Only after distinguishing the object and its responsibility is it possible to discuss how these states interact. Figure 1: The EvoMap architecture connects execution, experience, organization, and models through five kinds of RSI loops. Following the paths in the figure, execution trajectories return from Evolver and Hub to EvoX, showing how experience influences execution. Swarm, Self-Organize, and PEA describe how organization participates in execution. Synthesis, training, Eval, and the environment connect model production with feedback. They share experience but need not use the same update cadence. The feedback path from Swarm to Hub is labeled Meta RSI. The Hub handles experience exchange and evidence tracking, while Meta uses the feedback to choose cross-loop strategies, sequencing, and budgets. The two meet through clearly separated responsibilities. Starting with the experience path reveals how a discovery can become a capability that other Agents can use. 2. Experience Assets 2.1 Conditional Policies Adding memory to an execution loop is a natural minimum solution: store the problem, actions, and outcome, then retrieve them next time. But logs contain causal clues, incidental conditions, failed attempts, and erroneous attributions. Finding a similar record only shows that it may be relevant; it does not show that its actions are appropriate for the current environment. Human teams have a similar gap. One person fixes an issue, and the group chat retains the entire process, but another team may still be unable to reproduce the fix. This analogy illustrates a difference in responsibility: records show what happened, while procedural knowledge helps determine what to do next. It is not evidence of AI performance, but it explains why storage alone is not enough to turn experience into capability. EvoMap distinguishes Capsules from Genes because the two serve different tasks. A Capsule can hold the conditions, actions, outcomes, and evidence from one run. A Gene extracts a reusable policy while preserving evidence that allows the extraction to be audited. Extraction is not simple text compression; it turns a concrete discovery into a conditional, testable hypothesis about action. Zhipu’s publicly reported KV-cache transfer case illustrates this processing. By following traces and the Python/C++ call boundary, the team found that certain calls held Python’s global interpreter lock (GIL), preventing transfer threads in the same process from advancing promptly.[6] The fix required validating the timeline and performance under the same conditions; merely discovering that “transfer is slow” is not enough to apply a universal remedy. If this is saved as experience, it should record which path held the lock, which wait blocked another thread, how to confirm that concurrency was genuinely restored, and which changes could break thread safety. “Release the GIL” is only part of the action. Its applicability conditions, validation method, and failure handling are what make it a policy that another runtime can test. Without that information, faster propagation may simply expand the reach of erroneous application. A Gene is more like an action hypothesis than a compressed answer. After reading it, the recipient must still match the model, Harness, dependency versions, and task environment before deciding whether to adopt, modify, isolate, or reject it. One success is not permanent authorization; the value of reuse comes from reducing repeated exploration, not from eliminating judgment in the target environment. 2.2 Feedback Learning Once conditional policies are specified, an upstream question remains: is the feedback used for extraction trustworthy? Code unit tests can provide relatively clear signals, but quality, difficulty, and reward on open-ended tasks may not. If feedback is biased, a highly standardized asset format may merely preserve that bias more completely. The same trajectory can take different paths. Tool-call sequences and failure-avoidance patterns enter Agent Genes; training records, negative examples, and curricula enter Training Genes; member selection, task decomposition, and aggregation failures enter Organization Genes. Consumers and validation targets differ, so one aggregate score cannot declare that all states have upgraded simultaneously. The Data path is therefore not merely sample accumulation. In R-Zero, involving Tencent, the Challenger and Solver co-evolve: the former proposes tasks near the solver’s capability frontier, and the latter learns to solve them, creating a self-generated curriculum.[8] The learning target includes “what to practice next,” but “zero data” does not mean the foundation model had no pretraining data, nor that the reward rules, algorithms, or validation were autonomously designed by the model. When a task requires a rubric rather than direct acceptance, the reward provider can also learn. Kimi K2’s self-evaluation uses the model as a critic to provide feedback, then updates the critic with on-policy, verifiable-reward trajectories so that it adapts to the latest policy.[9] DeepSeek-V4 instead discloses that the generative policy model itself serves as the generative reward model, jointly optimizing generation and evaluation capabilities.[10] Meta’s 2024 Self-Taught Evaluators iteratively trains evaluators with synthetic preference and judgment data, reporting that Llama3-70B-Instruct’s RewardBench score improved from 75.4 to 88.3.[11] This is a result for that model and benchmark, not a universal accuracy rate for all evaluators. It supports the claim that evaluation capability can improve, but not that self-evaluation is inherently reliable. These approaches connect task generation, experience extraction, reward judgment, and policy updates. Generators and judges may become stronger together, but they may also share blind spots. A design can allow feedback mechanisms to learn while preserving their connection to real tasks and independent acceptance. Where feedback should enter still depends on the corresponding gains and boundaries; progress in “self-evaluation” does not authorize every update. 2.3 Shared Boundaries A policy that is reliable locally may not work across agents. Changes to models, tool permissions, and task distributions can alter the conditions under which it applies. Adding a Hub therefore means more than adding another storage address: source, version, applicability, and revocation must become part of a shared protocol. MetaExp, involving Alibaba, further distinguishes solving problems from learning to use experience. It trains models to acquire, update, and reuse experience through Shared-Tool and Shared-Workflow task families. During downstream evaluation, the weights are frozen and the skill library starts empty. The authors report gains on unseen tasks and also find that, under the same evolution protocol, the control foundation model’s accumulated experience actually declined.[12] Materials of the same form do not guarantee that different models will use them equally well. The Hub is better suited to discovery, tracking, comparison, and revocation than to acting as a global brain. It supplies candidate assets, sources, and validation histories; recipients decide how to use them for concrete tasks and return results that refine their applicability boundaries. Registration, exchange, or shared trust scores cannot replace benefit testing in the target environment. Sharing can also become self-reinforcing: a policy is easier to retrieve, so more Agents use it; increased adoption then makes it appear more reliable. If later evaluation relies on the same explanation, repeated use may be mistaken for repeated validation. Forwarding one log multiple times still yields only one piece of original evidence, and another model’s agreement does not equal reproduction in the target environment. Source, reproduction, and realized benefit should therefore be recorded separately. After source and format checks, an asset can begin as an isolated, low-privilege, reversible experimental hypothesis and expand only after validation under target conditions. Cross-agent propagation or inclusion in training requires separate permission, provenance, and risk admission; one success does not grant unlimited reuse rights. Figure 2: Experience is distilled into a Gene, validated in the target environment, and only then reused. The output of the asset cycle includes not only more Genes, but also narrower conditions, rejected hypotheses, and revocable policies. A later failure should change the scope of applicability rather than automatically be attributed to a weak recipient. Selection, isolation, and forgetting are part of continuous learning; once experience begins influencing division of labor and collaboration, organizational rules themselves must enter this cycle. 3. Organizational Learning Experience can leave a single execution and become the basis for another Agent’s actions, but reusable capability does not mean a group has learned to collaborate. A three-layer loop diagram places execution, capability evolution, and group inheritance at different levels. What expands outward is not the number of retries for one task, but the way improvements are preserved and the scope over which they operate. Figure 3: Execution, capability evolution, and group collaboration form three mutually nested loops. The small AgentLoop lets the Model perform perception, decision-making, execution, and feedback within the Harness; the Ralph Loop sends it back into execution. The large AgentEvolution loop distills and synthesizes experience, then validates and solidifies it into versioned, conditional state whose effects are tested by subsequent tasks. The carrier may be an external policy, execution mechanism, or weights; solidification does not mean it can never be revoked. The AgentSwarm hyperloop concerns how capabilities are inherited across agents and then used in collaboration to create new capabilities and experience. Inheritance can occur through distillation, internalization, and asset reuse. Consensus coordinates action and responsibility, but emergence requires combined gains on real tasks and cannot be inferred from headcount. The object of group learning also includes the organization itself: whether it will better select, divide, aggregate, and stop next time. 3.1 Self-Organization When expanding from one Agent to a team, the simplest approach gives members and a task graph externally, after which each member claims a subtask. This can increase execution capability, but leaves “why organize it this way” outside the system. The same models, tools, and budget do not guarantee the same result under different divisions of labor. EvoMap places Self-Organize before Plan to make organization a first-class variable: first choose a single Agent, a fixed team, or an open Swarm; assign roles, communication, budgets, and validation responsibilities; and only then decide the concrete decomposition and dependencies. Organization influences the granularity of planning, while new dependencies exposed by planning may require organizational adjustments. The two must correct each other. A fixed directed acyclic task dependency graph (DAG) is not the same as a fixed organization. The same graph can be paired with different members, communication methods, and aggregation methods. Only when those choices are also fixed externally is the system mainly executing a predetermined configuration. The key question is not who generates the DAG, but which organizational variables can be modified, accepted, and inherited based on results. “Organize first” does not require selecting the ideal team before understanding the task at all. The system can first analyze coarse task characteristics to form an initial organization, then adjust it based on planning and execution feedback. This sequence protects the independent status of organizational decisions; it does not create a one-time step chart that can only be executed. Otherwise, even with the right sequence, organization has not been learned. 3.2 Recursive Collaboration Kimi Agent Swarm has demonstrated dynamic division of labor and inference-time compute scaling. Public materials report up to 100 sub-Agents, more than 1,500 tool calls, and wall-clock acceleration of up to roughly 4.5 times relative to sequential execution.[13] These figures can demonstrate execution performance, but do not independently show lower total cost or continuous evolution of organizational policy. A learned orchestration policy may include cross-task learning, so dynamic division of labor, policy updates, and the independent gains from those updates must be distinguished separately. EvoMap’s PEA (Plan—Execute—Aggregate) must also answer: after execution ends, should the system continue, change the plan, or change the organization? A system with only decomposition, execution, and concatenation may excel at expanding the task tree while lacking an explicit position for judging whether expansion is useful. • Plan: define subtasks, dependencies, and acceptance conditions. • Execute: produce outcomes, traces, blockers, and resource consumption. • Aggregate: check evidence sufficiency and conflicts, then decide whether to repair, replan, reorganize, or stop. Aggregate is therefore not a text merger but the place where a decision about returning results is made. If the plan omitted dependencies, the system can return to Plan. If roles or collaboration structure caused the problem, it should return to Self-Organize. If the expected benefit of continuing is insufficient, it should stop. Continuously expanding the task tree without recognizing when not to continue is merely recursive resource consumption. This is first an intra-task control structure. Cross-task learning additionally requires distilling organizational choices, failure attributions, and validation results into Organization Genes, which pass through the Hub into the next Self-Organize. Returning to Plan solves the immediate problem, while returning experience to the next organization changes later choices; the two should not be conflated merely because both involve feedback. An Organization Gene cannot store only a successful topology. It must also explain why a task suits that combination, which roles provide independent information, which aggregation exposes conflicts, and when adding members becomes ineffective. What should be inherited next time is the basis for the choice—not the fact that “we used many Agents last time.” Figure 4: Organizational experience from a task is validated and enters the next round of self-organization. The three-loop diagram divides scope into execution, evolution, and group levels; task recursion, organizational experience loops, and meta-strategy improvement describe different actual changes. They do not correspond one-to-one. In particular, the hyperloop cannot be equated directly with Meta, which must also change how it selects future improvement directions based on the gains and costs of the individual loops. 3.3 Organizational Inheritance Whether an organization can learn depends on what it inherits, not on how much its membership grows. In Anthropic’s automated research experiments, research Agents given differentiated initial directions maintained greater diversity of ideas and improved search more effectively than Agents given identical prompts; groups with identical prompts were more likely to converge on a few methods.[14] The initial directions were still set by humans, so this is not proof of fully autonomous organization, but it shows that headcount and effective diversity are different things. Different role names do not imply different cognitive paths. If members rely on the same material, the same evaluation, and the same obvious hypothesis, the organization may amplify correlated errors while increasing the burdens of communication, context copying, merging, and validation. Quality, wall-clock time, token usage, GPU use, and human effort should be reported separately. The optimization objective and resource constraints should be stated first, rather than combining different units after the fact into an “overall gain.” The effect of organizational experience can be identified through clear controls: fix the model, tools, and task distribution; compare a fixed organization, a dynamic organization, and a dynamic organization with experience reuse under comparable budgets; then perform local ablations on key roles, communication, and aggregation. Only then can the relationship between organizational choices and task outcomes be explained concretely. If gains come from a stronger model or a repaired tool, they cannot all be credited to organizational experience. If failure comes from an external service, it cannot directly be judged an error in an Organization Gene. The relationship among interventions, conditions, and outcomes must be preserved before deciding which parts to continue, modify, or reject next time. What organizational learning should inherit is “which kinds of tasks are suited to which forms of collaboration under what budgets.” A reliable organization should also know when to fall back to a single Agent, retain a serial context, or stop early. Consensus can coordinate action but cannot define truth; after one collaboration succeeds, subsequent collaborations must still face examination. 4. Loop Coordination 4.1 Differential-Speed Linkage Once both experience and organization can learn, externalization and internalization need not be mutually exclusive. For the same new experience, the key relationship is when it can enter execution and when it can become a model’s long-term capability. The two paths may take effect sequentially or continuously exchange feedback. The fast loop uses Harness RSI on the execution side: a task produces outcomes and feedback; Data RSI stores operating conditions and evidence as Capsules and distills reusable policies into Genes. After source, version, applicability, and effect checks, experience can enter the next task and influence context, skills, tool use, and Harness updates. This process still invokes the model’s reasoning capability, but does not require weight modification before new experience can first be used. The slow loop uses Model RSI on the internalization side: knowledge and experience are organized into training corpora and, through training, weight updates, evaluation, and release, become capabilities the model can invoke later. The minutes-to-hours and days-to-weeks scales in the figure indicate orders of magnitude between two update cadences; the gears are a mechanistic analogy, not a fixed gear ratio or cycle. Figure 5: Agent Infra connects immediate experience and long-term capability at different speeds. The value of Agent Infra is to keep both loops at their own cadences while allowing improvements to flow between them. The fast loop drives the slow loop by turning accumulated, verifiable experience into training candidates that give the model learning input from real tasks. The slow loop feeds back into the fast loop: model capability supports Harness execution, while changes in model capability produce new task performance and experience. Caching and reuse send existing discoveries back into the next action, reducing repeated exploration. EvoMap occupies this interface. The same new experience can first take effect in the fast loop and later have an opportunity to enter the weights. The time window between these two effects allows the system to continue adapting outside the model’s update cycle. Source, version, applicability, and runtime feedback jointly constrain the experience’s scope, bringing timeliness and reliability into reuse. Fast-loop experience is one input to model learning, and models can also learn directly from world knowledge. Synthesis in Figure 1 connects experience, seeds, and data strategies, organizing materia…
Comments
…