CoEvolve: Self-Evolving Code Policies from Skills to Strategies for Humanoid Robots

1 INTRODUCTION

• The motivating challenge is that a valid task plan may cease to be executable when physical coupling changes teammate support or joint-motion feasibility.Unequal displacement can disrupt formation, while constrained turns may require temporary support and mover roles.Source: §1 · pp. 1–2
• CoEvolve represents team coordination as executable policies composed from fixed motor capabilities, rather than selecting complete strategies from a library.The model combines motion primitives, semantic objectives, temporary roles, coordination modes, and bounded execution parameters.Source: §1 · pp. 2–3
• Verifier Guided Coordination Evolution uses physical execution evidence to revise maneuvers, robot-role relationships, or execution parameters from the latest accepted checkpoint.Verified outcomes also contribute abstract coordination records and accepted executable examples; motor-policy weights remain fixed.Source: §1 · pp. 2–3, Figure 2 · p. 3
• The evaluation uses two simulated Unitree G1 humanoids carrying a freely supported rigid payload through constrained corridors, across 15 runs and three foundation-model families.It also examines adapted baselines, component variants, additional layouts, and experience reuse, with some comparisons subject to differing runtime or continuation conditions.Source: §1 · pp. 2–3

Self-Evolving Agents

• Self-evolving-agent systems adapt agent knowledge, memory, prompts, skills, implementations, or search processes; CoEvolve instead revises executable inter-robot coordination during a shared physical task.The paper positions its motor skills and runtime contracts as fixed.Source: §2 · p. 3

Robot Policy Refinement from Execution Feedback

• Execution-feedback systems already revise multi-robot plans or executable robot programs, while CoEvolve targets failures in physically coupled humanoid transport that may require a different maneuver or temporary support roles.CoEvolve combines coordination revision with physical transition checks, checkpoint recovery, and retrieval of strategy records and accepted code examples.Source: §2 · pp. 3–4

3.1 OVERVIEW AND COORDINATION REPRESENTATION

• The host supplies route geometry and progress constraints, while the model decides how to coordinate within them.The persistent semantic plan records task phases, completion criteria, and status.Source: §3.1 · p. 4
• The Task Orchestrator commits coordination primitives, semantic objectives, modes, and temporary roles, while paired robot policies each contain one allowed action followed by an explicit stop.The host validates the pair as one logical team transaction; logical grouping does not imply identical physical responses.Source: §3.1 · p. 4

3.2 VERIFIER GUIDED COORDINATION EVOLUTION

• Physical verification accepts transitions using measured progress, payload support and stability, robot configuration, and environmental contacts; only accepted transitions become trusted checkpoints.The semantic plan advances only when the active phase meets its completion criterion.Source: §3.2 · p. 5
• After rejection, typed revision changes the maneuver and objective, coordination mode and roles, or bounded parameters, while leaving fields outside the selected scope fixed.The approved child strategy constrains the next policy-generation step, which is evaluated from the latest accepted checkpoint.Source: §3.2 · p. 5

3.3 VERIFIED COOPERATIVE EXPERIENCE

• CoEvolve keeps abstract strategy records separate from accepted executable exemplars: the former guide what coordination to attempt, and the latter guide how to implement it.Records retain applicability conditions, failure patterns, and repair directions; exemplars retain code and effective parameters.Source: §3.3 · p. 5
• Experience is updated only after physical execution; accepted transitions can supply reusable records and exemplars, while rejected transitions can supply verified counterexamples.Unexecuted repair proposals are not promoted as successful experience.Source: §3.3 · p. 5

4.1 EXPERIMENTAL SETTING

• The evaluation uses two simulated Unitree G1 humanoids carrying a freely supported rigid payload through constrained corridors, with base-task completion requiring placement, release, and retreat.The model selects coordination primitives, temporary roles, modes, and bounded parameters within route and progress constraints; robot policies are independently deployed with frozen weights.Source: §4.1 · pp. 5–6, §4.2 · p. 6

4.2 EVALUATION PROTOCOL AND METRICS

• The metrics distinguish endpoint completion, retained milestone progress, transaction acceptance, and the timing of milestone acquisition; PAUC does not measure terminal stability or inference efficiency.The full comparison reuses GPT runs, and differences in runtime and continuation settings make aggregate comparisons descriptive rather than matched causal estimates.Source: §4.2 · p. 6

4.3 CROSS-BACKBONE EVALUATION

• All three backbones achieve successful full-task execution, although Claude’s higher EA and PAUC@80 do not correspond to more completions than GPT and Gemini.One GPT run accepted 31 of its final 33 transactions after its fourth milestone but certified no further milestone.Source: §4.3 · p. 6

4.4 METHOD COMPARISONS AND COMPONENT ANALYSIS

