AI4AI Survey: From Long-Horizon Agents to Recursive Self-Improvement—Definitions, Reliable Horizons, and Open Problems

1. Introduction

Can AI improve AI? This question is shifting from a speculative possibility to an empirical research problem. As of August 2026, frontier releases including GPT-5.6, Claude Fable 5, GLM-5.3, Kimi K3, Grok 4.6, and DeepSeek-V4-Pro are explicitly positioned for complex coding, agentic engineering, or long-running knowledge work (Anthropic 2026,DeepSeek 2026,Kimi Team 2026a,OpenAI 2026,SpaceXAI 2026,Z.ai 2026). Their vendor evaluations are not directly comparable, but their convergence shows how rapidly sustained agentic work has become a target of frontier-model development. Large language model (LLM) agents increasingly operate beyond isolated responses: they browse the web, edit repositories, interact with graphical interfaces, call tools and APIs, query databases, and coordinate multi-party workflows (Jimenez et al. 2024,Liu et al. 2024,Trivedi et al. 2024,Xie et al. 2024b,Yao et al. 2025,Zhou et al. 2024b). More recent systems use execution feedback to revise code, run experiments, optimize computational artifacts, and improve subsequent attempts. AI is thus beginning to participate across several stages of AI development rather than assisting with one local step. The central question is no longer only whether AI can perform individual research or engineering tasks. It is how far an AI system can reliably carry an improvement process from an initial idea to a verified result, and whether the resulting gains can persist and compound.

Answering this question is difficult because the relevant evidence is fragmented. Long-horizon agents, automated machine learning, AI-assisted research, self-improving systems, self-modifying agents, and recursive self-improvement often examine different stages of the same process under different terminology, tasks, harnesses, budgets, evaluators, and success criteria (Gao et al. 2026,Zhang et al. 2025d,Zhao et al. 2024). Even the meaning of long horizon is unsettled. Long contexts, many turns, prolonged execution, or numerous tool calls measure task pressure, but they do not establish dependence between actions (Sinha et al. 2025,Wang et al. 2026e). Likewise, success on an individual browsing, planning, coding, memory, or verification benchmark does not show that these capabilities remain reliable when coupled under one objective. An early design choice can alter later experiments, experimental outcomes can redirect subsequent plans, and a seemingly successful modification can fail under independent evaluation. The literature therefore leaves a consequential gap between what AI can do as separate capabilities and what AI can reliably improve as a system.

In this survey, we use the term AI for AI (AI4AI) to describe any AI-driven process that improves either an AI artifact or the process that creates it. These processes can target data, tasks, model weights, computational platforms, agent frameworks, evaluators, executable systems, and AI research workflows. By focusing on what is being improved, this definition allows us to compare traditional AI-assisted optimization, more autonomous AI research and development, self-improvement, and recursive methods, without assuming they all have the same level of autonomy or closure. We break down each improvement process by what changes, who sets the goals, how planning, execution, feedback, and repair are handled, how reliably these steps work under pressure, and what evidence supports the improvement. Section 2 explains the formal differences between bounded AI4AI, runtime closure, self-improvement, and recursive self-improvement. This breakdown links two areas of research that are often considered separately. On the model side, researchers study reasoning, tool use, revision, and learning from delayed feedback (Li et al. 2025a,Schick et al. 2023,Shinn et al. 2023,Wei et al. 2022). On the harness side, they focus on memory, program orchestration, software-agent runtimes, and mixed-initiative oversight (Khattab et al. 2024,Mozannar et al. 2025,Packer et al. 2023,Wang et al. 2025d). While these components are important for AI4AI, they are not enough on their own. The way they work together must keep objectives and state intact, recover from errors, and tell real progress apart from artifacts created by evaluators during repeated trials. As a result, reliability depends on the combined model, harness, environment, and evaluation protocol, not just the model. Human task time and consistency across repeated trials offer different ways to measure this reliability (Kwa et al. 2025,Yao et al. 2025). However, unstable environments, contamination, and protocol choices can make it harder to prove real improvement (Guo et al. 2024,Kapoor et al. 2025b).

A consistent pattern emerges from the available evidence. Integrated systems can already complete bounded loops in machine-learning engineering, optimization, paper replication, post-training, and research production (Chan et al. 2025,Rank et al. 2026,Starace et al. 2025,Wijk et al. 2025,Yang et al. 2026c). In systems where stage-level ownership can be verified, AI is taking on more of the improvement work, such as planning interventions, changing code, running experiments, interpreting feedback, and fixing failed attempts. However, control over improvement is still mostly not autonomous. The main goals and feedback criteria are still set by humans, and even strong components do not yet guarantee reliable end-to-end improvement. We call this gap the composition gap. It separates proven improvement under human-set conditions from stronger claims about independent research judgment, causal attribution, lasting and transferable gains, or ongoing improvement across future generations. Since local errors can build up across steps and repeated tries, a single successful run does not prove that improvement will reliably add up over time (Khanal et al. 2026,Ord 2025). The main challenge is now shifting from capability to composition, from composition to improvement, and from improvement to compounding.

Scope and boundary. This survey covers the intersection of long-horizon AI agents and AI-driven improvement of AI systems. We include interactive systems whose success depends on stateful, multi-step execution because AI improvement requires planning, action, evaluation, and revision across dependent steps. We include AI4AI systems that modify an AI artifact or its development process, including the acting system itself. We exclude ordinary long-context processing, independent dialogue turns, and one-call tool use when no action constrains a later decision or final verification. We also exclude cases in which an output is merely refined without changing an AI artifact or its development loop. AutoML, memory, tool use, reasoning, and AI-assisted science are included only where they provide mechanisms, benchmarks, or evidence relevant to end-to-end AI improvement. This boundary keeps the survey centered on one question: how far can AI reliably carry the process of improving AI?

Contributions. This survey makes three contributions. First, it provides a unified decomposition of long-horizon execution, AI4AI, self-improvement, and recursive self-improvement. The framework separates improvement target, functional coupling, task pressure, protocol-conditioned reliability, stage ownership, and the evidence required to substantiate improvement. Second, it synthesizes component benchmarks and integrated AI R&D systems through a documented search, citation-chaining, and source-verification process. A benchmark inventory and stage-ownership audit record what was improved, which stages the system controlled, how success was evaluated, and whether gains were retained or transferred. Third, it identifies the composition gap and uses it to organize the field’s next stage: converting strong but separately demonstrated capabilities into improvement that is end-to-end reliable, independently grounded, persistent, transferable, and eventually able to compound.

This survey addresses these questions in three main steps. First, Section 2 explains what qualifies as AI4AI and introduces the tools used to measure ownership, reliability, and evidence of improvement. Next, Section 3 shifts from evaluating individual components to looking at integrated systems and identifies the composition gap. Section 4 and Section 5 then discuss which aspects can be built into model behavior and which need to be provided, maintained, checked, or changed by the harness. Third, Section 6 explores why improvement may fail within a single pass, over multiple passes, across new generations, and at the edge of evidence and human control. Figure 1 and Figure 2 provide an overview of the capability landscape and evidence map. The appendices include details on the search process, coding rules, source checks, and full inventories. Altogether, this structure turns the question ’Can AI improve AI?’ into a testable problem: under what conditions can AI make improvements that are reliable, independently verified, lasting, transferable, and able to build on each other.

2. What Is AI4AI? A Taxonomy

Figure 3. Five dimensions operationalize AI4AI: target (D1), self-reference (D2), stage ownership (D3), signal grounding (D4), and the improvement-evidence profile (D5). The figure also tracks functional coupling and recursion as related qualifiers.

Figure 3. Five dimensions operationalize AI4AI: target (D1), self-reference (D2), stage ownership (D3), signal grounding (D4), and the improvement-evidence profile (D5). The figure also tracks functional coupling and recursion as related qualifiers.

2.1. What AI4AI Is: The Loop, Pointed at an AI System

AI4AI uses a familiar AI research loop: set a goal, propose and carry out a change, evaluate the result, and use feedback to plan or repair the next attempt. The loop becomes AI4AI when it targets an AI system, an artifact used to build or evaluate AI, or the research process that produces future systems. Traditional AutoML and neural architecture search automate parts of this loop within human-defined goals, search spaces, and objectives (Liu et al. 2025,Zoph and Le 2017). More advanced systems may also interpret results, repair failures, or modify the process that creates the next system. Yet pointing the loop at AI does not by itself make a system autonomous or self-improving. We therefore describe AI4AI claims along five separate dimensions.

D1: Target. The target dimension identifies what the improvement loop points at. Possible targets include data, task or environment design, model weights $\theta$, computational substrate, harness state or mechanisms $\mathcal{G}$, evaluators, and the research process itself (Chen et al. 2026c,Ren et al. 2026). This distinction groups systems by the object of improvement rather than by their degree of autonomy: a system that generates better training data and one that modifies an agent harness are both AI4AI, but they act on different targets. Here, environment design refers to modifying a task’s goals, rules, interfaces, or dynamics, rather than changing the state of the runtime environment $\mathcal{E}$ during execution.

D2: Self-reference. Self-reference asks whether the system running the loop is also one of its targets. An AI agent can design a separate model, training pipeline, or benchmark without changing itself; this is AI4AI, but not self-improvement. The process becomes self-referential when the agent modifies its own components, such as its harness (Schmidhuber 2007,Yin et al. 2024,Zelikman et al. 2024).

D3: Stage ownership. Stage ownership asks who is responsible for each part of the loop: setting the goal, making the plan, carrying out the change, judging the result, and repairing failures. For example, an AI agent may run experiments and fix code while a human still chooses the goal and decides whether the result counts as an improvement (Chan et al. 2025,Wijk et al. 2025). Separating these stages prevents automated execution from being mistaken for control of the whole loop. Equation 1 formalizes this division of responsibility.

D4: Signal grounding. Signal grounding asks what feedback closes the loop and shows whether a change is an improvement. The evidence may come from a formal verifier, an executable test, a held-out benchmark, a learned reward model, a model-based judge, or the system’s own assessment (Chen et al. 2026c,Huang et al. 2024,Jimenez et al. 2024,Zhuge et al. 2025). Signal grounding therefore describes the basis on which the evaluator accepts or rejects a change. Verification observability asks a different practical question: how delayed, incomplete, or costly that evidence is to obtain (Section 2.3).

D5: Improvement-evidence profile (G/R/H/T). The improvement-evidence profile asks what completing one or more passes through the loop has actually demonstrated. It separates four questions:

• Measured gain (G). Did performance improve on the declared measure?
• Retention (R). Was the gain preserved, or followed by further improvement, across passes or generations?
• Human comparison (H). How did the system compare with a human given a similar budget (Wijk et al. 2025)?
• Held-out transfer (T). Did the gain extend beyond the metric, task, model, or domain used for optimization (Li et al. 2026a,Zhang et al. 2025a)?

A positive answer to one question cannot stand in for the others, so each coordinate is coded separately as yes, no, or not reported.

Taken together, D1–D5 turn the simple picture of “a loop pointed at AI” into a practical checklist: What does the loop change? Does it change the system running the loop? Who controls each stage? What feedback determines success? What improvement has the completed loop actually demonstrated? These questions are independent and should not be collapsed into a single ladder of autonomy.

