PaperlayerView exact revision on arXiv

Source-linked AI summary

Self-Evolving Coding Agents: From Digital Programs to Physical-World Intelligence

Hongcheng Gao, Jingjing Zhou, Zelin Zheng, Shijia Ge, Jay Zhu, Yazhe Wang, Jianshu Zeng, Xuan Shangguan, Di Wu, Lingyu He, Zhiqi Jia, Sihang Wu, Xiao He

arXiv:2609.35432v1cs.RO

TL;DR

Physical action policies leave task state and recovery implicit, complicating inspection and revision. Physical Coding makes them executable programs; HexaAnything improves RoboCasa365 Composite-Unseen success over native XR-1 VLA and completes PhyBench experiments.

  • Problem

    VLA/WAM policies encode task requirements, conditions, progress, and recovery implicitly in action sequences, making them difficult to inspect or revise.

    Source: §1 · p. 1, §3.1 · p. 7

  • Method

    Physical Coding maintains executable world and policy programs, while HexaAnything composes typed tools with observation, verification, recovery, and external feedback.

    Source: §3.3 · p. 8, §3.4 · p. 9, §9 · p. 26

  • Results

    34.3% to 38.3% Composite-Unseen success over native XR-1 VLA; HexaAnything also autonomously completes scientific experiments on PhyBench.

    Source: §1 · p. 3, §9 · p. 26

  • Takeaways & Limitations

    The evidence for Harness, data, model, and tool improvement motivates a staged path toward broader self-evolution.

    Source: §1 · p. 3

    Evidence remains preliminary: RoboCasa365 uses one action model and benchmark, PhyBench uses ten trials per model and task, and real-robot results use three trials per task.

    Source: §8.3 · p. 25

Abstract

from arXiv · show

Vision-language-action (VLA) and world-action (WAM) models map observations and instructions directly to robot actions. This directness ties a policy to training: minor layout or viewpoint changes cause failure, and instructions generalize poorly. The root cause lies in representation: task requirements, conditions, progress, and failure recovery are implicitly encoded in action sequences, making them difficult to inspect or revise. Digital coding agents offer a precedent: LLMs call tools, verify results, and revise from feedback as executable code. The same working pattern of explicit state, manageable execution, and revisable procedures underlies generalization and long-horizon execution in the physical world, letting physical experience return as reusable programs, memory, or evidence. We propose Physical Coding, representing task state and execution as code. Code as World records objects, relations, constraints, and progress; Code as Policy organizes planning, verification, recovery, and execution. We build HexaAnything, which calls perception, planning, and control tools, including VLA/WAM policies, and makes in-the-loop decisions from external feedback. Verified traces become data and memory, enabling evolution from tools and Harness to model weights, architectures, and ultimately hardware and task design. On RoboCasa365, HexaAnything improves Composite-Unseen and overall success over XR-1 VLA, and its Harness-trained HexaModel beats the base on every split, indicating code traces internalize physical execution. On PhyBench and a dual-arm AgileX robot, the agent autonomously completes physics experiments and most tabletop tasks, often faster than published results. We observe data, model, and tool self-evolution; future work targets weight internalization, autonomous redesign of architectures, languages, representations, and tasks, and deployment in manufacturing and science.

1 Introduction

The introduction argues that action-focused models leave task state, progress, and recovery implicit, then presents Physical Coding as an executable interface for representing and revising them. HexaAnything uses this interface to gather reusable execution evidence, with preliminary results across manipulation, scientific experiments, and self-evolution.

1 Introduction

  • VLA and WAM action sequences leave task requirements, progress, and recovery implicit, limiting inspection and revision during long-horizon execution.The introduction also reports failures under layout or viewpoint changes and poor instruction dependence in existing policies.Source: §1 · p. 1
  • Physical Coding represents both relevant world state and execution procedures as executable programs through Code as World and Code as Policy.These programs can be validated, edited, versioned, and rolled back, allowing experience to persist as reusable artifacts.Source: §1 · pp. 2–3
  • Successful executions can become reusable records, memories, or learning signals, while failures provide localized evidence for revising tools, workflows, predicates, and recovery procedures.The resulting model–Harness–environment loop uses evidence from one interaction to update later interactions.Source: §1 · p. 3
  • HexaAnything integrates state observation, planning, action tools, verification, recovery, and feedback collection, using general-purpose robot tools and learned VLA/WAM policies.The evaluation spans long-horizon manipulation, simulated experiments, and a real dual-arm robot.Source: §1 · p. 3
  • HexaAnything provides preliminary evidence of Harness, tool, and data-to-model improvement, and autonomously completes scientific experiments in simulated PhyBench.Full autonomous co-evolution of models, representations, environments, and embodiments remains future work.Source: §1 · p. 3