• Only CoEvolve completes the full task among compared methods, while removing Dynamic Experience reaches 60.0% VP but yields no completion, and Flat Reflective Repair hits the payload-drop limit in four runs.The reported failure profiles are consistent with structured revision localizing what to change and verified experience informing what to try, but do not isolate either effect causally.Source: §4.4 · pp. 7–8

4.5 EVALUATION ACROSS LAYOUTS

• Layouts 2 and 4 achieve verified placement, but Layout 3 reaches no placement despite the highest VP (58.3%) and PAUC@160 (53.6%), as support degrades after certified progress.Layout 4 uses a refined corridor-verification condition, so it is not a matched geometry-only replicate.Source: §4.5 · p. 8, Table 3 · p. 8

4.6 CROSS-MODEL EXPERIENCE REUSE

• Cross-backbone reuse yields two placements with Gemini-derived experience, one with GPT-derived experience, and none with Claude-derived experience; unequal banks and no matched empty-memory condition preclude a causal transfer claim.The target selects, instantiates, and verifies policies rather than receiving simulator state, controller history, or a complete trajectory.Source: §4.6 · pp. 8–9, Table 4 · p. 8

• CoEvolve adapts executable multi-robot coordination over fixed motor skills through physical verification, structured revision, and verified experience.Source: §5 · p. 9
• Across three foundation-model families, CoEvolve achieves end-to-end cooperative transport, with additional evaluations showing execution under new layouts and same-model and cross-model experience reuse.Source: §5 · p. 9
• Accepted actions can fail to resolve a coordination bottleneck, and verified progress can precede later loss of physical support.Source: §5 · p. 9
• Motion precision, contact stability, and physical recovery remain open limitations.Source: §5 · p. 9

• All experiments use simulation, privileged physical-state information, and supplied route references, so real-world deployment remains unevaluated.Source: §6 · p. 10
• Runs incur substantial wall-clock cost because model inference, physical execution, verification, and recovery recur throughout execution.Source: §6 · p. 10
• Rejected executions recover by restoring an accepted simulator state rather than using a physically executable recovery policy, limiting direct transfer to real robots.Source: §6 · p. 10
• Bounded motion intentions can yield unequal responses, residual motion, and formation drift, while finite contact regions, friction, and simulator contact dynamics affect payload stability.Source: §6 · p. 10
• Contact dynamics are not systematically randomized, and relatively small, heterogeneous cohorts limit strong causal claims about components, scene generalization, and experience transfer.Source: §6 · p. 10

• Generative AI assisted literature search, ideation, experimental design, software development, results interpretation, and manuscript drafting and refinement.Source: AI USE STATEMENT · p. 10
• Authors independently reviewed and verified AI-assisted suggestions, code changes, configurations, results, citations, and scientific claims.Source: AI USE STATEMENT · p. 10
• Generative AI was not used to generate synthetic datasets or prove mathematical claims, and the authors take full responsibility for the work.Source: AI USE STATEMENT · p. 10

• The study is entirely simulated and involves neither human participants nor personal data or physical-robot deployment.Source: ETHICS STATEMENT · p. 10
• The framework is intended for research on cooperative robot reasoning and execution, not as a real-world safety guarantee.Source: ETHICS STATEMENT · p. 10
• Physical-robot use would require additional safeguards, state and contact estimation, calibrated motion control, and hardware-specific safety validation.Source: ETHICS STATEMENT · p. 10

REPRODUCIBILITY STATEMENT

• Appendix A covers role interfaces, motor capabilities, verification, and experience mechanisms; Appendix B documents execution settings, baselines, endpoints, and selected runs.Source: REPRODUCIBILITY STATEMENT · p. 10
• Appendix C defines metric reconstruction, uncertainty from unresolved transactions, resource statistics, and run-time accounting.Source: REPRODUCIBILITY STATEMENT · p. 10
• The appendices distinguish recorded execution conditions from retrospective reporting horizons used in aggregate results.Source: REPRODUCIBILITY STATEMENT · p. 10

A.1 STATE, PLAN, AND ROLE INTERFACES

• The orchestrator commits task-phase coordination while the coder supplies bounded numerical parameters and programmatic implementation; the semantic plan records phases and completion evidence, not executable waypoints.Source: §A.1 · p. 13, Table 5 · p. 13

A.2 MOTOR CAPABILITIES AND TEAM EXECUTION

• Three transport primitives are coordinated linear transport, pivot, and alignment; paired robot policies are validated before dispatch, but joint dispatch is not a hard real-time synchronization barrier.Source: §A.2 · pp. 13–14, Table 6 · p. 13

A.3 VERIFICATION, REVISION, AND RECOVERY