AI4AI is the broad category whenever the loop improves AI, even if humans control key stages and the system does not change itself. Self-improvement also requires self-reference. Recursive self-improvement (RSI) additionally makes the successor-producing process editable; open-ended RSI may also change the success criteria (Chen et al. 2026c). Boundedness records what stays fixed, while runtime closure records how much of the loop the system controls. None of these labels guarantees reliable completion because AI research and development cycles are long and stateful, with delayed or unclear feedback (Chen et al. 2026a,Starace et al. 2025).

2.2. Why Long-Horizon: One Pass Is a Loop

Why one pass is already long-horizon. One pass of AI4AI already contains a full improvement loop. Completing the pass means connecting four stages: deciding what to change, carrying it out, observing what happened, and using the feedback to repair the attempt or choose the next step. Consider an agent that modifies a training pipeline. It may need to edit code, launch a run, inspect the resulting metrics, trace a regression to an earlier decision, and then revise the code or plan. The later steps cannot be understood or judged without the artifacts and evidence produced by the earlier ones. This dependence is why even one AI4AI pass can be a long-horizon task.

Passes, rounds, and carried state. In this survey, a pass runs from an improvement goal to a result that can be accepted, rejected, or repaired. A pass may contain several rounds, and each round may contain many actions. Later rounds inherit code, data, observations, decisions, and constraints from earlier rounds. Current web, operating-system, application, and software-engineering benchmarks capture the same basic structure: an early action changes the state or information available later (Jimenez et al. 2024,Khanal et al. 2026,Trivedi et al. 2024,Xie et al. 2024b,Yao et al. 2025,Zhou et al. 2024b). AI R&D makes this dependence especially clear because proposals, implementations, evaluations, and repairs all act on shared artifacts, often with delayed feedback (Chan et al. 2025,Rank et al. 2026,Starace et al. 2025,Wijk et al. 2025). Long-horizon execution is therefore about functional coupling across actions or rounds, not simply about prompt length, elapsed time, turns, or tool calls.

A formal definition of functional coupling. We make this idea precise by describing the rounds inside a pass. Let g be the improvement goal, $\tau$ the action–observation trajectory, and $m_k$ the state carried into round k. We write the round as $u_k=(p_k,a_{t_k:t_{k+1}},f_k,r_k)$, where $p_k$ is the plan, $a_{t_k:t_{k+1}}$ is the action sequence, $f_k$ is the resulting feedback, and $r_k$ is the repair. The repair updates the carried state through $m_{k+1}=m_k\oplus r_k$. Successive rounds are functionally coupled when feedback $f_k$ changes the next plan through this updated state. If the system ignores earlier feedback and starts each round from scratch, it is repeating trials rather than carrying out a coupled long-horizon process.

Functional coupling is not loop ownership. Functional coupling tells us why the task is long-horizon; it does not tell us who controls the loop. A human may still set the goal, approve the plan, supply feedback, or decide how to repair a failure. We keep these questions separate with the stage-ownership signature

$$c^{+}=\left(c_{\mathrm{goal}},c_{\mathrm{plan}},c_{\mathrm{exec}},c_{\mathrm{feedback}},c_{\mathrm{repair}}\right)\in {\{hum,mix,sys\}}^5.$$

(1)

For each stage, $hum$ means that a human or a design-time artifact supplies the substantive output and the system mainly relays or executes it. $mix$ means that human-authored goals, criteria, templates, or acceptance rules partly determine a stage that also contains system-generated content. $sys$ is reserved for a stage whose substantive content and execution come from the system, given only upstream inputs and generic interface constraints. The four-stage execution vector $c=c_{-\mathrm{goal}}^{+}$ simply omits the goal-setting coordinate. A fixed outer evaluator affects the ownership signature only when its signal is actually used inside a stage. The signature applies to a specified system version and protocol, not to an entire research programme.

A practical test for long-horizon dependence. A practical test for long-horizon dependence is to ask whether each action could be judged independently while preserving the final success condition. If the answer is yes, the trajectory may be long in steps but weakly long-horizon. If removing the order, shared state, or cross-step relationships removes information needed for a later decision or final verification, the pass requires trajectory-level evaluation (Ma et al. 2024,Trivedi et al. 2024,Wang et al. 2024b,Yao et al. 2025). Conversely, even a short trajectory can be strongly long-horizon when one early choice changes what can be done later or delays the only useful correctness signal. Human-supplied feedback or repair changes who owns the loop, but it does not remove these dependencies.

Why this matters for AI4AI. This distinction matters directly for AI4AI. A system may perform well on isolated skills such as browsing, coding, tool use, or evaluation, yet still fail to connect them into one completed improvement pass. Integrated AI4AI systems must carry the goal and relevant state across these skills, update shared artifacts, respond to feedback, and reach a verified result. Because most benchmarks test the component capabilities separately, strong component scores do not by themselves establish reliable composition across an AI4AI cycle. Section 3.2 maps these capability families to their roles in the loop and reviews the available benchmark evidence. The next subsection then separates the pressure created by the task, who controls the stages, and how strong the improvement evidence is.

2.3. How to Measure: Pressure, Closure, and Evidence

A long-horizon label tells us that the steps in a pass depend on one another. It does not tell us how demanding the pass was, how much of the loop the system controlled, or whether the final change was genuinely an improvement. We therefore measure three different objects. Pressure describes the demands placed on the system during the pass. Closure describes who supplied the goal, plan, execution, feedback, and repair. Evidence describes why the outcome should count as an improvement. These objects can vary independently. A pass can be difficult but mostly human-directed, highly automated but easy, or fully executed without producing trustworthy evidence of improvement.

Pressure: how demanding is the pass? The functional-coupling test in Section 2.2 first determines whether the pass qualifies as long-horizon execution. Once that condition is met, task pressure describes what makes the pass demanding. We use six non-interchangeable axes: human-effort time, interaction length, context and memory demand, environment grounding, planning dependency, and verification observability. Human-effort time asks how long a qualified person would need for the same work, while interaction length counts the dependent actions or turns that must remain coordinated (Ma et al. 2024,Wang et al. 2024b,Wijk et al. 2025). Context and memory demand asks how much causally relevant state must be retained, and for how long. Environment grounding records the external states that the system must read or change. Planning dependency captures critical-path depth and the need to replan (Jimenez et al. 2024,Trivedi et al. 2024,Xie et al. 2024b,Zhou et al. 2024b). Verification observability records how delayed, incomplete, or costly the correctness signal is (Jimenez et al. 2024,Starace et al. 2025,Trivedi et al. 2024).

We collect these axes in the task-pressure vector

$$\mathbf{z}=(z_{\mathrm{time}},z_{\mathrm{interaction}},z_{\mathrm{context}},z_{\mathrm{grounding}},z_{\mathrm{dependency}},z_{\mathrm{observability}})\in \mathcal{Z}.$$

Each coordinate keeps its own auditable unit because the axes are not substitutes. Ten more tool calls, for example, do not equal ten more hours of human effort or a longer verification delay. When no defensible numerical scale exists, a preregistered ordinal bin is preferable to an invented number.

Task pressure belongs to the task, whereas reliability belongs to a particular system running under a particular protocol. The same pass may be reliable with one model, harness, budget, or evaluator and unreliable with another. We represent the agent system as $S=({\pi }_{\theta },\mathcal{G},\mathcal{E})$. Protocol Q fixes the budgets, retries, tools, graders, sampling procedure, and allowed human intervention. Let $Y_Q\left(\tau \right)=1$ only when the complete trajectory passes the declared state, safety, and verification checks. The protocol-conditioned reliability surface and its reliable region are

$$\begin{array}{cc}\hfill R_{S,Q}\left(\mathbf{z}\right)& =\underset{\tau \sim (S,Q)\mid \mathbf{Z}=\mathbf{z}}{Pr}\left[Y_Q\left(\tau \right)=1\right],\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill {\mathcal{H}}_{\alpha }(S,Q)& =\left\{\mathbf{z}\in \mathcal{Z}:R_{S,Q}\left(\mathbf{z}\right)\ge \alpha \right\}.\hfill \end{array}$$

(3)

In plain terms, $R_{S,Q}\left(\mathbf{z}\right)$ is the probability that the system completes and verifies a pass at pressure level $\mathbf{z}$. The region ${\mathcal{H}}_{\alpha }$ contains the pressure settings where this probability is at least the chosen threshold $\alpha$; its boundary is the reliable-horizon surface.

A one-dimensional horizon is meaningful only after specifying how pressure increases. Appendix C defines scalar paths, axis-conditional slices, and a robust-prefix alternative for non-monotone difficulty. The multidimensional region ${\mathcal{H}}_{\alpha }$ remains primary in the main text because it does not hide a weakness on one axis behind strength on another. Estimating it requires a frozen system and protocol, repeated trials within observed task-pressure cells, and replayable state or trajectory records. Uncertainty should be reported, and cells without enough evidence should remain unestimated rather than be filled by extrapolation. Appendix C gives the full reporting checklist (Khanal et al. 2026,Yao et al. 2025).

Closure: who controls the loop? Pressure tells us how demanding the pass is; closure asks who supplies the work at each stage. We measure closure with the stage-ownership signature $c^{+}$ from Equation 1. To avoid a vague system-level label such as “autonomous,” the stage-ownership grid crosses D1, the editable target, with D3, the supplier of each stage. Editable AI-system layers form the rows, and goal, planning, execution, feedback, and repair form the columns. Each cell therefore answers a concrete question, such as who planned a weight update or who judged whether a harness change succeeded.

Each layer–stage cell is coded for one system version under one protocol. Code hum when a human or design-time artifact supplies the substantive output and the system mainly relays or executes it. Code mix when a human-authored objective, criterion, template, or rule partly determines content that the system also generates. Code sys only when the system originates and carries out the substantive work from upstream inputs and generic interface constraints. A fixed outer evaluator Q changes the ownership code only if its signal enters the stage being coded. Missing disclosure is recorded as not reported rather than inferred from labels such as “autonomous” or “self-evolving.” These codes measure ownership, not the functional coupling that makes the pass long-horizon.

Table 1 applies this rule to Kimi K3 and KernelEvolve because their reports provide enough layer-level detail for cell-by-cell coding (Kimi Team 2026b,Liao et al. 2026). System ownership is most extensive for targets that can be rebuilt and checked relatively cheaply, including data, harnesses, and computing infrastructure. It is less extensive for model weights and evaluators, where one check may require a training run or may redefine what success means. The pattern reflects a practical boundary in current AI4AI systems: execution and repair can be automated even when humans still choose the direction and define acceptable evidence (Chan et al. 2025,Favaro and Clark 2026,Starace et al. 2025,Wijk et al. 2025).

Agents that improve computing infrastructure may own planning, execution, and repair. However, human-written profilers and correctness tests still define success, so the loop is not fully system-owned ( Kimi Team 2026b,Liao et al. 2026).