2 Background: From Action Models to Coding Agents

The background moves from action models through code-based policies and world representations to coding-agent Harnesses and self-evolving systems.

2.1 Action Models: VLA and WAM

  • VLA policies can remain largely instruction-insensitive and fail under viewpoint or layout changes, while WAM video prediction rewards plausible frames rather than correct physics.Action chunks and stop signals also leave decomposition, completion, and recovery implicit.Source: §2.1 · pp. 3–4

2.2 Code as Policy

  • Prior code-policy systems rely on trusted perception and external retries, while the proposed policy program makes verification, stopping, and recovery explicit and checks them against the world program.Execution evidence can be used to edit the policy across episodes.Source: §2.2 · p. 4

2.3 Code as World

  • Unlike per-query or per-episode representations, the proposed world program records task-relevant objects, relations, constraints, and progress predicates with observation provenance, and persists across episodes.It is checked by an independent verifier, so failed execution can add predicates or revise constraints.Source: §2.3 · p. 5

2.4 Coding Agents and Harnesses

  • Prior embodied Harnesses revise memories, skills, critics, or operating rules around fixed models, whereas this formulation trains HexaModel on execution traces that pass an independent evaluator.Typed verdicts and provenance help prevent a model from validating its own errors.Source: §2.4 · pp. 5–6

2.5 Self-Evolving Agents

  • Prior self-evolving systems often adapt one component while holding surrounding components fixed; the proposed coupled view highlights gaps in system-level measurement, attribution, and independent validation.The present report evaluates the execution interface and a first update in which Harness-collected traces train a new model.Source: §2.5 · p. 6

3 Physical Coding

Physical Coding replaces implicit action-sequence state with executable representations of the world and of the policy, linked through observation and evidence. This interface makes execution inspectable and revisable, from sensing and tool use through verification, recovery, and system updates.

3.1 Why Physical Coding?

  • Figure 3 depicts the loop in which observations update Code as World and verification against fresh evidence guides policy continuation, re-observation, recovery, or stopping.Source: Figure 3 · p. 7, §3.3 · p. 9
  • Physical Coding puts task state, procedures, and feedback in executable code, so failures can become localized edits and verified traces can train later models.The agent observes through world-state predicates, acts through tool-calling policies, and uses a verifier to assess evidence rather than accepting the model’s completion claim.Source: §3.1 · p. 7

3.2 Code as World and Code as Policy

  • Code as World records task-relevant state, while Code as Policy organizes actions; together, they make progress inspectable and proposed changes testable.Neither representation suffices alone: state without a policy cannot act or recover, while a policy without state cannot reliably express task conditions.Source: §3.2 · p. 8

3.3 How the Physical World Becomes Code

  • World entries combine image-derived scene structure, tool measurements, and robot execution state with provenance; typed policy tools support observation, action, verification, branching, and recovery.When evidence does not determine a task predicate, the policy must observe again rather than guess; plans can also specify experimental conditions and analysis code.Source: §3.3 · pp. 8–9
  • After each tool call, fresh evidence determines whether to continue, re-observe, recover, or stop; persistent traces link world entries, policy nodes, tool outcomes, and verdicts.Failures can be traced to predicates, conditions, tools, or recovery branches, and verified traces can become training data for later models.Source: §3.3 · p. 9

3.4 Physical Coding Agents: Formulation and Scope

  • A physical coding agent is the full agent–environment interface: the model interprets and synthesizes, while the Harness supplies tools, verification, execution state, permissions, and rollback.Self-evolution can update task specifications, environments, programs, Harness, model, verifier, data, or memory from prior-episode evidence; the report’s experiments cover only some evolution targets.Source: §3.4 · p. 9

4 Physical Self-Evolution

