Recent advances in Vision-Language-Action (VLA) models and World Action Models (WAMs) have expanded the manipulation and whole body capabilities of individual robots. Yet a single robot remains limited by its embodiment, and many real world tasks require capabilities that can only emerge through cooperation. Existing multi robot frameworks largely emphasize task decomposition, allocation, and replanning, while providing limited support for adapting executable coordination when physical execution deviates from the intended behavior. We present CoEvolve, a framework that represents team coordination as executable code over fixed robot motor skills. CoEvolve introduces Verifier Guided Coordination Evolution, where a multimodal foundation model instantiates coordination strategies through motion primitives, semantic objectives, temporary robot roles, and bounded execution parameters. Physical verification evaluates each executed transition, rejected behaviors trigger structured coordination revision from an accepted checkpoint, and verified experience is retained to guide subsequent decisions. We evaluate CoEvolve with two simulated Unitree G1 humanoids transporting a freely supported rigid payload through constrained corridors. Across 15 base task runs with three multimodal backbone families, CoEvolve completes 8 tasks, with every backbone achieving end to end success. Additional evaluations yield verified placement on two additional corridor layouts and after both same-backbone and cross-backbone experience initialization, while exposing persistent limitations in motion precision and contact stability. These results support executable coordination as a practical interface for adapting long horizon multi robot collaboration under shared physical constraints.
Figures & tables
Figure 1: Motivation and overview of CoEvolve . The schematic contrasts individual manipulation with coordinated transport of a shared payload. CoEvolve combines executable team policies, physical verification, and reusable experience to revise coordination during execution.
Figure 2: Framework of CoEvolve . The Task Orchestrator commits a team subtask, which the Policy Coder grounds into executable robot policies. Physical verification accepts or rejects the resulting transition; rejected executions trigger structured coordination revision, while verified outcomes update cooperative experience. Motor-policy weights remain frozen.
Backbone
Full-task SR@80 ↑
VP (%) ↑
EA (%) ↑
PAUC@80 (%) ↑
GPT-5.4-mini
3/5 (60.0%)
86.7
85.4
61.9
Gemini-3.5-Flash
3/5 (60.0%)
76.7
66.7
60.2
Claude-Sonnet-4.6
2/5 (40.0%)
76.7
86.5
64.5
Table 1: Base-task results across foundation model backbones ( n=5 per backbone). Success requires placement, release, and robot retreat. VP, EA, and PAUC are per-run means.
Method
Full-task SR@80 ↑
VP (%) ↑
EA (%) ↑
PAUC@80 (%) ↑
External baselines
REMAC ( Yuan et al., 2026 )
0/5 (0.0%)
26.7
57.1
23.3
COHERENT ( Liu et al., 2025a )
0/5 (0.0%)
56.7
≥83.6
49.1
CaP-Agent0 ( Fu et al., 2026 )
0/5 (0.0%)
33.3
66.7
29.5
ASPIRE (Online) ( Lu et al., 2026 )
0/5 (0.0%)
40.0
74.9
35.6
Component variants
Table 2: Base-task comparison using GPT-5.4-mini ( n=5 per condition). The full method reuses the GPT runs in Table 1 . ≥ denotes a confirmed EA lower bound.
Figure 3: Representative CoEvolve and REMAC executions on the base task. CoEvolve reaches task completion, whereas REMAC terminates at the cumulative payload-drop limit after successive pivot attempts. Attempt labels denote internal execution indices rather than cumulative physical transactions.
Layout
Verified placement ↑
VP (%) ↑
EA (%) ↑
PAUC@160 (%) ↑
Layout 2
1/3 (33.3%)
41.7
71.4
30.3
Layout 3
0/3 (0.0%)
58.3
46.1
53.6
Layout 4
1/3 (33.3%)
50.0
64.1
37.1
Table 3: Additional-layout results ( n=3 per layout). PAUC@160 uses a common retrospective reporting horizon.
Figure 4: Representative execution traces across additional layouts. Layout 3 accumulates intermediate progress before payload support degrades, illustrating why certified local progress need not preserve feasibility for later maneuvers. Layouts 2 and 4 show successful placement under different coordination sequences. Attempt labels denote internal execution indices rather than cumulative physical transactions.
Source → Target
Strategy records / action exemplars
Verified placement ↑
VP (%) ↑
EA (%) ↑
PAUC@80 (%) ↑
GPT → GPT
17 / 14
1/5 (20.0%)
50.0
75.4
38.0
Gemini → GPT
16 / 8
2/5 (40.0%)
76.7
80.3
55.8
Claude → GPT
4 / 8
0/5 (0.0%)
56.7
≥61.6
45.0
Table 4: Experience reuse with GPT-5.4-mini as the target ( n=5 per source bank). PAUC uses the first 80 cumulative physical transactions. ≥ denotes the confirmed EA lower bound.
Appendix figures & tables12 assets
Supplementary material from the paper’s appendix.
Appendix
Role
Responsibility
Task Orchestrator
Maintain the semantic plan and commit the current team subtask.
Policy Coder
Generate bounded parameters and executable policies for the robots.
Evaluator
Interpret observations and execution evidence for failure analysis.
Evolution Manager
Select a revision scope and objective from verifier evidence.
Mutation Operator
Propose a child strategy within the approved scope.
Code Repairer
Repair invalid or inconsistent policy drafts.
Appendix
Table 5: Structured model roles. Physical acceptance, execution checks, checkpoint management, and experience promotion remain host operations.
Capability
Motor skills
Arguments
Longitudinal motion
carry_forward , carry_backward
Distance, speed, ramp duration
Turning
turn_clockwise , turn_counterclockwise
Yaw, yaw rate, turn segment
Lateral motion
carry_lateral_left , carry_lateral_right
Distance, speed, ramp duration
Height control
place_crouch , recover_stand
Height, ramp, hold duration
Payload recovery
recover_payload_inward
Ramp and hold duration
Appendix
Table 6: Motor capabilities available through the execution interface.
Figure 5: Coordination revision during execution. Selected snapshots show transport, target alignment, rejection and checkpoint restoration, followed by revised behavior and the illustrated completion. Attempt labels identify positions in the episode, not cumulative physical-transaction counts.
Figure 6: Environment layouts. Layout 1 is the base environment; Layouts 2–4 provide additional corridor configurations.
Condition
Evaluated mechanism
REMAC
Reflective multi-robot planning through the task and capability interface.
COHERENT
Multi-agent coordination using the robot observations and bounded skills.
CaP-Agent0
Executable robot-code generation for cooperative payload transport.
ASPIRE (Online)
Online adaptation with the reported setting K=8 and verification local to the current checkpoint.
Flat Reflective Repair
Direct policy rewriting without selecting a typed revision scope; physical feedback, recovery, and dynamic memory remain available.
w/o Dynamic Experience
Structured revision with strategy and exemplar retrieval, writing, and promotion disabled.
Appendix
Table 7: Comparison mechanisms. External methods are task-specific adaptations; the component conditions alter the stated parts of CoEvolve .
Geometry
Sliding
Torsional
Rolling
Palm/forearm proxies
3.0
0.05
0.002
Payload
2.0
0.05
0.002
Target
1.4
0.03
0.001
Ground default
1.0
0.02
0.001
Appendix
Table 8: Configured contact parameters in the inspected scene generator.
Quantity
Observed value
Requested displacement
0.250m
Payload displacement at stop trigger
0.192672m
Final payload displacement
0.663442m
Maximum sampled payload displacement
0.689713m
Payload displacement after stop trigger
0.470769m
Front robot displacement after stop trigger
0.476529m
Appendix
Table 9: Single-trace stopping diagnostic, not a repeated-trial accuracy estimate.
Layout
Run 1
Run 2
Run 3
Layout 2
D, 19/80
S, 88/160
D, 30/80
Layout 3
B, 160/160
D, 118/160
D, 94/160†
Layout 4
D, 57/80
D, 29/80
S, 120/160∗
Appendix
Table 10: Scene outcomes and cumulative transactions/original limit. S denotes placement, D a drop-limit terminal, and B budget exhaustion. ∗ Placement follows adjusted corridor verification. † The effective limit is 160; an older embedded field retains 80.
Source
Run 1
Run 2
Run 3
Run 4
Run 5
GPT
D, 25/80
S † , 56/80
D, 46/80
G, 25/80
D, 37/80
Gemini
D, 40/80
S † , 58/80
C, 82/100
S, 41/80
G, 46/80
Claude
D, 56/80
B † , 80/80
D † , 53/80
D ‡ , 32/80
D, 78/80
Appendix
Table 11: Transfer outcomes and cumulative transactions/original limit. G denotes generation/repair stall; C denotes conditional diagnostic stop. † Original finalization gaps are retained alongside later read-only validation. ‡ The terminal outcome is independently reconciled.
Evaluation
PAUC horizon
Outcome scope
Base task
80
Placement, release, and retreat within 80 transactions.
Additional layouts
160
Placement/release in the selected execution; original limits differ.
Experience reuse
80
PAUC uses the first 80 transactions; other metrics use the complete selected execution.
Appendix
Table 12: Reporting horizons and task endpoints. A common retrospective horizon does not establish a matched experimental protocol.
Condition
Physical transactions
FM calls
Terminal counts D/G/B/C
Unresolved transactions
Base-task backbones (five runs each)
GPT-5.4-mini
52.4
460.4
0/1/1/0
0
Gemini-3.5-Flash
27.0
148.6
0/2/0/0
0
Claude-Sonnet-4.6
24.2
182.0
0/3/0/0
0
Comparison conditions (five runs each)
REMAC
20.4
122.8
4/1/0/0
0
Appendix
Table 13: Resource and termination diagnostics. Physical transactions and FM calls are per-run means; terminal and unresolved counts are group totals. ≥ denotes a confirmed call-count lower bound. ‡ One drop terminal is independently reconciled with its original infrastructure exception retained. The full comparison row reuses the GPT backbone results and is not duplicated here.
Condition
n
Complete timing
Mean run time (min)
Base-task backbones
GPT-5.4-mini
5
5/5
254.7
Gemini-3.5-Flash
5
5/5
74.9
Claude-Sonnet-4.6
5
5/5
87.8
Comparison conditions
REMAC
5
5/5
29.0
Appendix
Table 14: Run-time statistics for the selected execution archive. Means include successful and unsuccessful outcomes. Complete timing counts executions with complete recorded timing; ≥ denotes a confirmed lower bound caused by missing historical timing intervals. The reused Full condition from Table 2 is not counted separately.