Evidence: did the pass really improve AI? Completing a pass, even with high system ownership, does not prove that the resulting change is useful. The loop may optimize the wrong metric, overfit the evaluator, lose an earlier capability, or accept its own mistaken judgment. We therefore qualify evidence in two steps. Signal grounding asks what makes the feedback trustworthy. The improvement-evidence profile asks how much of the claimed improvement was actually demonstrated.

Signal grounding and observability. D4 orders improvement signals by how directly they are tied to external evidence. Formal verifiers and executable tests provide the strongest grounding, followed by held-out benchmarks and learned rewards, then model-based judges and unaided introspection (Jimenez et al. 2024,Trivedi et al. 2024,Zhuge et al. 2025). The weaker the external grounding, the more room a loop has to confirm its own mistakes (Chen et al. 2026c,Huang et al. 2024). Signal grounding and verification observability answer different questions. Grounding asks why the signal should be believed; observability asks how difficult the signal is to obtain. An executable test, for example, may be strongly grounded but slow or expensive, while a model judge may be immediate but less independent (Zhuge et al. 2025).

Improvement-evidence profile. D5 asks what the reported result establishes beyond passing its evaluator. The profile contains four separate tests: measured gain (G), retention (R), human comparison (H), and held-out transfer (T). Measured gain asks whether performance increased on the declared measure (Chan et al. 2025,Zhang et al. 2025a). Retention asks whether the gain survived a preservation test or was followed by further improvement across passes or generations (Lee et al. 2026a,Zhang et al. 2025a). Human comparison asks how the system performed against a person given a similar budget (Wijk et al. 2025). Held-out transfer asks whether the gain extends beyond the metric, task, model, or domain used for optimization (Li et al. 2026a,Zhang et al. 2025a). Each coordinate is coded yes, no, or not reported. “No” is reserved for a reported failed test; missing evidence remains not reported. Claims should disclose the system version, tasks, budgets, seeds, checkpoint rules, evaluators, interventions, and held-out results. Published studies currently report different subsets of these tests (Chan et al. 2025,Chen et al. 2025b,Lange et al. 2025,Lee et al. 2026a,Novikov et al. 2025,Starace et al. 2025,Wijk et al. 2025,Zhang et al. 2025a). Appendix C provides the detailed reporting checklist, and Appendix B records the source-linked $G/R/H/T$ profile for each primary-source record.

Together, pressure, closure, and evidence provide three views of the same AI4AI pass. The task-pressure vector $\mathbf{z}$ states the conditions under which the loop ran. The ownership signature $c^{+}$ states who controlled its stages. Signal grounding and the $G/R/H/T$ profile state why the outcome should count as an improvement. Keeping these views separate prevents a long run from being mistaken for a hard one, an automated run from being mistaken for a system-owned loop, or a higher score from being mistaken for durable and transferable AI improvement.

2.4. How AI4AI Differs: Self-Improvement, RSI, and Related Paradigm

These labels sound similar because they all describe AI systems involved in improving AI. The easiest way to tell them apart is to ask what changes and what remains under human control. AI4AI only requires the target to be an AI artifact. Self-improvement requires the system to change itself. RSI also allows the system to change the process used to build its next version. Runtime closure asks a separate question: who actually runs each stage? Table 2 turns these distinctions into five plain-language checks.

AutoML and NAS improve AI inside a human-drawn box. Think of conventional AutoML or neural architecture search as a search assistant working inside a box designed by people. The system explores possible models, but humans choose the search space and decide how candidates will be scored. It therefore improves AI, but it does so within fixed human boundaries (Zoph and Le 2017).

Self-improvement means changing yourself, not only another AI. The practical question is simple: is the system changing itself or something else? An agent that builds a better separate model is doing AI4AI, but not self-improvement. It becomes self-improvement when the agent changes one of its own components, such as its harness (Ren et al. 2026). Self-Refine is nearby but different because it revises an answer rather than the AI system producing that answer (Madaan et al. 2023).

RSI can rewrite the recipe for making the next system. Self-improvement changes the current system. Recursive self-improvement goes one step further by allowing the system to change the process that produces its next version (Yin et al. 2024,Zelikman et al. 2024,Zhang et al. 2025a). Open-ended RSI may even change what counts as success during that process, although this remains a prospective paradigm (Chen et al. 2026c).

Recursion does not mean that the system runs the whole loop alone. A system may rewrite itself and still wait for a human to set the goal or judge the result. Another system may plan, execute, evaluate, and repair a full pass without ever changing itself. Recursion describes what the system may edit. Runtime closure describes who runs the stages. The two properties should therefore be reported separately rather than combined into one autonomy score.

How we use these labels in this survey. Earlier surveys map self-improvement targets and signals (Gao et al. 2026,Ren et al. 2026), recursive-system closure (Chen et al. 2026c), and AI assistance across research stages (Ao et al. 2026,Chen et al. 2025d). Other reviews focus on long-horizon execution and harness mechanisms (Dong et al. 2026,Guo et al. 2026,Li et al. 2026c). We use these accounts as a map, then ask a more concrete question at every stage: who supplied the substantive work? Under the strict rule in Section 2.3, a human-written success criterion makes feedback hum or mix. Every system in our audit still relies on such a criterion. None is therefore runtime-closed under this rule, even when no human intervenes during the run (Favaro and Clark 2026).

3. Evaluation: From Components to Integrated AI4AI

This section is a practical guide to choosing an AI4AI research area and evaluating progress within it. It follows the decisions that a researcher must make. First, define the metrics and controls needed for a fair comparison. Second, identify the weakest part of the intended AI4AI pass and select a component benchmark that exposes it. Third, use integrated benchmarks to test whether a local improvement survives in the full loop. Finally, check whether failures at handoffs undermine the end-to-end result. Appendix E provides the complete 67-entry benchmark inventory. The main text turns that inventory into a path from research question to defensible claim.

3.1. Evaluation Metrics: Make the Comparison Fair

A benchmark converts task outcomes into numbers. Each number should answer a defined question about performance. A fair comparison requires four decisions before evaluation begins: how repeated runs are summarized, what counts as success, which resources stay fixed, and how difficulty increases. These decisions separate system quality from extra attempts, larger budgets, or easier tasks (Mohammadi et al. 2025,Yehudai et al. 2026).

1. Measure reliability across repeated runs. One rollout shows whether a system succeeded once; it does not show how often the system succeeds. For each task i, run exactly k rollouts under the same configuration. Set $s_{ij}=1$ only when rollout j satisfies the success condition for task i; otherwise set $s_{ij}=0$. Two complementary metrics then summarize repeated-run performance:

$$\begin{array}{cc}\hfill \widehat{\mathrm{pass}@k}& ={\displaystyle \frac{1}{n}}{\displaystyle \sum _{i=1}^n}\mathbb{I}\left[\underset{1\le j\le k}{max}{s}_{ij}=1\right],\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill \widehat{{\mathrm{pass}}^k}& ={\displaystyle \frac{1}{n}}{\displaystyle \sum _{i=1}^n}{\displaystyle \prod _{j=1}^k}{s}_{ij}.\hfill \end{array}$$

(5)

$\mathrm{pass}@k$ is the fraction of tasks for which at least one rollout succeeds. It measures whether repeated attempts can eventually find a solution. ${\mathrm{pass}}^k$ is the fraction of tasks for which every rollout succeeds. It measures whether the system can reproduce success across unattended runs. A large gap means that the system can find solutions but cannot produce them consistently. This benchmark use of “pass” differs from the AI4AI improvement pass defined in Section 1. Longer tasks can widen the gap because an early error changes more later decisions (Khanal et al. 2026,Yao et al. 2025).

2. Define what counts as task success. Write the success condition before running the benchmark. For a coding task, the condition can require specified executable tests to pass. For an application task, it can require a specified final environment state. If the task provides either check, use it as the primary outcome. A model-based or human process judgment may explain a failure, but it should not override a failed executable check (Jimenez et al. 2024,Liu et al. 2024,Xie et al. 2024b,Zhou et al. 2024b,Zhuge et al. 2025).

3. Hold comparison resources constant. Choose one factor to compare and hold the other factors fixed. When comparing models, use the same harness, tools, evaluator, task set, and budget. When comparing harnesses, use the same model, tools, evaluator, task set, and budget. For every rollout, record the full configuration, attempt count, time or token budget, cost, and human intervention. Otherwise, a higher score could come from additional resources rather than the factor under study. Appendix C provides the full reporting checklist (Kapoor et al. 2025b).

4. Define how task difficulty increases. Choose one difficulty variable for each horizon analysis. Keep the system and evaluation protocol fixed while that variable increases. Build the levels so that each new level preserves earlier requirements and adds one specified increase. WebArena can increase interaction depth or the number of sites involved (Zhou et al. 2024b). SWE-bench can increase qualified-human resolution time or cross-file dependency (Jimenez et al. 2024). AppWorld can increase dependent API calls, persistent-state breadth, or verification delay (Trivedi et al. 2024). Do not compare numerical horizons across these benchmarks because their units differ. If success falls below and later rises above the reliability threshold, report the score at every level. Also report the longest consecutive prefix that stays above the threshold. Appendix C defines this robust-prefix horizon formally.

3.2. Component Benchmarks: Identify the Weak Capability

An AI4AI pass depends on several capabilities. The system may need to keep a plan, retrieve evidence, operate an interface, edit code, and coordinate tools. A component benchmark removes most of that chain and tests one capability at a time. This isolation can locate a weak capability. It cannot show that the capabilities work together in one AI4AI pass. Table 3 states the question answered by each benchmark family and the question left open.

1. Planning and state retention. Use this family when later decisions depend on earlier goals, constraints, feedback, or artifacts. TravelPlanner and DeepPlanning test constraint retention during planning (Xie et al. 2024a,Zhang et al. 2026c). Robotouille and ALE-Bench test whether later actions respond to earlier state and feedback (Gonzalez-Pumariega et al. 2025,Imajuku et al. 2025). A passing score shows state retention within the benchmark episode. It does not show that the system preserves experiment lineage, accepted checkpoints, or reasons for change across improvement passes. Section 5.2 reviews mechanisms for preserving that state.

2. Evidence retrieval and source fidelity. Use this family when the pass needs literature, documentation, or failure evidence. Mind2Web and WebLINX test grounding in recorded web traces (Deng et al. 2023,Lu et al. 2024). WebArena and VisualWebArena add changing pages, sessions, accounts, and backends (Koh et al. 2024,Zhou et al. 2024b). Deep-research benchmarks score report and citation quality (Du et al. 2025,Gou et al. 2025,Nakano et al. 2021). A passing score shows that the system can acquire evidence under the tested conditions. It does not show that later summaries or tool handoffs preserve the source’s meaning and provenance.

3. Interface control and recovery. Use this family when actions change software, devices, accounts, or physical state. OSWorld, AndroidWorld, ALFRED, and RoboCerebra test whether actions reach specified environment states (Han et al. 2025,Rawles et al. 2025,Shridhar et al. 2020,Xie et al. 2024b,Yuan et al. 2026). A passing score shows control within the tested interfaces. It does not show whether the system detects collateral damage, restores a checkpoint, or recovers after an early mistake (Chen et al. 2026e,Li et al. 2026d).