Physical self-evolution uses an executable world–policy interface to make four coupled targets revisable and independently evaluable. Execution evidence guides candidate changes, while verification and rollback preserve attribution across updates.

4.1 Overview

  • The four targets are coupled because a change to one can alter the evidence available to the others, so updates require attribution against versioned baselines and independent evaluation.For example, a new verifier changes training labels, while a changed task distribution can expose gaps in the world representation.Source: §4.1 · pp. 10–11

4.2 The Self-Evolution Loop

  • Candidate artifacts are proposed from execution evidence and retained only when independent evaluation justifies the change without violating other components’ contracts.The versioned bundle includes the world representation, policy, Harness, admitted data, memory, and evaluator configuration; a single successful rollout is insufficient for adoption.Source: §4.2 · p. 11

4.3 Harness Evolution: Tools, Workflows, and Verification

  • The Harness can evolve tools, workflows, predicates, verifiers, and recovery procedures, while Code as World and Code as Policy can themselves be revised.The interface also permits changes to object types, affordances, observation abstractions, task constraints, control decompositions, and verification schedules.Source: §4.3 · p. 12

4.4 Data and Environment Evolution

  • Verified traces connect demonstrations, memories, counterexamples, task distributions, training corpora, and environment generators to the execution loop.Simulation supplies inexpensive resets and controlled perturbations; physical environments expose noise, calibration error, contact variation, latency, and failures that simulation may omit.Source: §4.4 · p. 12

4.5 Model and Algorithm Evolution

  • The model target spans prompts and policies through parameter updates and, longer term, architecture, routing, memory, and action heads.The paper stages its model-update claim: verified traces train a new checkpoint, then reduced Harness assistance and held-out compositions test whether capabilities were internalized.Source: §4.5 · p. 12

4.6 Representation and Interface Evolution

  • The representation and interface can evolve through revised world abstractions and extensions to the executable language, primitives, schemas, or runtime.Candidate interfaces must compile or instantiate, preserve provenance, pass regression and safety tests, and improve held-out physical outcomes before adoption.Source: §4.6 · p. 12

4.7 Embodiment and Hardware Evolution

  • Embodiment and compute changes are longer-term targets, gated by compatible interfaces, safety tests, and evaluation with the model and Harness that will use them.The substrate includes sensors, actuators, morphology, accelerators, memory, networking, and scheduling; the current Harness-bootstrap experiments do not assume these changes.Source: §4.7 · p. 13

4.8 System Integration, Oversight, and Governance

  • Integration treats action models as components: the coding agent can invoke a VLA/WAM, inspect outcomes through the world program, and decide whether to continue, interrupt, or revise a subgoal.Compute allocation, human feedback, and governance—including privacy filtering of intermediate reasoning—are also treated as part of the learning system.Source: §4.8 · p. 13

5 HexaAnything: A Physical Coding Agent

HexaAnything wraps executable world and policy programs in a Harness that observes, dispatches tools, verifies outcomes, and records traces. Its staged roadmap uses validated experience to improve the Harness and model before constrained physical deployment.

5 HexaAnything: A Physical Coding Agent

  • HexaAnything combines a model that writes world and policy programs with a Harness that runs them and establishes the coding–action–state–feedback interface.Its Harness determines available observations and tools, monitors actions, evaluates evidence, and turns failures into candidate revisions.Source: §5 · p. 13

5.1 Formal System Definition

  • The Harness dispatches policy steps through tools, updates the world program from observations and outcomes, and uses typed verifier verdicts to continue, interrupt, recover, or terminate.The complete execution trace is the unit of attribution and later update; the action model supplies a possible tool, while the Harness owns bookkeeping, verification, recovery, and trace admission.Source: §5.1 · pp. 13–14

5.2 The Verifier

  • The verifier checks world-program predicates against available evidence, and verified traces require a verifier independent of the model proposing actions.Disagreements between in-episode verdicts and benchmark labels are retained as counterexamples; verifier changes are tested on a separate suite.Source: §5.2 · p. 14

5.3 Evolution Roadmap and Deployment Protocol

  • The roadmap progresses from a tool-and-feedback Harness bootstrap, through model–Harness co-evolution using validated traces, to deployment in constrained physical workflows.Physical deployment adds feedback from engineers, users, sensors, logs, and safety checks; human oversight supplies initialization, external validation, and safety gates.Source: §5.3 · p. 15