• Acceptance checks physical support and stability, robot state, contacts, phase validity, and objective progress; rejected transitions restore the latest accepted simulator state and revise selected strategy fields.The host validates that the approved child changes only its selected fields; recovery does not physically reverse motion or automatically search earlier checkpoints.Source: §A.3 · p. 14

A.4 EXPERIENCE CONTENTS AND RETRIEVAL

• Strategy records guide coordination choices, while accepted code exemplars guide implementation; only experience supported by executed behavior and verifier outcomes is eligible for promotion.Fresh runs start with empty dynamic memory, while transfer runs preload a fixed source bank and update their own subsequent experience.Source: §A.4 · p. 14

A.5 REPRESENTATIVE COORDINATION REVISION

• Figure 5 illustrates rejection, checkpoint restoration, and revised behavior within one episode; it adds no independent run to the quantitative evaluation.Source: §A.5 · p. 14, Figure 5 · p. 15

B.1 ENVIRONMENT LAYOUTS AND ENDPOINTS

• The base and additional layouts use two humanoids supporting a free rigid payload; placement endpoints require target support and release, while the base full-task endpoint also requires robot retreat.Placement requires a 3 s stability window; the additional-layout endpoint omits retreat.Source: §B.1 · p. 15, Figure 6 · p. 15

B.2 COMPARISON CONFIGURATIONS

• External comparison methods are task-specific adaptations, and the shared task interface does not imply identical runtime or recovery implementations.Source: §B.2 · p. 15, Table 7 · p. 16
• The full reference reuses GPT runs from Table 1, and differing execution configurations and repair continuations prevent treating the comparison as an isolated causal estimate.Source: §B.2 · p. 15

B.4 LOCAL EXECUTION DIAGNOSTICS

• Residual motion continues after IDLE commands are consumed, so successful skill return does not establish endpoint accuracy or continuous-time safety.The stopping diagnostic is a single trace, not a repeated-trial accuracy estimate.Source: §B.4 · p. 16, Table 9 · p. 17
• A release gate rejected withdrawal at a logged 0.459 m against a 0.45 m limit, and the later feedback clarification does not establish repaired release dynamics.The historical gate snapshot was not replaced with a later measurement.Source: §B.4 · pp. 16–17

B.5 SCENE RECORDS AND EXECUTION CONDITIONS

• Layouts 2 and 4 reach placement at 88 and 120 transactions, so neither meets the 80-transaction placement endpoint.The 160-transaction PAUC horizon is retrospective and does not make these fresh 80-transaction trials.Source: §B.5 · p. 17

B.6 SOURCE BANKS AND TRANSFER RECORDS

• Transfer banks contain unequal numbers of strategy records and accepted action exemplars, and no source physical state or complete trajectory is transferred.Each fixed bank initializes five target executions; unequal bank sizes and absent matched empty initialization limit conclusions about transfer benefits.Source: §B.6 · p. 17
• Restoring simulator state does not ensure a valid decision context, and correcting checkpoint binding still did not prevent the transfer run from reaching its payload-drop limit.Plans and retrieved evidence must apply to the execution state, while resulting motion must separately preserve physical support.Source: §B.6 · p. 18

C.1 OUTCOMES, PROGRESS, AND ACCEPTANCE

• Execution acceptance measures locally accepted dispatched transactions, not global task success; unresolved charged outcomes are reported as confirmed lower bounds.Setup and corrective actions can be accepted without completing a milestone.Source: §C.1 · p. 18

C.2 RECONSTRUCTING PROGRESS AUC

• PAUC credits each milestone at first certified attainment and measures its timing, while VP measures progress retained at the terminal trusted checkpoint.Neither metric substitutes for success or continuous physical stability.Source: §C.2 · p. 19

C.3 RESOURCE USE AND TERMINATION CATEGORIES

• Termination labels describe final stopping conditions rather than intermediate errors or unique causes, and the 69-execution archive combines different endpoints and conditions.Those differences preclude combining the archive into one aggregate success rate.Source: §C.3 · p. 19

C.4 RUN-TIME ACCOUNTING

• Run time sums elapsed execution-segment duration, including model waits, physical execution, verification, recovery, and finalization.Manual pauses, code modification, and queue waiting between segments are excluded.Source: §C.4 · p. 19
• At least 112.8 hours of run time are recorded across 69 selected executions, averaging at least 98.1 minutes per execution.Timing is complete for 65 executions; missing historical intervals remain lower bounds rather than being imputed as zero.Source: §C.4 · p. 20, Table 14 · p. 21
• Shorter run time does not necessarily indicate greater efficiency because unsuccessful runs may terminate early, while verification and recovery can extend a run.The five GPT base-task executions average 254.7 minutes, compared with 142.4 minutes for the three successful GPT executions.Source: §C.4 · p. 20