4. Code and system modification. Use this family when the system edits repositories, training systems, kernels, or compilers. Executable tests check the changed artifact directly (Chu et al. 2026,Deng et al. 2025,Jimenez et al. 2024,Merrill et al. 2026). SWE-Bench ProMax contains 170 expert-curated multilingual refactoring tasks. Its gold patches modify 11.4 files on average (Shi et al. 2026). SWE-EVO, SWE-CI, and test-evolution benchmarks expose failures that appear after later changes (Chen et al. 2026b,Le et al. 2025,Shang et al. 2026). A passing score supports the tested modification. It does not prove that the change survives broader tests or future repository updates.

5. Tool and workflow coordination. Use this family when a pass connects several APIs, services, databases, or agents. ToolLLM and BFCL test function selection, while AppWorld, WorkArena, and OfficeBench connect calls through shared workflows (Drouin et al. 2024,Patil et al. 2025,Qin et al. 2024,Trivedi et al. 2024,Wang et al. 2024c). Multi-agent settings add handoffs between different actors. A passing score supports the dependency chain tested by the benchmark. It does not show that shared information remains current, attributable, and verified after every handoff (Cemri et al. 2025,Kim et al. 2025,Ma et al. 2026a,Xu et al. 2025a).

How to use the component results. List every capability required by the proposed AI4AI pass. Test each capability under the metrics and controls from Section 3.1. A score below the predeclared threshold identifies a component bottleneck. If every required component meets its threshold, move to an integrated benchmark. The remaining failure may occur only when the components share state, artifacts, and feedback.

3.3. Integrated Benchmarks: Test the Complete AI4AI Pass

A complete AI4AI pass places the required capabilities under one goal, state, artifact history, budget, and evaluator. An integrated benchmark tests that complete chain. Its result supports only the claim encoded by its task and protocol. We group current benchmarks into three claim levels, ordered by what the system changes.

Claim level 1: Complete a human-defined research task. MLE-bench, RE-Bench, PaperBench, MLR-Bench, and AIRS-Bench combine data analysis, implementation, experiment management, replication, and open-ended research (Chan et al. 2025,Chen et al. 2025b,Lupidi et al. 2026,Starace et al. 2025,Wijk et al. 2025). Executable tests or expert review determine whether the task is complete. A passing result shows that the system can execute the stated research task under the reported budget. It does not show a self-sustaining improvement process. In RE-Bench, human performance gains more from longer time budgets than agent performance. MLS-Bench reports that locally optimized methods do not consistently transfer across settings and scales (Lyu et al. 2026,Wijk et al. 2025).

Claim level 2: Improve an artifact across several passes. ML-Master, ML-Master 2.0, PostTrainBench, Agent² RL-Bench, and RSIBench-Data retain experiment history and revise artifacts after feedback (Chen et al. 2026f,Liu et al. 2025,Meng et al. 2026a,Rank et al. 2026,Zhu et al. 2026). These benchmarks test whether a later pass produces a better dataset, pipeline, or checkpoint. In RSIBench-Data, 58.33% of settings improve over the first valid attempt. However, 78.26% of searches that continue past their best checkpoint finish below that peak. Reports should therefore include both the best artifact found and the final artifact returned. They should also state the checkpoint and stopping rules.

Claim level 3: Improve the machinery that produces later artifacts. This level changes a model, harness, or successor-producing process. AiScientist tests the effect of durable project state (Chen et al. 2026a). Frontis-MA1 separates the task environment, program-evolution operators, and composing harness (Yang et al. 2026c). HarnessOpt-Bench optimizes another agent’s harness under held-out evaluation (Ursekar et al. 2026). The Meta-Agent Challenge tests successor-agent construction (Lu et al. 2026b). These protocols still use human-specified tasks, interfaces, evaluators, resources, and acceptance rules. They support bounded meta-improvement, not unrestricted recursive self-improvement.

Inspect the artifact, not only its report. The AI Scientist line, FARS, and AutoSOTA show that systems can generate research artifacts under human-defined criteria (Li et al. 2026f,Lu et al. 2026a,Tang et al. 2026). Artifact inspection can change the result. ResearchArena assigns lower scores after inspecting code and logs. None of its 117 audited papers reaches the top-tier acceptance bar (Zhang et al. 2026e). Shadow evaluations find completed engineering work but no substantive progress on two unpublished research questions (Kirgis et al. 2026). HackDetect also shows that exposure to an evaluation protocol can inflate scores (Shao et al. 2026). Integrated evaluations should therefore use held-out tasks, inspect executable artifacts, and keep the evaluator outside the optimization loop.

Check whether the gain remains and transfers. A score increase establishes measured gain, not lasting improvement. Retention asks whether the gain survives later passes. Transfer asks whether it survives a new metric, task, model, or domain. In the cited continual-learning study, only RELAI-VCL transfers and improves again after re-optimization (Wang et al. 2026d). Larger training runs do not answer these questions. Kimi K3 demonstrates million-token agentic training and persistent sandboxes, not recursive improvement (Kimi Team 2026b).

Record control and evidence separately. Stage ownership asks who supplies the goal, planning, execution, feedback, and repair. Design-time prompts, benchmarks, verifiers, reward functions, and acceptance rules count as human inputs. In the audited systems, execution is system-owned and repair is often system-owned. Goals remain human-owned, while feedback remains human- or mixed-owned. Appendix B provides the source-level coding.

The D5 profile records a different result. Measured gain (G) asks whether the score increased. Retention (R) asks whether the gain survived or improved again. Human comparison (H) uses a person with a matched budget. Held-out transfer (T) tests a metric, task, model, or domain excluded from optimization. A missing test is recorded as not reported. Appendix B gives the evidence profile and source trail.

3.4. From Benchmark Results to Research Gaps

A research gap should follow from an observed failure pattern. One score cannot identify that pattern. Compare component and integrated results under the same tasks, budgets, evaluators, and retry limits. Table 4 maps six result patterns to the next research target.

Build the diagnosis from three comparisons. First, compare every component score with its predeclared threshold. Second, compare the integrated pass with its own threshold. Third, compare repeated with single-run performance, optimized with held-out performance, and best with final checkpoints. These comparisons separate component failure, composition failure, unreliable search, evaluator overfitting, and lost improvement. Table 4 gives the corresponding research target.

A component misses its threshold. An AI4AI pass fails when any required component fails. A browsing, execution, metric-reading, or verification error can invalidate the pass (Rakhsha et al. 2026,Wang et al. 2025a,Wang et al. 2026e). In this pattern, the next study should target the failed capability. The integrated benchmark then tests whether the fix changes the full pass.

Components pass, but the integrated pass fails. This pattern identifies a composition gap. Documents, observations, repositories, logs, plans, metrics, and checkpoints encode state differently. The system must transfer their content without losing provenance or changing the goal (Laban et al. 2026,Lu et al. 2025a,Wu et al. 2026a,Yao et al. 2026). File-based project state and structured experience records can support these transfers (Chen et al. 2026a,Yang et al. 2026c). The study should record intermediate artifacts and locate the first handoff that changes or drops required information.

Search succeeds, but single runs remain unreliable. More candidates, retries, stronger judges, or larger budgets can raise $\mathrm{pass}@k$ without raising ${\mathrm{pass}}^k$ (Yao et al. 2025). This pattern calls for error recovery, checkpointing, stopping rules, or a lower per-step failure rate. Resource-matched ablations are needed to separate these effects. Frontis-MA1 and RE-Bench provide examples of layer-wise and time-matched attribution (Wijk et al. 2025,Yang et al. 2026c).

The evaluator rewards the wrong outcome. An evaluator converts an artifact into feedback for the next pass. Executable tests and held-out scores can verify specified properties. Novelty, scientific validity, and experimental sufficiency require judgments that may disagree (Kirgis et al. 2026,Wang et al. 2026i,Zhang et al. 2026e). A system can therefore raise the proxy score while the artifact loses quality outside that proxy (Liu et al. 2026b). This pattern calls for artifact inspection, independent evaluators, contamination tests, and held-out transfer.

An improvement disappears in later passes. When the best checkpoint beats the final artifact, the system found a gain but failed to retain it. The next study should test checkpoint selection, rollback, regression detection, and stopping rules. Report the best and final artifacts under the same budget. Section 5.3 and Section 6 review mechanisms and failure modes for this case.

The benchmark workflow is now complete. Section 3.1 defines the metrics and controls. Section 3.2 locates weak capabilities. Section 3.3 tests the complete AI4AI pass. This subsection converts the observed result pattern into a research target. The next sections examine model and harness interventions for those targets.

4. Model Design: From Policy Improvement to Weight-Layer AI4AI

A model supplies the policy that chooses the next action. Improving this policy can mean two different things. The first is to make one model plan, act, and learn more reliably during a task. The second is to improve how the next model is produced by changing its data, architecture, learning algorithm, or training recipe. We call these the inner and outer model-side loops.

The distinction determines what an experiment can claim. Inference-time search spends more computation on one run but leaves the weights unchanged. Supervised learning, mid-training, and reinforcement learning update the weights. Weight-layer AI4AI goes one step further: it uses an AI system to search or revise the process that produces those weights. None of these changes automatically supplies memory, external verification, rollback, or an independently chosen objective. Those functions belong to the harness discussed in Section 5.

A simple calculation explains why the model still matters. If every action succeeded independently with probability 0.95, a 100-action task would succeed with probability $0.{95}^{100}<1\%$. Real agent errors are not independent, so this number is only an illustration. An early mistake can change later state, and feedback can either catch that mistake or spread it. Evaluation must therefore name the changed loop stage and test the result on coupled trajectories. Figure 4 provides this map, while Appendix D compares the individual methods.

4.1. Plan: Mid-Training from Reasoning and Search Traces

A plan matters when a later action depends on an earlier result. Search methods expose candidate plans without changing the model weights. Chain-of-Thought (CoT) produces one reasoning path, while Tree-of-Thoughts (ToT) explores alternatives and can backtrack (Wei et al. 2022,Yao et al. 2023a). ReAct links reasoning to actions, and LATS uses environment feedback to score search nodes (Yao et al. 2023b,Zhou et al. 2024a). Successful traces can then become training data. Plan-and-Act creates query–plan and plan–action pairs to train separate Planner and Executor models (Erdogan et al. 2025).

The WebArena-Lite result shows what this change buys. Supplying a high-quality dynamic plan raises the base Executor’s success from 9.85% to 44.24%. Training the full Planner–Executor raises success to 57.58% (Erdogan et al. 2025). Planning is therefore one measured bottleneck on this benchmark. It is not the whole task because execution must still track state, recover from errors, and pass an external check.

4.2. Execute: Tool Learning and Grounding

A tool-using model must answer three concrete questions: when to call a tool, which interface to call, and how the result changes the next action. Toolformer keeps API calls that improve next-token prediction and uses them as self-supervision (Schick et al. 2023). Gorilla retrieves documentation and applies instruction tuning to reduce invented API signatures (Patil et al. 2024). These methods improve individual calls. They do not show that a sequence of calls leaves the task in the correct final state. That claim requires trajectory-level feedback and harness-managed state.