5.4 Harness Architecture for Physical Coding

  • The Harness separates tools, workflow, verifier, recovery, and memory so failures can motivate a targeted revision and make attribution more tractable.A VLA or WAM is an available action tool, while workflow decomposes instructions, recovery handles failures, and memory stores provenance-checked traces.Source: §5.4 · p. 15

5.5 HexaAnything Execution Contracts

  • Execution contracts record evidence provenance and semantic verdicts, while the orchestrator monitors each tool call and fails closed on unfinished or ambiguous states.Harness edits must pass static checks, regression tests, and the official evaluator before their traces are admitted as Physical Coding data.Source: §5.5 · p. 16

6 Experiments: Harness, Model, and Tool

The experiments evaluate Harness, model, and tool evolution, including long-horizon execution with XR-1 held fixed and revisions scored by fixed evaluators. They report gains from Harness-managed execution, Harness-returned training data, and iterative tool revision.

6.1 Harness Effect with a Fixed Action Model

  • HexaAnything with GPT-5.6-Sol raises XR-1 Composite-Unseen success from 34.3% to 38.3% (+4.0 points), Composite-Seen from 54.8% to 61.5%, and overall from 56.6% to 61.1%.Both coding agents use GPT-5.6-Sol, and XR-1 runs natively or as a tool; each task is evaluated on 50 seeds.Source: Table 1 · p. 16, §6.1 · p. 16

6.1.1 Long-Horizon Execution on RoboCasa365

  • On three Composite-Unseen tasks, HexaAnything raises success by 31.0, 15.0, and 17.0 points over native XR-1 while using the same XR-1 action model.GPT-5.6-Sol maintains subgoals, verifies progress, and can interrupt or revise the next call.Source: Table 2 · p. 17, §6.1.1 · p. 17
  • For LoadKebabSandwich, the workflow gates oven closure on both ingredients being inside and revises subgoals when that predicate is false.Native XR-1 sometimes closes the door with one ingredient still out; on PortionHotDogs, the agent re-estimates item state and recovers from drops, imprecise placements, or stalls.Source: §6.1.1 · p. 17, Figure 6 · p. 17
  • On-demand execution summaries reduce a representative trace’s active context from roughly 190K to an estimated 30–35K tokens while keeping the full trace on disk.This change is in the Harness, not the model.Source: §6.1.1 · p. 17
  • Doubling the native VLA action budget on PortionHotDogs completed 21 of 100 trials versus 22 of 100 at the standard budget, while the coding-agent condition completed 37.The monitor–interrupt–replan workflow also raises CloseFridge from 50.0% to 79.0% and TurnOffStove from 0 of 8 baseline trials to 18.0%; those tasks used different protocols and are not pooled with Table 2.Source: §6.1.1 · p. 18

6.2 Model Evolution

  • In the same Harness, HexaModel v0.1 improves over its base on every split, from 37.3% to 39.5% on Composite-Unseen and from 60.5% to 61.7% overall.The model is fine-tuned on Harness-returned data together with general-domain data.Source: §6.2 · p. 18, Table 4 · p. 18, Figure 7 · p. 19

6.3 Tool Evolution

  • With task definitions and evaluators fixed and weights unchanged, two tool-revision rounds raise Fold cloth, Pour vase, and Press by number success from 0.0%, 40.0%, and 0.0% to 80.0%, 100.0%, and 100.0%.Improvement is not monotonic: the first Pour vase revision lowers success to 0.0%, before the next revision raises it to 100.0%.Source: Table 5 · p. 19, §6.3 · p. 19
  • On Fold cloth, seven reusable-tool revisions reached 4/5 held-out successes without privileged keypoints, but an operator chose pixels for each call.The tool’s task, evaluator, and weights stayed fixed; these results measure the tool and interface rather than autonomous perception.Source: §6.3 · p. 19, Figure 8 · p. 20

7 Beyond Manipulation: Scientific Experiment with Physical Coding

PhyBench tests whether HexaAnything can design and execute simulated physics experiments whose success depends on quantitative conclusions, not just object arrangements. Across three tasks and multiple models, the agent completes experiments end to end, while a Hooke’s-law trace shows how measurements and analysis remain inspectable.