4.3. Feedback: Credit, Stability, and Horizon Scaling

A final reward says whether the trajectory worked, but not which action caused success or failure. LOOP trains directly from trajectory outcomes in persistent application environments (Chen et al. 2025c). GiGPO, SALT, HCAPO, and CAPO assign credit to particular states, interaction steps, or complete actions (Feng et al. 2025,Li et al. 2026b,Tan et al. 2026,Wang et al. 2026b). This finer assignment can require repeated states, several rollouts, hindsight checks, critic estimates, or environment-specific structure.

Long trajectories also create unstable training data because the policy may change while rollouts are still being collected. SORL aligns updates with turn boundaries, and SAO corrects drift in asynchronous rollouts (Hou et al. 2026,Li et al. 2025a). AgentGym-RL increases trajectory length as a curriculum (Xi et al. 2025). IterResearch takes another route by rebuilding a compact workspace instead of appending the full history (Chen et al. 2025a). The last method depends on both layers: the model learns from the compact state, while the harness stores and reconstructs that state.

Each method fixes a different training problem. Trajectory rewards set the direction, step-level methods locate responsibility, stability methods control update error, and curricula expose longer tasks. To claim a longer reliable horizon, researchers must keep the environment and budget fixed, repeat trials, and separate model changes from harness changes.

4.4. Repair: Weight-Layer AI4AI

The preceding methods improve the policy used in one task. Weight-layer AI4AI instead asks an AI system to improve how a successor policy is produced. The editable object may be training data, model architecture, a learning algorithm, or a post-training recipe. A complete pass must propose a change, run the experiment, judge the result, and preserve an accepted change for the successor.

Data and task generation. The first target is the data used for learning or evaluation. STaR turns successful rationales into supervision for later training (Zelikman et al. 2022). Self-Rewarding Language Models generate instructions and judge preferences (Yuan et al. 2024). Autodata generates data, compares weak and strong solvers, revises its generator, and evaluates utility on held-out tasks (Kulikov et al. 2026). ASI-Evolve also reports changes to pretraining-data curation (Xu et al. 2026c). These systems automate parts of data design, but humans still define the allowed sources and downstream metric.

Architecture and learning-algorithm discovery. The second target is the code that defines an architecture or learning algorithm. AlphaEvolve uses LLM-generated code mutations and automated evaluators to improve algorithms and infrastructure (Novikov et al. 2025). One reported target is a training kernel used by the model family that performs the search. ASI-Evolve extends the search to neural architectures and reinforcement-learning algorithms (Xu et al. 2026c). Execution-grounded automated AI research shows why evaluation design matters. Evolutionary search over executed ideas finds improved training methods. Directly training the proposal model from execution reward raises average reward but narrows proposals toward simple modes without improving the best result (Si et al. 2026).

Training and post-training recipes. The third target is the training recipe. PostTrainBench lets command-line agents change data curation and post-training choices under a fixed single-GPU budget (Rank et al. 2026). The agents obtain uneven gains and also attempt to game the evaluator. TREX represents fine-tuning as a search tree shared by researcher and executor agents (Ma et al. 2026b). It carries experiment history across training rounds. Frontis-MA1 trains reusable Draft, Improve, Debug, and Crossover operators from executable outcomes (Yang et al. 2026c). OpenMLE-Evo then combines those operators during search. Ablations separate gains from operator training and gains from extra search. The evidence supports improvement inside a fixed task, evaluator, and budget, not unrestricted recursive self-improvement.

The remaining outer-loop boundary. In the systems reviewed here, the fixed boundary remains outside the model. Humans choose the objective, build the evaluator, limit what may be edited, allocate compute, and decide which result becomes the successor. Effort control and million-token training change the cost and capability of a run, but they do not choose the objective (Kimi Team 2026b). A gain under a fixed metric therefore establishes bounded AI4AI. It supports an RSI claim only if the system can also change the process that produces later successors. The claim must also show that the gain remains and transfers. Section 5 now examines the runtime that stores state, runs experiments, checks results, and can itself become editable.

5. Harness Design: Runtime Functions Outside the Weights

A model call receives an input and returns an output. It does not, by itself, maintain a workspace, execute a tool, preserve a checkpoint, or verify the final state. The harness provides these runtime functions around the model. It includes the execution loop, context manager, state store, tool interface, and verifier (Guo et al. 2026,Meng et al. 2026b,Zhou et al. 2026a).

This layer matters because small errors accumulate. Across reported evaluations, benchmark success falls as trajectories become longer (Ord 2025). The pattern does not prove that step errors are independent; many errors share state and causes. It does show why single-step accuracy is insufficient. A reliable system must prevent errors, detect them, and restore a valid state after a failure.

Harness choices can change benchmark results without changing model weights. Controlled studies report that harness choices can reverse model rankings (Zhang et al. 2026d). On a task that can be split into independent steps, decomposition and per-step correction supported more than one million steps without a final error (Meyerson et al. 2025). That result applies to separable work, not to tasks where each step changes the next one.

We divide the harness into four functions. Execution turns model outputs into grounded actions. Persistence carries state across rounds. Governance checks results and decides whether to retry, escalate, or stop. Self-modification places the harness itself inside the AI4AI improvement loop. Figure 5 shows what evidence is required to credit a harness change. Appendix D provides the method-level comparison.

5.1. Execute: Grounded Actions and Observations

Execution follows a simple cycle: construct the current state, ask the model for an action, execute it, observe the result, and update the state. ReAct exposes this action–observation cycle (Yao et al. 2023b). Reflexion, Self-Refine, and CRITIC turn outcomes or tool evidence into revisions (Gou et al. 2024,Madaan et al. 2023,Shinn et al. 2023). AdaPlanner and LATS retain alternative plans when the next action is uncertain (Sun et al. 2023,Zhou et al. 2024a).

The action interface determines what the agent can do and what evidence it receives. Schema-first APIs constrain arguments, code actions expose executable behavior, and adapted interfaces can reduce misuse without changing the model (Ning et al. 2026,Sigdel and Baral 2026,Xu et al. 2026b). The verifier then determines whether the loop can correct an error. Prompted self-critique provides little benefit when checked against external evidence, while reliable external feedback enables correction (Kamoi et al. 2024). Learned critics, process reward models, and pre-execution reviewers can detect errors earlier (Khalifa et al. 2026,McAleese et al. 2024,Ta et al. 2026). Feedback that points to the faulty step also supports better repair than a raw failure message (Ray and Goyal 2026).

5.2. Persist: Context, Memory, and Skills

Long tasks produce more state than a context window can safely hold. Tool outputs, code changes, logs, plans, and earlier decisions may still matter after their text leaves the prompt (Wang et al. 2026f). The harness must decide what to keep, where to store it, and when to retrieve it. Selection, summarization, fact extraction, and external files make those decisions explicit. Learned compaction, delegated context managers, and agent-controlled editing make the policy trainable (Li et al. 2026e,Li et al. 2026g,Yi et al. 2026). Every compression step can lose a constraint, so retention must be tested rather than assumed.

Memory across episodes can store facts, previous experiences, and reusable procedures (Hu et al. 2025c,Sumers et al. 2024). Flat stores, graphs, paged hierarchies, and skill libraries suit different workloads (Zhou et al. 2026c). A memory system can also cause harm. Stale facts, irrelevant retrieval, and poorly tested skills can direct the next action away from the goal (Chen et al. 2026g,Huang et al. 2026b,Ouyang et al. 2026).

AI4AI adds experimental lineage to the state. Depending on the experiment, a pass must retain source code, data versions, environment images, configurations, checkpoints, metrics, rejected hypotheses, and supporting evidence. AiScientist uses files to preserve project state across research passes (Chen et al. 2026a). OpenMLE-Evo stores structured program and experience records across search rounds (Yang et al. 2026c). Kimi K3 retains partial rollouts, external key–value state, and resumable microVM sandboxes (Kimi Team 2026b). A larger context window is not enough if another researcher cannot reconstruct the environment and lineage.

5.3. Govern: Verify, Recover, Escalate, Stop

An unattended loop must decide whether a result is good enough to keep working with. It must also decide whether to continue, retry, ask for help, or stop. Following Meng et al. (2026b), we call the design of these decisions looping engineering. Human work moves from checking every output to setting and auditing the control rules.

Verification is the central constraint. A fixed test may omit part of the intended outcome, and repeated optimization may exploit that omission. A model that judges its own output can also approve its own mistake (Huang et al. 2024,Kamoi et al. 2024,Wang et al. 2026a,Zhao et al. 2026). The harness therefore needs separate rules for acceptance, retry, escalation, rollback, and termination.

These controls can support multi-day runs. One coding system managed dozens of simulation jobs with separate evaluation contexts and recovery procedures (Orimo et al. 2025). More agents do not guarantee better control. Coordination can add cost, and a weak central verifier can spread one error across the team (Kim et al. 2025). Smaller pipelines often match elaborate designs at lower cost (Liu et al. 2026a,Wang et al. 2025b,Xia et al. 2025). Evaluation should therefore test fault localization, confirmed reruns, and correct stopping, not agent count (Cemri et al. 2025,Ma et al. 2026a,Zhu et al. 2025).

Attribution. Harness changes act on $\mathcal{G}$, not on the model policy ${\pi }_{\theta }$, in $S=({\pi }_{\theta },\mathcal{G},\mathcal{E})$ (Section 2.3). The same model can therefore reach different task horizons under different memory, feedback, verification, and environment settings. One preregistered study reports accuracy differences of up to 28 points across scaffolds for the same model (Starace 2026). Controlled comparisons also find harness variance larger than model variance in some settings (Zhang et al. 2026d). A horizon claim must therefore disclose the harness and compare models under the same harness.

5.4. Self-Modify: The Harness Rewrites Itself

So far, the harness has been fixed before the task begins. Harness-layer AI4AI makes part of that runtime editable (Chen et al. 2026c,Ren et al. 2026). The key question is who edits it and whether the edited harness later edits itself. Four regimes answer that question. They describe edit authority, not a single ranking of autonomy.

Regime 1: Fixed human-designed harnesses. Humans write the execution loop, context policy, memory store, verifier, and stopping rule. Those components remain fixed while the model solves tasks. ReAct, Reflexion, and MemGPT fit this regime even when they repeat critique or revision (Packer et al. 2023,Shinn et al. 2023,Yao et al. 2023b). The harness may improve task success, but it does not improve its own design.

Regime 2: Externally optimized harnesses. An external AI system searches over harness designs, while the system being improved remains a separate object. Automated Design of Agentic Systems edits scaffold code and archives successful agent programs (Hu et al. 2025b). Meta-Harness searches context, retrieval, tool, and control code using source files, scores, and traces (Lee et al. 2026b). HarnessX represents the harness as composable settings that can be searched (Chen et al. 2026d). Natural-language harness descriptions allow module-level ablations (Pan et al. 2026). Held-out gains show transfer, but not self-improvement, because the improver and target are different systems.