7.2 Three Experimental Tasks: Objectives and Apparatus

  • The three experiments ask agents to estimate spring stiffness, gravitational acceleration, and coupled-oscillator frequencies by designing procedures, operating apparatus, measuring, and reporting estimates.Source: §7 · p. 20, §7.2 · pp. 21–22

7.1 PhyBench: A Simulated Laboratory

  • PhyBench uses Isaac Sim laboratories with a Franka arm, task-specific apparatus, calibrated cameras, and instruments, while hiding reference values until submission.Physics runs at 240 Hz for pendulum and coupled-oscillator tasks; the coupled displacement recorder samples at 120 Hz.Source: §7.1 · p. 20

7.2 Three Experimental Tasks: Objectives and Apparatus

  • Success requires relative error at most 15% for spring stiffness, 3% for gravity, and 10% for each coupled-oscillator frequency.Source: §7.2 · pp. 21–22

7.3 Execution Protocol and Results

  • All three evaluated models keep mean relative error below 5% on every task; GPT-6-Astra and Opus 5.5 each return valid results in 30/30 trials, versus 27/30 for GPT-5.6-Sol.Opus 5.5 is most accurate on Hooke’s law (1.3%) and the simple pendulum (1.0%); GPT-6-Astra leads on coupled oscillators (0.8%).Source: Table 6 · p. 22, §7.3 · p. 22
  • Runs proceed autonomously under a 7,200-second wall-clock limit and an 18,000-frame simulation budget; tables report mean error over valid runs and valid-run counts.Failed or interrupted trials remain in the denominator without a numerical error.Source: §7.3 · p. 22

7.4 Case Study: Hooke’s Law

  • In a tracked Hooke’s-law run, a weighted fit estimated k = 24.82 ± 0.40 N/m against a 25.16 N/m reference, for 1.36% relative error.The agent linked five readings to their source camera observations, making the estimate traceable to the images.Source: §7.4 · pp. 23–24, Figure 10 · p. 23

8 Physical Deployment, Limitations, and Open Problems

HexaAnything transfers its tool-based Harness to a dual-arm robot, where five of seven tabletop tasks succeed in all three trials. The paper also identifies limits in the current evaluation and open challenges for reliable self-evolution.

8.1 Real-World Transfer and Deployment Status

  • Five of seven AgileX tabletop tasks succeed in all three trials; HexaAnything completes tic-tac-toe in 5.0 minutes versus GPT-Policy’s 13.6, and unscrews a cap in 5.1 versus 17.9.Published comparisons use different hardware and operating limits, and each task has only three trials.Source: §8.1 · p. 24, Table 7 · p. 24
  • Robot tools evolve from execution traces and operator judgment: revisions changed throw timing, trajectory, and grasping, while rejected versions were rolled back.The Harness is exposed through URAI, which lets humans and agents use the same robot planning and control code.Source: §8.1 · pp. 24–25

8.2 Long-Horizon Complex Tasks

  • Longer random-start tasks requiring subgoal decomposition and object search were designed but not evaluated; long-horizon evidence therefore remains limited to built-in composite tasks.Source: §8.2 · p. 25

8.3 Limitations and Open Problems

  • The evidence is preliminary: PhyBench uses ten trials per model and task, real-robot tasks use three trials, and RoboDojo tool-evolution rates rely on few seeds.Open problems include verifier co-adaptation, learning physical causality from sparse trajectories, privacy for lifelong memory, and safety testing for deployment.Source: §8.3 · p. 25

9 Conclusion

Physical coding couples executable world-state and policy programs, and HexaAnything applies that interface across manipulation, scientific experiments, and robot tasks. The reported results are initial evidence of data, model, and tool evolution, not unrestricted self-redesign or unconstrained deployment.

9 Conclusion

  • On RoboCasa365, HexaAnything raises Composite-Unseen success from 34.3% to 38.3% over native XR-1 VLA, while HexaModel trained on its traces improves over its base model on every split.The conclusion also reports tool-revision gains on three RoboDojo tasks, sub-5% mean relative errors on PhyBench, and five of seven real-robot tasks completed in all trials.Source: §9 · p. 26
  • The broader roadmap spans Harness, data and environments, models, embodiment and compute, with representation and interface evolution cutting across these targets.Source: §9 · p. 26
  • Attributing progress requires versioned parents, independent hold-out evaluators, protected regression suites, provenance, canary deployment, and rollback.Simulation and constrained physical workflows provide complementary feedback for eventual manufacturing and scientific workflows.Source: §9 · p. 26