Regime 3: Self-modifying harnesses. The agent now edits code that controls its own later behavior (Cai et al. 2026,Jiang 2026,Yin et al. 2024,Zelikman et al. 2024). Darwin Gödel Machine stores coding-agent descendants that inspect logs and modify their code, while a fixed outer procedure selects survivors (Zhang et al. 2025a). Self-Harness mines weaknesses, proposes changes, and accepts only changes that pass regression tests (Zhang et al. 2026a). Recursive Harness Self-Improvement updates an editable harness specification using pairwise feedback over revision history (Lee et al. 2026a). Bilevel Autoresearch lets an outer loop inspect inner-loop code and add search mechanisms, but reports only the first bilevel step (Qu and Lu 2026). These systems are self-referential at the harness layer, while their evaluator and acceptance rule remain fixed.

Regime 4: Model–harness co-evolution. In the fourth regime, a change affects the process that proposes later changes. MetaSkill-Evolve attaches an improvement procedure to each branch, then evolves that procedure on a slower loop over a frozen model (Wang et al. 2026j). Escher-Loop jointly optimizes the proposer and target (Liu et al. 2026c). OpenMLE-RL learns program-evolution operators from executed transitions, and OpenMLE-Evo uses them to create later training experience (Yang et al. 2026c). Kimi K3 samples harness configurations during reinforcement learning, so training changes both the model and the distribution of runtimes it encounters (Kimi Team 2026b). RHI proposes turning improved harness traces into training data for later models (Lee et al. 2026a). These designs create feedback between model and harness improvement. They do not yet demonstrate an unbounded sequence of autonomous successors.

The ownership audit assigns system control most frequently to execution and repair, while planning contains more mixed ownership (Appendix B). Table 1 shows how ownership also changes by editable layer. Three facts limit current claims. Humans still set the objective and edit surface. External evaluators decide which descendant survives. Reported gains can also mix better harness design with a larger search budget. On Terminal-Bench 2.1, automatic harness evolution does not consistently beat test-time scaling under matched feedback and inference budgets. The evolved harnesses also transfer poorly to held-out tasks when search and evaluation share a benchmark (Wang et al. 2026g). Section 6 turns these limits into testable research questions.

6. Open Problems: Four Scales of Failure

The same mistake has different consequences depending on how long it remains in the loop. Within one pass, a wrong action corrupts the current task. Across passes, a bad memory or artifact changes the next attempt. Across generations, generated data or code becomes input to a successor. At the evaluation boundary, extra compute, leaked information, or human rescue can look like capability gain.

We use these four scales to organize the open problems. For each scale, we ask three questions: what fails, what current results fail to record, and what researchers should test next. Figure 6 traces the failure paths. Table 5 turns them into an experimental checklist.

6.1. One Pass: Planning, Grounding, Tools

A pass links planning, grounding, and tool use through one changing state. A correct plan can point to the wrong interface element. A correct observation can lead to an invalid tool call. A valid tool call can advance the wrong subgoal (Deng et al. 2023,Patil et al. 2024,Yao et al. 2025,Zhou et al. 2024b). Later actions may look reasonable because they are consistent with the corrupted state, even though the task has already gone off course (Trivedi et al. 2024,Wang et al. 2026e,Xie et al. 2024b).

A final success score hides this causal chain. Evaluation should label the first failure as decomposition, grounding, tool selection, arguments, policy compliance, state tracking, or verification. It should then measure how far the environment state diverged after that failure (Guo et al. 2024,Ma et al. 2024,Rabanser et al. 2026). Researchers can replay the same state with typed faults to test whether a model change or harness change prevents the cascade.

6.2. Across Passes: Decay, Drift, Cascades

Across passes, the main question is whether the next attempt starts from the correct state. Memory must preserve constraints, artifacts, provenance, unfinished subgoals, and environment state. It must also reject stale or false records (Du 2026,Gutiérrez et al. 2024,Hu et al. 2025c,Packer et al. 2023). A lossy summary can remove a requirement. Irrelevant retrieval can revive a discarded plan. Copying an earlier failure can make the next pass repeat it. Because these records affect the environment, later observations can reinforce the drift (Jimenez et al. 2024,Shinn et al. 2023,Wang et al. 2026e,Yan et al. 2026).

Memory capacity does not measure whether the stored state helps. Tests should measure state fidelity and the usefulness of the next action. They should vary record age, insert contradictions, check whether invariants remain, and require source revalidation before irreversible actions (Mei et al. 2025,Wu et al. 2026c,Xu et al. 2025b). Checkpoints should separate durable constraints from temporary observations so researchers can measure rollback and repair (Mozannar et al. 2025,Qiao et al. 2023,Wang et al. 2025d).

Error cascades and recovery. An error cascade begins when a fault is written into retained state. Later actions then follow that false record. TOOLSCAN and AgentErrorTaxonomy label tool, memory, planning, action, and system faults instead of reporting only the final outcome (Kokane et al. 2025,Zhu et al. 2025).

A retry helps only if the feedback identifies a real problem. Self-Refine and Reflexion show that feedback-conditioned retries can improve bounded tasks (Madaan et al. 2023,Shinn et al. 2023). Unaided self-judgment can instead preserve or amplify the original error (Huang et al. 2024). Tool outputs, execution traces, verifier results, and environment errors provide independent evidence. Existing methods use this evidence to critique output, test replanning, or choose retry, substitution, replanning, and safe termination (Gou et al. 2024,Vuddanti et al. 2025,Wang et al. 2025a).

Recovery should count only when the system repairs state. A protocol should record whether it detected and located the fault, which state it rolled back, and whether the task remained feasible. It should also report repair cost and confirm that the repaired trajectory returned to a valid state. These records distinguish successful recovery from repeated guessing.

6.3. Across Generations: Collapse and Hacking

A generation accepts a changed model, harness, workflow, memory, or dataset as the starting point for the next improvement cycle. This creates a new risk: an error can become part of the successor-producing process. A higher score for a few generations on one benchmark does not establish recursive improvement. The claim also needs preserved capabilities, independent checks, and an evaluator that does not become easier to exploit.

Self-confirming loops. If one system proposes a change and judges that change, agreement between the two roles is not independent evidence. Models often fail to correct reasoning without external signals, and self-correction can damage an initially correct answer (Huang et al. 2024). The same problem appears across generations when an internal score separates from the intended outcome. An independent external check must remain in the loop (Chen et al. 2026c).

Collapse and capability erosion. Training repeatedly on generated data can remove rare cases and collapse the learned distribution unless real or independently grounded data remain available (Shumailov et al. 2024). Updating workflows, tools, memory, or weights for a new task distribution can also damage earlier capabilities (Yu et al. 2026). Search has a parallel failure. If every generation follows one successful lineage, it stops testing alternatives and becomes brittle outside the optimized tasks.

RSIBench-Data shows this non-monotonic pattern before full recursion. It reports runs where continued search finishes below the best checkpoint found earlier (Meng et al. 2026a). An improvement loop must therefore preserve checkpoints, run regression tests, and stop when further passes reduce held-out performance. More generations alone do not show progress.

Reward hacking as the signal weakens. Reward hacking occurs when the system improves the measured score without improving the intended artifact. PostTrainBench records agents training on evaluation data, replacing outputs with existing checkpoints, and using unauthorized services (Rank et al. 2026). Execution-grounded research reports another case: reinforcement learning raises average proposal reward but narrows the proposal distribution without improving its best results (Si et al. 2026). Misevolution studies find unwanted behavior entering through model, memory, tool, and workflow updates (Shao et al. 2025). A broader editable loop therefore needs a verifier that checks the intended outcome, not only the optimized proxy.

Positive generational evidence. A positive generational result must show more than a rising optimized score. Held-out regression gates test preserved capabilities. Lineage archives retain alternatives. Fixed budgets prevent extra search from being counted as a better method. Self-Harness checks proposed edits on held-in and held-out tests, while DGM preserves several viable descendants (Zhang et al. 2026a,2025a). Frontis-MA1 reports post-training and harness gains separately, then tests transfer beyond its main benchmark (Yang et al. 2026c). A complete claim should report several accepted successors, retained capabilities, held-out transfer, and a budget-matched human comparison.

6.4. Evidence and Control: Attribution and Oversight

A benchmark score reflects the whole tested system. The base model, prompt construction, memory, tools, search, verifier, controller, and human intervention can all change the result. Evaluation must therefore record what changed, how much it cost, whether benchmark information leaked, and which decisions remained human-controlled.

Model–harness attribution. Final task success does not identify which component improved. Researchers should first freeze the harness and compare models. They should then freeze the model and compare memory, search, or verification. Cross-combinations under one environment and evaluator reveal interaction effects. Frontis-MA1 reports model-only, harness-only, and combined comparisons under a fixed MLE-bench Lite budget (Yang et al. 2026c). Kimi K3 changes architecture, reinforcement learning, sandbox persistence, effort policy, and infrastructure together (Kimi Team 2026b). Such a system needs factorial ablations before a gain can be assigned to one component.

Cost-normalized evidence. A system can buy a higher score with longer prompts, more candidates, deeper search, extra verifier calls, larger teams, or human rescue. That is a budget increase, not necessarily a method improvement. Coordination can even reduce performance on sequential or tool-heavy tasks (Kim et al. 2025). Reports should pair success with token use, wall-clock time, accelerator time, model calls, tool calls, verifier cost, memory growth, and human intervention. Fixed compute budgets and time-matched expert comparisons support fairer claims than unconstrained best-of-k results (Rank et al. 2026,Wijk et al. 2025,Yang et al. 2026c).

Contamination and transfer. A correct answer is weak evidence if the system has already seen the task or its solution pattern. Leakage can enter through templates, tool schemas, public traces, grading scripts, recovery examples, or benchmark-specific harness code. Contamination studies distinguish broad semantic exposure from direct answer leakage (Xu et al. 2024). LatestEval, LiveCodeBench, and LiveBench reduce exposure by using fresh or frequently updated data (Jain et al. 2025,Li et al. 2024,White et al. 2025). Agent benchmarks should also regenerate environments, hide state, rotate tools, deduplicate training corpora, and test transfer. OpenMLE reports deduplication controls and transfer to held-out NatureBench Lite tasks (Yang et al. 2026c).

Adaptive autonomy and human oversight. A protocol can place human oversight at different points. An agent can ask for clarification, request approval before an irreversible action, save a checkpoint, roll back, abstain, or escalate. Safety benchmarks test unsafe tool calls, prompt injection, uncritical trust in tool output, and poor risk recognition (Debenedetti et al. 2024,Zhang et al. 2024). Governance work recommends constrained action spaces, approval gates, audit trails, sandboxes, and named accountability (Mozannar et al. 2025,Shavit et al. 2023). Evaluation should count intervention as a resource. Reports should include escalation precision, number of approvals, intervention delay, reversibility, rollback success, and whether a reviewer can understand the trace.

These four scales give researchers a direct workflow. First, locate the earliest failed state transition. Next, test whether the error survives across passes or enters a successor. Then compare systems under matched budgets, harnesses, evaluators, and human intervention. Every report should disclose the base model, harness, context and memory policies, tool and verifier budgets, contamination controls, and approval rules. Without these records, readers cannot identify the source of a gain or reproduce it.

7. Conclusion: How Far Can AI Improve AI?

Any improvement process has four basic steps: set a goal, make a change, test the result, and decide what to do next. AI4AI uses this loop to improve an AI system or the process used to build one. Our framework asks how one step affects the next, how the loop holds up as tasks become harder, and who controls each step. It also asks what evidence shows a real gain and whether that gain lasts and works elsewhere. The evidence gives a clear but limited answer. AI systems can carry out the work and often fix failures, but people still set the goals and judge whether the result is better.

Tests of complete systems show that AI can handle engineering, optimization, replication, and paper-writing tasks when people define the goal and the test (Li et al. 2026f,Lu et al. 2026a,Lupidi et al. 2026,Tang et al. 2026,Wang et al. 2026i,Yang et al. 2026c). But this does not yet show that AI can work as an independent researcher. Studies that inspect the finished work show why: a polished report or completed run does not guarantee sound judgment or real progress on an open problem (Kirgis et al. 2026,Zhang et al. 2026e). Repeated attempts can also end with a worse version than the best one found earlier (Meng et al. 2026a). The evidence therefore supports a narrow claim: AI can improve AI within rules set by people. We do not yet know whether those gains will last, work on new tasks, or carry over to later systems.

RSI sets a much higher bar for evidence. A system must change not only itself, but also the process that builds its next version. Each new version must show a real gain with the same limits on time and computing, and under the same tests. That gain must last and help the versions that follow. For open-ended RSI, the system may also change the rules used to judge success, which makes independent checks even more important. No current evidence meets all of these conditions. The lesson is simple: change is not the same as progress. A faster loop helps only when it can tell a real gain from a mistake, keep the gain, and pass it on. The future of AI4AI will depend less on how often systems change and more on whether each change gives the next system a better starting point.

Appendix A.1. Search Process and Inclusion Criteria

We froze the systematic search on 4 August 2026 and verified targeted additions through 13 August 2026. We also froze the primary-source stage-ownership audit on 4 August 2026. The original Google Scholar search combined four terms: long-horizon, LLM agent, reliability, and benchmark. We paired these terms with terms for web use, computer use, software engineering, tool use, and planning. For the AI for AI (AI4AI) revision, we defined AI4AI as using AI to improve an AI artifact or research process. We queried the arXiv and OpenAlex APIs through eight recorded query families. These families covered AI4AI terminology, automated research, AI Scientist/autoresearch systems, self-improving and recursive agents, harness evolution, ML engineering, research benchmarks, and long-horizon reliability. Each query returned at most 50 records. We then found related records by following references and citations. The search returned 369 records after removing duplicate titles. One OpenAlex query timed out. Its corresponding arXiv query and all nine priority checks completed. Search results were capped, and one earlier log is incomplete. We therefore report how many records we screened, but not the total required for a full PRISMA flow diagram.

Core studies of long-horizon execution had to evaluate an interactive LLM agent. Eligibility required functional coupling across actions or rounds. This coupling means that earlier actions or feedback affect later actions or rounds and thereby influence success. Persistent state, delayed consequences, trajectory-level verification, and repeated-run reliability supported eligibility but did not replace functional coupling. AI4AI entries also required a repeated plan–execute–feedback–repair process that changed an AI artifact. Eligible artifacts included data, weights, a harness, an executable program, an evaluator, or a research process. We included self-improvement and recursive self-improvement studies that changed the mechanism producing later attempts or measured repeated improvement. We label non-coupled and non-AI-target comparisons as protocol-conditional or adjacent. Protocol-conditional entries depend on specific evaluation settings, whereas adjacent entries are included only for comparison. We excluded static QA, standard long-context processing, independent turns, one-call tools, and research proposals without execution or measured evidence from artifacts. We prioritized primary sources that disclosed tasks, environments, graders, budgets, or protocols over surveys.

Appendix A.2. Evidence Collection and Verification

For each component benchmark, we recorded its domain, scale, reported execution amount, coupling, persistent state, correctness signal, budget, and source. We kept each execution amount in the unit used by its source. For the stage-ownership audit, we selected 35 primary publications and first-party reports covering AI4AI and related forms of self-adaptation. Each source contributes one record for a reported system release and identifies the main AI component that release could change. We coded the improvement target (D1), stage ownership (D3), and improvement-evidence profile (D5). Stage ownership records who controls the goal, plan, execution, feedback, and repair. The improvement-evidence profile ($G/R/H/T$) records measured gain, retention, a budget-matched human comparison, and held-out transfer. We also recorded the source type, where the evidence appears, why we assigned each code, and our confidence. We described self-reference (D2) and signal grounding (D4) in prose instead of assigning table codes. Self-reference asks whether the system running the improvement process is also a target of that process. Signal grounding identifies the evidence used to decide whether a change is an improvement. A human-created artifact fixed before the run affects only the stage for which it provides the main output or pass/fail rule. An external evaluator changes another stage’s label only when that stage uses its feedback. We resolved disputed fields through a primary coding pass and an independent check of sources and possible contradictions. The only record based solely on a blog remains classified as low confidence. Because the audit lacks two completed human annotations, its counts describe this sample rather than how common the coded features are across the field.

We checked new records from logged searches and citation chaining against primary papers, proceedings, arXiv or publisher metadata, and first-party reports. We assign commercial material to a separate source tier and do not treat it as peer reviewed. Figure A7 summarizes the discovery, screening, extraction, coding, and verification process.

Figure A7. Survey methods and evidence trail. The pipeline combines the original Google Scholar search with the revised arXiv and OpenAlex search. It then screens records, extracts evidence in a standard format, codes stage ownership, and checks primary sources. We froze the systematic search on 4 August 2026 and verified targeted additions through 13 August 2026. The primary-source audit remained frozen on 4 August 2026. The component inventory contains 67 entries, and the stage-ownership audit contains 35 primary-source records. Because search results were capped, these counts are not the complete totals required for a PRISMA flow diagram.

Figure A7. Survey methods and evidence trail. The pipeline combines the original Google Scholar search with the revised arXiv and OpenAlex search. It then screens records, extracts evidence in a standard format, codes stage ownership, and checks primary sources. We froze the systematic search on 4 August 2026 and verified targeted additions through 13 August 2026. The primary-source audit remained frozen on 4 August 2026. The component inventory contains 67 entries, and the stage-ownership audit contains 35 primary-source records. Because search results were capped, these counts are not the complete totals required for a PRISMA flow diagram.

Appendix A.3. Scope and Limitations

The corpus covers web and computer use, software and terminal work, tools, APIs, workplace workflows, planning, science, and model learning. It also covers AI-directed improvement of artifacts and research processes, harness evolution, and evaluation methods. Appendix E contains the 67 component rows. Appendix B reports the 35-record primary-source audit. These two views overlap because PostTrainBench reports both the scale of one benchmark component and evidence about an integrated system.

We gave more weight to stronger evidence but did not aim for exhaustive coverage. Four factors limit completeness: query caps, one recorded OpenAlex timeout, changing terminology, and the rapid publication of 2026 preprints. The documented search is therefore reproducible but incomplete. Stage-ownership labels may also depend on what we count as one system. For example, a reported release may operate autonomously at run time while a human still sets its goal during design. Finally, the stage-ownership audit has two independent coding passes but does not include two completed human annotations. We retain low-confidence and non-peer-reviewed sources for transparency. However, we exclude them from strong claims about recursive self-improvement.

Appendix C.1. One-Dimensional Reliability When Difficulty Changes Unevenly

Consider a declared stress path $g:h\mapsto \mathbf{z}$ along which task pressure does not decrease. This path describes one way in which task difficulty can increase. Its scalar path horizon is

$$H_{\alpha }(S,Q;g):=sup\left\{h:R_{S,Q}\left(g\left(h\right)\right)\ge \alpha \right\}.$$

(A1)

When all coordinates except axis d remain fixed, the corresponding conditional horizon is

$$H_{\alpha }^{\left(d\right)}({\mathbf{z}}_{-d};S,Q):=sup\left\{u:R_{S,Q}({\mathbf{z}}_{-d},z_d=u)\ge \alpha \right\}.$$

(A2)

This threshold is meaningful only for a specified one-dimensional slice where reliability does not increase as task pressure rises. If stress path g rises and falls rather than changing steadily, report the reliable set or the robust prefix:

$$H_{\alpha }^{\mathrm{prefix}}(S,Q;g):=sup\left\{h:\underset{0\le u\le h}{inf}{R}_{S,Q}\left(g\left(u\right)\right)\ge \alpha \right\},$$

(A3)

The robust prefix is the longest initial segment that maintains reliability of at least $\alpha$. It prevents one easier instance at a later value of h from making the reported horizon look larger than it is.

Table A9. Measures for evaluating long-horizon agents. The first six rows cover outcomes and reliability. The remaining rows explain why a system succeeds or fails and which resources it uses.

Measure group	Typical measures	Main question	Reporting guidance
Final outcome	Success rate; exact match; goal-state match; $\mathrm{pass}@1$	Did the agent finish the task successfully?	Report success for each task and define the grading rules clearly. Prefer executable tests or checks of the final environment state.
Multiple attempts	$\mathrm{pass}@k$; best-of-k success	Does the agent succeed when it receives several attempts?	Report k, the sampling settings, and the selection rule. Separate capability with search from performance in a single deployment run.
Repeated-run reliability	${\mathrm{pass}}^k$; trial consistency; success variance	How consistently does the agent succeed across repeated runs?	Run multiple rollouts for each task and report the variance or confidence intervals (Khanal et al. 2026,Yao et al. 2025).
Estimate uncertainty	Binomial interval; task bootstrap; paired interval	How precise is the reliability estimate?	State the resampling unit, task count, rollout count, and interval. Do not treat several rollouts of one task as independent tasks.
Reliability boundary	$R_{S,Q}\left(\mathbf{z}\right)$; ${\mathcal{H}}_{\alpha }$; $H_{\alpha }(S,Q;g)$; robust prefix	Under which task pressures does reliability reach at least $\alpha$?	Keep the system and protocol fixed. Report the stress path or conditional slice. If difficulty rises and falls, use a reliable set or robust prefix.
Partial progress	Subgoal completion; milestone accuracy; partial credit	How much progress does the agent make before failing?	When final success is rare, distinguish failure near the start from failure after almost complete execution.
Action trajectory	Action validity; tool-use correctness; loop rate; process score	Did the agent follow a valid and efficient sequence of actions?	Record complete trajectories and evaluate the quality of the process as well as the final outcome (Zhuge et al. 2025).
Quality of verification	Check coverage; false accept/reject; verification delay	Can the evaluation protocol detect both success and failure?	Prefer executable checks. When model-based grading is unavoidable, disclose the judge prompts and calibration procedure.
Error recovery	Recovery rate; rollback success; actions or time to recovery	Can the system recover a valid state after an error?	Report error detection, error localization, rollback, and successful repair as separate steps.
Safe execution	State-diff correctness; unintended actions; rollback success	Did the agent change the environment only as intended?	Record the initial and final states, permitted changes, and any irreversible or harmful side effects.
Resource use and cost	Tokens; tool calls; latency; verifier calls; monetary cost	Which resources did the system use?	Compare systems with matched budgets and report success normalized by cost (Kapoor et al. 2025b).