A Extended Related Work

  • The appendix provides an extended review of self-evolving systems, organized by the object of adaptation and the boundary held fixed.Source: A Extended Related Work · p. 33

A.1 Evolving Data, Tasks, Objectives, and Evaluators

Prior work evolves task and data distributions, objectives, and executable agent interfaces, but these adaptations play different roles in a learning loop. The review distinguishes those objects and highlights the attribution challenge when the evaluator also changes.

A.1 Evolving Data, Tasks, Objectives, and Evaluators

  • Task generators, environment generators, curricula, and demonstration synthesis adapt different parts of the training substrate, whereas RoboCasa and SWE-bench provide fixed settings [87] [90] [60].Source: §A.1 · p. 33
  • Reward-code systems make objectives programmable, but jointly adapting policy, reward generator, and scorer can confound capability gains with reward exploitation or evaluator–policy co-adaptation.Source: §A.1 · p. 33
  • The formulation treats task specification z, data D, and verifier ϕ as distinct interacting components because task generation, reward improvement, and independent validation have different causal roles.Source: §A.1 · p. 33

A.2 Evolving Programs, Tools, Harnesses, and Persistent Memory

  • Executable programs and surrounding interfaces structure perception, control, tools, memory, and feedback, while embodied systems adapt Harness components and interfaces [1] [72] [10] [21] [41] [58] [17] [50] [83] [84] [102].Source: §A.2 · pp. 33–34
  • Persistent memory stores reusable skills and traces, whereas the Harness composes execution; improvement at either level does not itself establish parameter or architectural change [81] [76] [101].Source: §A.2 · p. 34

A.3 Evolving Model Parameters, Architectures, and Research Procedures

The section distinguishes what an evolving agent changes from the boundary within which it is evaluated. It contrasts component-level adaptation with the unresolved challenge of reliable joint evolution across physical execution settings.

A.3 Evolving Model Parameters, Architectures, and Research Procedures

  • Model evolution can target learned parameters or adapters, structural configuration, or persistent memory; these are distinct from external changes to policy artifacts.The model state is written as θ = (A, w).Source: §A.3 · p. 34
  • Parameter-efficient updates such as LoRA do not establish autonomous self-evolution unless the agent controls data selection, update triggers, training, and validation.The passage distinguishes modifying a downstream policy from updating the agent's own underlying parameters.Source: §A.3 · p. 34
  • Program-search systems show that algorithms and executable agents can be search targets, while Autoresearch bounds changes to a training script for more tractable attribution.Those boundaries clarify which artifact a search procedure can modify; they do not by themselves establish neural-architecture evolution in an embodied model.Source: §A.3 · pp. 34–35
  • Joint evolution of model state (A, w, M) leaves catastrophic forgetting, cross-task regression, causal credit assignment, and safe rollback unresolved.Evidence for reliable joint evolution remains limited.Source: §A.3 · p. 35

A.4 Evolving Runtimes, Simulators, and Physical Execution Substrates

  • Software execution feedback supports adaptation of compilers and low-level code, but workloads, protocols, and hardware are typically fixed, limiting evidence for transfer across substrates.CompilerGym, MLGO, KernelBench, CUDA Agent, and KernelFoundry illustrate this line of work [80] [16] [62] [89].Source: §A.4 · p. 35
  • Real-world execution adds noise, calibration error, unmodeled dynamics, latency, contact variation, hardware wear, morphology, and safety constraints that simulation success alone cannot resolve.A successful program, solvable generated task, or simulation improvement does not alone establish robustness to distribution shift or transfer to a physical robot.Source: §A.4 · p. 35
  • Simulation is framed as a controlled cold-start substrate, with physical deployment supplying evidence about causal factors it does not faithfully represent.Table 8 is a mechanism-level scope map, not a performance ranking; the compared systems use different tasks, embodiments, and evaluation protocols.Source: §A.4 · p. 35, Table 8 · p. 36