Table A9. Measures for evaluating long-horizon agents. The first six rows cover outcomes and reliability. The remaining rows explain why a system succeeds or fails and which resources it uses.

Measure group	Typical measures	Main question	Reporting guidance
Final outcome	Success rate; exact match; goal-state match; $\mathrm{pass}@1$	Did the agent finish the task successfully?	Report success for each task and define the grading rules clearly. Prefer executable tests or checks of the final environment state.
Multiple attempts	$\mathrm{pass}@k$; best-of-k success	Does the agent succeed when it receives several attempts?	Report k, the sampling settings, and the selection rule. Separate capability with search from performance in a single deployment run.
Repeated-run reliability	${\mathrm{pass}}^k$; trial consistency; success variance	How consistently does the agent succeed across repeated runs?	Run multiple rollouts for each task and report the variance or confidence intervals (Khanal et al. 2026,Yao et al. 2025).
Estimate uncertainty	Binomial interval; task bootstrap; paired interval	How precise is the reliability estimate?	State the resampling unit, task count, rollout count, and interval. Do not treat several rollouts of one task as independent tasks.
Reliability boundary	$R_{S,Q}\left(\mathbf{z}\right)$; ${\mathcal{H}}_{\alpha }$; $H_{\alpha }(S,Q;g)$; robust prefix	Under which task pressures does reliability reach at least $\alpha$?	Keep the system and protocol fixed. Report the stress path or conditional slice. If difficulty rises and falls, use a reliable set or robust prefix.
Partial progress	Subgoal completion; milestone accuracy; partial credit	How much progress does the agent make before failing?	When final success is rare, distinguish failure near the start from failure after almost complete execution.
Action trajectory	Action validity; tool-use correctness; loop rate; process score	Did the agent follow a valid and efficient sequence of actions?	Record complete trajectories and evaluate the quality of the process as well as the final outcome (Zhuge et al. 2025).
Quality of verification	Check coverage; false accept/reject; verification delay	Can the evaluation protocol detect both success and failure?	Prefer executable checks. When model-based grading is unavoidable, disclose the judge prompts and calibration procedure.
Error recovery	Recovery rate; rollback success; actions or time to recovery	Can the system recover a valid state after an error?	Report error detection, error localization, rollback, and successful repair as separate steps.
Safe execution	State-diff correctness; unintended actions; rollback success	Did the agent change the environment only as intended?	Record the initial and final states, permitted changes, and any irreversible or harmful side effects.
Resource use and cost	Tokens; tool calls; latency; verifier calls; monetary cost	Which resources did the system use?	Compare systems with matched budgets and report success normalized by cost (Kapoor et al. 2025b).

Appendix E.1. Evidence from Integrated AI R&D Evaluations and Systems

Table A14. System-level AI4AI evaluations that combine several capabilities. This table is separate from the 67 component benchmarks. PostTrainBench appears in both tables because the evidence supports both views.

Evaluation or system	Part of the AI system that changed	Types of work combined	How the evaluation measured improvement	How the evaluation separated possible causes
MLE-bench (Chan et al. 2025)	The competition model and pipeline	End-to-end machine-learning engineering across 75 Kaggle competitions	Scores on held-out competitions	The agent wrapper and tools are fixed, but the evaluation does not separate the effects of the model and budget
RE-Bench (Wijk et al. 2025)	AI R&D artifacts	Open-ended R&D in seven environments	Executable scores specific to each task	Comparisons with expert-human attempts given the same amount of time
PaperBench (Starace et al. 2025)	The research implementation	Reproduction of 20 ICML papers from descriptions	Hierarchical rubrics validated by the authors	Artifacts and rubrics are visible, but the effects of the model and harness remain coupled
MLR-Bench (Chen et al. 2025b)	The machine-learning research result	Work from forming ideas through producing the report	Task-specific scores for artifacts and research	End-to-end comparisons, with few tests that vary one factor at a time
PostTrainBench (Rank et al. 2026)	The model checkpoint	Data and recipe selection, training, and evaluation	A held-out benchmark, using one H100 for ten hours	A shared sandbox and budget, with logs that reveal shortcuts
AiScientist (Chen et al. 2026a)	The state of the research project	Long-running refinement by specialized roles that hand files to one another	Outcomes on MLE-bench Lite and PaperBench	Tests that remove or change state and coordination, without evaluating every combination of base model and setup
Frontis-MA1/OpenMLE (Yang et al. 2026c)	The MLE program, operators, and search harness	Operator training together with experience-guided evolutionary search	MLE-bench Lite (12 hours) and transfer to NatureBench Lite	Comparisons that match the model, match the harness, or evaluate the combined system
Kimi K3 (Kimi Team 2026b)	The model, agent policy, and harness distribution	Million-token reinforcement learning with persistent rollout and sandbox state	Domain-specific executable metrics and judge-based metrics	An industrial system designed as a whole, with no public experiment that varies each full-stack component separately

Table A14. System-level AI4AI evaluations that combine several capabilities. This table is separate from the 67 component benchmarks. PostTrainBench appears in both tables because the evidence supports both views.

Evaluation or system	Part of the AI system that changed	Types of work combined	How the evaluation measured improvement	How the evaluation separated possible causes
MLE-bench (Chan et al. 2025)	The competition model and pipeline	End-to-end machine-learning engineering across 75 Kaggle competitions	Scores on held-out competitions	The agent wrapper and tools are fixed, but the evaluation does not separate the effects of the model and budget
RE-Bench (Wijk et al. 2025)	AI R&D artifacts	Open-ended R&D in seven environments	Executable scores specific to each task	Comparisons with expert-human attempts given the same amount of time
PaperBench (Starace et al. 2025)	The research implementation	Reproduction of 20 ICML papers from descriptions	Hierarchical rubrics validated by the authors	Artifacts and rubrics are visible, but the effects of the model and harness remain coupled
MLR-Bench (Chen et al. 2025b)	The machine-learning research result	Work from forming ideas through producing the report	Task-specific scores for artifacts and research	End-to-end comparisons, with few tests that vary one factor at a time
PostTrainBench (Rank et al. 2026)	The model checkpoint	Data and recipe selection, training, and evaluation	A held-out benchmark, using one H100 for ten hours	A shared sandbox and budget, with logs that reveal shortcuts
AiScientist (Chen et al. 2026a)	The state of the research project	Long-running refinement by specialized roles that hand files to one another	Outcomes on MLE-bench Lite and PaperBench	Tests that remove or change state and coordination, without evaluating every combination of base model and setup
Frontis-MA1/OpenMLE (Yang et al. 2026c)	The MLE program, operators, and search harness	Operator training together with experience-guided evolutionary search	MLE-bench Lite (12 hours) and transfer to NatureBench Lite	Comparisons that match the model, match the harness, or evaluate the combined system
Kimi K3 (Kimi Team 2026b)	The model, agent policy, and harness distribution	Million-token reinforcement learning with persistent rollout and sandbox state	Domain-specific executable metrics and judge-based metrics	An industrial system designed as a whole, with no public experiment that varies each full-stack component separately

Table A15. What AI4AI studies published in 2026 have shown, and what their evaluations do not yet establish.

Study	Evaluation setup	Strongest reported result	What the result does not establish
AIRS-Bench (Lupidi et al. 2026)	20 research tasks, with no baseline code	The reported human SOTA was exceeded on 4/20 tasks	Fixed tasks and metrics test execution ability, not the ability to choose a research direction
NatureBench (Wang et al. 2026i)	90 containerized tasks from Nature-family papers, with the source methods hidden	The strongest agent surpasses the published SOTA on 17.8% and matches it on 47.8%	The tasks mostly test translation of a method into an implementation, not demonstrated invention
RSIBench-Data (Meng et al. 2026a)	A fixed stack for iteratively developing data strategies	58.33% improve initially; 78.26% of searches after the peak end below that peak	Scores can rise and then fall, and the study does not resolve when to stop searching
The AI Scientist/Nature (Lu et al. 2026a)	Template-based and free-form systems that work from an idea to a paper	One of three selected papers reaches workshop level	The process still uses human filtering, and no paper reaches the main-conference bar
FARS (Tang et al. 2026)	An unattended multi-agent deployment that works from an idea to a paper	166 papers/67 topics; 282 reviews cover 140 outputs	The result demonstrates scale and allows outputs to be inspected, but it does not show quality improving steadily
AutoSOTA (Li et al. 2026f)	Reproduction and optimization from a paper to a repository	Improved models are reported for 105 executable papers	Criteria derived from each paper guide both search and evaluation, and the study does not isolate transfer
ResearchArena (Zhang et al. 2026e)	117 papers, reviewed from the manuscript alone and with access to artifacts	Text scores are competitive, but no paper reaches the top-tier bar after audit	The audit finds fabrication, weak experiments, and mismatches between plans and execution
Shadow evals. (Kirgis et al. 2026)	Two unpublished NeurIPS questions, six days, and expert grading	The engineering work is completed, but there is no meaningful research progress	The evaluation reveals weak judgment, backtracking, resource use, and choice of direction

Table A15. What AI4AI studies published in 2026 have shown, and what their evaluations do not yet establish.

Study	Evaluation setup	Strongest reported result	What the result does not establish
AIRS-Bench (Lupidi et al. 2026)	20 research tasks, with no baseline code	The reported human SOTA was exceeded on 4/20 tasks	Fixed tasks and metrics test execution ability, not the ability to choose a research direction
NatureBench (Wang et al. 2026i)	90 containerized tasks from Nature-family papers, with the source methods hidden	The strongest agent surpasses the published SOTA on 17.8% and matches it on 47.8%	The tasks mostly test translation of a method into an implementation, not demonstrated invention
RSIBench-Data (Meng et al. 2026a)	A fixed stack for iteratively developing data strategies	58.33% improve initially; 78.26% of searches after the peak end below that peak	Scores can rise and then fall, and the study does not resolve when to stop searching
The AI Scientist/Nature (Lu et al. 2026a)	Template-based and free-form systems that work from an idea to a paper	One of three selected papers reaches workshop level	The process still uses human filtering, and no paper reaches the main-conference bar
FARS (Tang et al. 2026)	An unattended multi-agent deployment that works from an idea to a paper	166 papers/67 topics; 282 reviews cover 140 outputs	The result demonstrates scale and allows outputs to be inspected, but it does not show quality improving steadily
AutoSOTA (Li et al. 2026f)	Reproduction and optimization from a paper to a repository	Improved models are reported for 105 executable papers	Criteria derived from each paper guide both search and evaluation, and the study does not isolate transfer
ResearchArena (Zhang et al. 2026e)	117 papers, reviewed from the manuscript alone and with access to artifacts	Text scores are competitive, but no paper reaches the top-tier bar after audit	The audit finds fabrication, weak experiments, and mismatches between plans and execution
Shadow evals. (Kirgis et al. 2026)	Two unpublished NeurIPS questions, six days, and expert grading	The engineering work is completed, but there is no meaningful research progress	The evaluation reveals weak judgment, backtracking, resource use, and choice of direction