A.5 From Component-Local Adaptation to Coupled Self-Evolution

Although individual agent components can be adapted, their sustained co-evolution with attribution, generalization, independent evaluation, and reversibility remains less established. The section formulates self-evolution as a coupled system and identifies recurring gaps in prior work.

A.5 From Component-Local Adaptation to Coupled Self-Evolution

  • Many agent components have been adapted, but whether they can co-evolve over time while preserving attribution, independent evaluation, generalization, and reversibility remains substantially less established.Changes to tasks, policies, Harnesses, environments, and physical-world evidence can interact, so their effects are no longer independent.Source: §A.5 · pp. 36–37
  • The formulation treats task specifications, environments, world and policy programs, Harnesses, model state, verifiers, data, and memory as potentially interdependent objects.It requires evidence that supports attribution across component boundaries, rather than crediting a local gain that depends on a changed evaluator, narrower task distribution, or environment-specific shortcut.Source: §A.5 · p. 37
  • Prior work leaves four recurring gaps: fixed-component generalization, component-local bottlenecks, sim-to-real and physical-causality evidence, and evidence-backed continual evolution.The latter includes independent validation, regression control, provenance, and rollback.Source: §A.5 · p. 37

B RoboCasa365 Case Studies

In three PortionHotDogs episodes, HexaAnything completes tasks left unfinished by native XR-1 from the same initial state. The accompanying PhyBench case-study examples are selected completed runs, not representative accuracy results.

B RoboCasa365 Case Studies

  • In all three episodes, native XR-1 leaves PortionHotDogs unfinished, while HexaAnything completes it from the same initial state.The cases include a missed sausage, a failed bread placement, and a stall before moving the sausages; HexaAnything detects and addresses each issue.Source: Figure 12 · p. 37, B RoboCasa365 Case Studies · p. 37, Figure 13 · p. 38

C PhyBench Case Studies

  • The PhyBench pendulum and coupled-oscillator examples were selected for passing all official-evaluation gates and retaining complete traces, not to represent typical accuracy.Plots were redrawn from the agent-written CSV and JSON files.Source: C PhyBench Case Studies · p. 38

C.1 Simple Pendulum

The simple-pendulum run plans the excitation and timing procedure before acting, then estimates gravitational acceleration from three measured pendulums. Its fitted estimate closely matches the stated reference.

C.1 Simple Pendulum

  • The plan matches each pendulum label to its gate timer, targets 2.5–2.8° amplitude below the 5° limit, and times ten complete cycles after withdrawing the probe.The planned pushes are 12, 15, and 18 mm for P1, P2, and P3, respectively.Source: §C.1 · pp. 38–39
  • g = 9.8682 m/s2 versus a 9.8678 m/s2 reference, with 0.004% relative error in the three-pendulum fit.All residuals are below 4 × 10−4 s2.Source: Figure 15 · p. 39, §C.1 · p. 39
  • The agent marks probe-grasp and bob-push points, performs the excitation, reads gate-timer records, and fits T 2 against L over the three pendulums.The figure shows the plan before action and the fit with residuals.Source: Figure 15 · p. 39, §C.1 · p. 39

C.2 Coupled Oscillators

The agent planned and acquired two independent coupled-oscillator records, then estimated both normal-mode frequencies close to their references.

C.2 Coupled Oscillators

  • The two-record plan uses independent initial displacements—CH1 +31.7 mm, then CH2 −23.9 mm—and Figure 16 shows second-record preparation and the joint fit.Each displacement excites both modes; the sliders are released together for a 120 s two-channel recording.Source: §C.2 · p. 40, Figure 16 · p. 40
  • Estimated frequencies were 3.0140 and 3.3382 rad/s against references of 3.0137 and 3.3376 rad/s, with relative errors of 0.010% and 0.020%.Table 9 presents the independent records and estimated normal-mode frequencies.Source: Table 9 · p. 39, §C.2 · p. 40
  • The agent fit the first 45 s of each record with a joint two-mode model using shared damping, averaged the records, and set uncertainty to the largest of three error estimates.The uncertainty rule takes the maximum of between-record spread, fitting-window spread, and formal fit error.Source: §C.2 · p. 40

Related papers

Loading 2609.35432v1…