The Trinity:Capability-Driven Recursive Self-Improvement for Multimodal Agents

Introduction

Multimodal foundation models have rapidly advanced in understanding, reasoning, and generation across text, images, video, and audio [4, 2, 49, 3, 5, 40, 50, 119, 123, 121, 124, 125], enabling agents to perceive, decide, and act in open environments [34, 35, 122]. We view multimodal intelligence as an evolving loop: worlds provide tasks, humans guide learning, and agents interact with the world to produce verifiable outcomes [116, 117]. As tasks and environments grow increasingly complex, this loop faces two bottlenecks: (1) Constructing large-scale, heterogeneous, and verifiable environments manually is costly, motivating automated world generation; and (2) Agent capability is increasingly constrained by the Harness [14, 13, 15, 41, 48, 43], whose manual iteration cannot keep pace with growing task complexity and diversity.

Inspired by Harness recursive self-improvement [12, 23, 22] and agent–environment co-evolution [37, 39, 38], we ask whether this manual loop can improve continuously. Generated worlds provide adaptive curricula, while verified interaction feedback guides Harness updates.

However, extending this process across heterogeneous text-only and multimodal tasks [118, 120] presents a challenge. Current Harness RSI works focus on text-modality tasks (e.g., coding and math [12, 43, 54, 51]) and adopt task-specific evolution [36, 48, 53, 23]. This approach is suitable when tasks share similar capability requirements, but can lead to Harness overfitting and poor generalization across heterogeneous tasks. Conversely, a global Harness struggles to accommodate conflicting task demands, including performance–efficiency trade-offs in embodied tasks, limiting its efficiency and adaptability.

A key insight is that tasks with different modalities and surface forms can share the same underlying capability requirements. For example, although ARC-AGI-3 [66] and Micromouse [67] differ in task structure, both rely on accurate perception and state tracking: the former requires recognizing grid states and their changes, while the latter requires continuously updating environmental information during maze exploration. Grouping tasks by these shared capability requirements makes the underlying mechanisms a common learning objective, enabling generalization across tasks.

To operationalize this position, we introduce The Trinity, a recursive self-improvement framework coupling environment generation with agent evolution through Creator, Explorer, and Evolver. Using verified trajectories, Evolver identifies task capability requirements and groups tasks sharing them, reorganizing the original task tree into a hierarchical capability tree. Heterogeneous tasks at the same node share a learning objective, motivating Capability-Driven Real2Sim2Real: Creator abstracts their common requirements into simplified, verifiable environments, while evaluation on the original tasks measures capability transfer. Along the capability tree, Explorer evolves a Harness tree through selective inheritance and local refinement, while Creator evolves at corresponding nodes and consolidates validated updates into a new Base Harness at the end of each iteration.

The Harnesses specialize in different capabilities, requiring task-dependent selection. For Explorer, our Capability-Aware Harness Router uses verified execution experience and public task information to select a matching branch of Explorer’s Harness tree. For Creator, overlap within its Harness tree motivates merging complementary modules and removing near-duplicates to form a new Base Harness. Explorer and Creator play distinct roles in RSI processes along the same capability tree.

Contributions. Capability-driven multimodal RSI. We make shared capability requirements the organizing principle of Harness evolution. Capability-Driven Real2Sim2Real turns these requirements into compact training worlds, yielding a reusable module-based Harness tree whose specialization motivates capability-aware routing. Capability–module priors for Harness design. We connect task-level capability requirements to reusable module configurations, using empirical associations and controlled interventions to examine which module support matters for a task. Efficient evolution and transfer. We show that targeting shared decision logic supports effective Harness improvement at low evolution cost, with transfer across heterogeneous tasks, unseen benchmarks, and real-world embodied settings.

Preliminaries

Multimodal Agentic Tasks

Long-horizon multimodal agentic tasks span interactive games [70], GUI manipulation [26], and embodied interaction [34, 35]. They combine perception, understanding, reasoning, and generation with memory, planning, and adaptation across observation–action sequences. Agents must retain evidence, revise hypotheses, and adjust plans as observations arrive. Because later decisions depend on earlier actions and feedback, misread observations or forgotten constraints can propagate across steps. Agent performance thus increasingly depends on effective Harness organization and coordination. Dynamically coordinating capabilities over long interactions and adapting to increasingly large, heterogeneous task sets remain key challenges.

Agent Harness

A Harness configuration $\phi$ coordinates a frozen model $f_\theta$ through six control-flow protocols:

Given task $\tau$, observation $o_t$, public history $\xi_{<t}$, controller state $s_t$, and available resources $\mathcal{C}_\tau$:

Perception extracts facts $f_t$; Memory builds a history-conditioned view $v_t$; Inference maintains compatible candidates; Planning ranks or prunes options into directive $d_t$; Orchestration identifies applicable resources; and Loop resolves execution $e_t$ and commitment $c_t$, including withholding action. These roles are independent of task categories and capability-tree nodes. The equations describe functional roles and their data dependencies; individual module bindings are invoked under the runtime policy described in Section sec:local_harness_evolution.

Modules are pure functions of supplied public records, without hidden-state access or environment actions. Only Memory may declare explicit carry; hypothesis refutation requires observed contradiction. All protocols may emit typed readiness signals, while Loop resolves execution. Orchestration assesses applicability, relevance, and trust within a fixed host-exposed tool set. Evolution updates module configurations with $\theta$ fixed.

Capabilities and protocols have a many-to-many relationship: the tree groups shared requirements, while protocols locate module updates. Hypothesis consistency can involve Memory organizing evidence, Inference checking compatibility, and Planning ranking informative tests; the same Memory module can support several requirements. Explorer retains node modules; Creator uses the same tree structure and consolidates its next Base Harness. Evaluation-time skills are prepared separately (§ 4.1.0.1); they are not stored, evolved, inherited, or routed in the tree.

The Trinity

Framework Overview

The Trinity couples environment generation and Harness evolution with a frozen backbone (Figure 2). Explorer collects trajectories; Evolver organizes requirements from specifications and verified trajectories into a capability tree (§ 3.2–§ 3.3). Through Capability-Driven Real2Sim2Real, Creator builds simplified, verifiable worlds; original-task evaluation measures transfer (§ 3.3.0.2). Explorer selectively inherits and refines reusable modules, accumulating validated updates in a fixed-topology Harness tree (§ 3.4 and § 3.5). The Capability-Aware Harness Router selects a compatible branch using public task information and verified experience (§ 3.6).

Stage 1: Task Tree Construction

Benchmark Organization.

Evolver normalizes public multimodal benchmarks into specifications of goals, observations, actions, feedback, task-completion criteria, and budgets, independently checked against their sources. A common observation–action interface preserves information access and scoring rules. Benchmarks are grouped into five requirement domains: rule discovery, constrained problem solving, perception and control, multi-agent interaction, and long-horizon environments. The training/unseen split is fixed before capability induction.

World Exploration.

Explorer collects trajectories from sampled training instances using $\mathcal{H}_0$ under fixed settings. Only training records support capability-tree construction, world generation, module learning, and Router training (§ 3.6). Unseen capability requirements are assessed only after the tree is fixed, for evaluation. Instance selectors and initial-state hashes are fixed in advance. Diagnostic reruns reset memory; completed runs are retained, while infrastructure failures are marked invalid and retried. Hash-chain checks verify execution records.

Stage 2: Capability Tree Construction

Evolver derives requirements from task goals, permitted observations, action rules, and task-completion criteria, linking them to rules and trajectory steps satisfying or violating these criteria through rule-based checks. Host-private information supports only retrospective verification.

Requirement Organization.

Using training-task specifications and trajectories, independent agents propose capability categories $\mathcal{K}$ (Appendix § 10); a judge consolidates them, and reviewers independently check definitions, evidence, assignments, and coverage. Each training task $\tau$ receives a fixed requirement set $K_{\tau}\subseteq\mathcal{K}$, including requirements already satisfied by $\mathcal{H}_0$.

The tree is constructed from training tasks $\mathcal{B}_{\mathrm{tr}}$ only. A deterministic capability order $\prec$, fixed before construction, defines paths and the tree:

The $\operatorname{Trie}$ merges common prefixes across domains. Each node $v$ supports an Explorer module configuration for its prefix; tasks retain endpoint associations, including at internal nodes. Node requirements define local objectives, with selective parent inheritance for Explorer; the order implies no causal dependencies. Requirements for unseen tasks $\tau\in\mathcal{B}_{\mathrm{un}}$ are identified afterward using the fixed categories, solely for retrospective Router evaluation, without modifying the tree.

World Creation.

Once the capability tree is built, each node is linked to training benchmarks through shared requirements. Although the four tasks in Figure 3 differ, all require evidence verification before decisions. This motivates Capability-Driven Real2Sim2Real: Evolver designs simplified training levels from node requirements, descendants, and representative tasks’ public specifications, excluding target-task layouts, private proofs, and solution traces while preserving core decision processes. Creator implements these levels using a node Harness initialized from its Base Harness or inherited parent modules, omitting aesthetic optimization to focus on task mechanisms. Evolver’s host-executed verifier pool checks node binding, execution, state transitions, rendering, and completion. Node identifiers link specifications, trajectories, and module updates, while private verifiers and public feedback guide revisions. Explorer tests verified worlds with a frozen screening Harness, admitting only those within a predefined intermediate-performance band. Otherwise, Creator adjusts difficulty along predefined dimensions. Trial counts, performance thresholds, action budgets, and retry limits are fixed in advance; worlds and verifiers remain unchanged during local training. Curricula may be reused or regenerated, while original benchmarks assess capability transfer. Appendix § 13.2 details the curricula for each node.

Stage 3: Harness Tree Construction

For Explorer, capability-driven RSI builds a Harness tree aligned with the capability tree. At each node, Explorer executes admitted worlds with inherited and local modules. Evolver compares successful and failed trajectories using public observations, actions, and host-assigned outcomes to identify node-specific improvements. It develops reusable modules through host-registered bindings in the six-protocol library (§ 2.2), refining interfaces, bounded configurations, or implementations. Updates record node, predecessor-version, episode, and executable-example references. Before local updates, the host validates evidence, ownership, interfaces, lineage, and typed input–output assertions; ancestor modules remain preserved. Bindings use public context and permitted memory under a fixed runtime policy. Multiple bindings per protocol may coexist, with model calls determining execution order. Admission verifies grounding and executability; evaluation measures performance. Creator evolves only upon verifier-detected failures. At each iteration’s end, validated proposals are consolidated with existing Base Harness modules, merging complementary modules and removing near-duplicates. § 3.5 details persistence, selective inheritance, and consolidation.

Recursive Self-Improvement

Explorer evolves along the capability tree, with Creator following at corresponding nodes; their Harness trees share the same structure (Appendix § 11). Explorer selectively inherits node modules; at each iteration’s end, Creator deduplicates and merges complementary updates into its next Base Harness. Let $V=V(\mathcal{T})$ and $V^+$ denote all nodes and non-root nodes, respectively.

Node State.

For Explorer, let $\mathcal{H}_{\mathrm E,v}^{(i)}\equiv\mathcal{H}_{\phi_{\mathrm E,v}^{(i)}}$ denote the Harness at node $v\in V$ after iteration $i$. Nodes initialize with $\mathcal{H}_{\mathrm E,v}^{(0)}=\mathcal{H}_0$ and available training feedback $\mathcal{F}_v^{(0)}$. Top-down iterations retain local modules and keep the synthetic root fixed.

Selective Inheritance.

At non-root node $v\in V^+$, compare the previous inherited registry $P_v^{(i)}$ with the updated parent $\widehat{P}_v^{(i+1)}$, holding local modules $L_v^{(i)}$ fixed. Writing the Harness’s module configuration as $\mathcal{H}_{\mathrm E,v}^{(i)}=P_v^{(i)}\oplus L_v^{(i)}$, registries use host-registered binding IDs and right-biased union:

Parent exports are bound to parent identifiers and state digests. Ancestor entries compose at recorded versions from root to parent, then local modules; overrides preserve ancestor sources and local ownership/version lineage. Under identical validation tasks, trial count, and budget, the updated parent is retained only with strictly higher host-verified performance, measured by task-completion counts; otherwise, the previous registry is retained.

Continual Refinement.

Let $P_v^{(i+1)}$ be the retained inherited registry and $\mathcal{D}_v^{(i+1)}$ the admitted-world curriculum conditioned on the fixed requirement, previous feedback $\mathcal{F}_v^{(i)}$, and prior coverage. Curricula may be renewed or reused. Explorer’s trajectories $\mathcal{Z}_v^{(i+1)}$ guide Evolver’s local update:

Trajectories record public observations, actions, host-assigned outcomes, and executed configurations. The host checks update evidence, ownership, interfaces, predecessor versions, and executable contracts. Accepted updates modify local state; rejection preserves it. The retained $L_v^{(i+1)}$ yields $\mathcal{H}_{\mathrm E,v}^{(i+1)}=P_v^{(i+1)}\oplus L_v^{(i+1)}$; local admission requires no score increase.

Subsequent training-side evaluation of the retained Harness yields $\mathcal{E}_v^{(i+1)}$ and next-iteration feedback

where $\operatorname{Feedback}$ retains verified observations, outcomes, failure evidence, and episode/module-version references for the next iteration. Completed nodes export retained state to children; sibling branches evolve independently. Explorer retains $\mathcal{H}^{(i)}=\{ \mathcal{H}_{\mathrm E,v}^{(i)}:v\in V\}$ for routing.

Creator Base Harness Update.

Creator’s Base Harness $\mathcal{H}_{\mathrm{C}}^{(i)}$ has module registry $R_{\mathrm C}^{(i)}$, initialized with pre-RSI modules at $i=0$. Creator evolves nodes in top-down order within each iteration. Root children start from this base; other nodes inherit their parent’s updated module configuration. Each node retains its own guidance. Verifier-detected failures trigger local evolution, yielding validated proposals $\Delta R_{\mathrm C,v}^{(i+1)}$. At iteration end, proposals and base modules are consolidated in learning order $\prec_{\mathrm C}$:

The resulting registry configures $\mathcal{H}_{\mathrm{C}}^{(i+1)}$, the Base Harness for the next iteration. Validated revisions replace predecessors; distinct capabilities are retained, partial overlaps are merged to preserve complementary functionality, and near-duplicates retain the earlier-learned module. Each binding retains one active definition and its provenance. Guidance, construction notes, and action budgets remain node-specific. Without accepted updates, the Base Harness remains unchanged. Explorer’s evaluation-time skills are prepared separately (§ 4.1.0.1).

Capability-Aware Harness Routing

Routing follows a context–action–feedback loop [65]. Let $x_n$ contain the public goal, initial observation, metadata, and images, and $\mathcal{C}\subseteq \mathcal{H}^{(i)}$ be the fixed, versioned Harness pool. Memory $\mathcal{M}_0$ is initialized by importing verified training-side categorization trajectories into empty memory once in file order (§ 3.2.0.2). These $\mathcal{H}_0$ executions record public context, the executed configuration, outcomes, and costs; unseen categorization records are excluded. The agent, prompt, candidate modules, retrieval settings, and verifier remain fixed.

For each task, candidate descriptions, retrieved experience $R$, and observed performance–cost summaries $S$ guide selection:

The agent commits $h_n$ with an evidence-based rationale before execution. Retrieval uses cosine similarity $\geq 0.5$, at most ten records, and a 20,000-record FIFO memory. Summaries include only matching executed configurations; untried outcomes remain unknown. Tasks are processed once in file order. After terminal receipts are verified against the committed decision and registry hash, outcome and cost $f_n$ update memory for later tasks:

Unseen task–capability assignments remain excluded from routing context, verification, and memory; they are accessed only for evaluation after the complete prediction ledger is hash-locked. Technical failures remain recorded and score zero; invalid selections receive no fallback.

Experiments

Experimental Setup

We use 28 training and 18 unseen benchmarks (Table 1; Appendix § 9). Train evaluates a fixed set of representative instances per benchmark over multiple episodes; Unseen uses each benchmark’s official evaluation set or a fixed official subset. Five experiments examine capability-driven organization, recursive self-improvement, capability-aware Harness routing, capability–module relationships, and embodied transfer of capability-evolved Harnesses.

Task domain	Train	Unseen
Rule discovery	[77],  [92],  [102],  [87],  [90],  [66],  [99]	[107],  [114],  [72]
Constrained problem solving	[82],  [97, 98],  [80],  [85],  [83]	[113],  [111],  [73],  [75]
Perception and control	[84],  [94],  [93],  [67],  [79],  [95, 96],  [101],  [103],  [104]	[105],  [111],  [71],  [104],  [74],  [103]
Multi-agent interaction	[86],  [78],  [88],  [89],  [91]	[89],  [108],  [109, 110]
Long-horizon environments	[100],  [81]	[112],  [106]

All variants share Base Harness $\mathcal{H}_0$ (Prime Agent) and a frozen Claude Opus 5 backbone [115]. Table 2 in Appendix § 12 reports metrics, instance and episode counts, and full results. Token costs are totals in millions (M); Tables tab:exp_1.3–tab:exp_4 report inference costs, and – denotes data not required.

Evaluation-Time Skill Preparation.

To reflect real deployment and account for each Harness’s effect on skill learning, we run five preparation trials per benchmark–Harness pair, summarize their trajectories into skills, and keep these skills fixed for subsequent evaluation on Train and Unseen.

Capability-Driven Organization

Preliminary Comparison: Modules and Skills.

Table tab:exp_1_2 compares four settings at . Base uses initial modules; evolves them; adds skills to Base; Ours combines both and performs best on Train and Unseen. Skills follow § 4.1.0.1. comparisons use to isolate the effect of Harness organization.

Organization Comparison.

Table tab:exp_1_1 compares five organizations after one RSI iteration to assess task grouping, hierarchical inheritance, and training curricula. Global pools experience from all 28 original environments into one shared Harness. Task-Domain learns 15 task-specific Harnesses, whereas Capability-Domain uses six flat capability groups.

Capability Tree (Real) and Capability Tree (Sim) use the same prefix-based topology, selective parent inheritance, and node-specific local refinement described in § 3.5. Real trains on original benchmark tasks; Sim uses verified synthetic worlds that preserve their decision processes. Domain/tree variants use one Harness and environment per domain/node. Training counts evolution-stage tokens; Inf. Train/Unseen count execution-only evaluation tokens.

Evaluation.

Flat grouping reduces training cost but underperforms Global: Capability-Domain uses the fewest training tokens at 136.94M, with Train/Unseen scores of 49.25/39.43. Capability Tree (Real) gains 4.19/2.88 points over this flat organization, supporting selective inheritance across shared capability prefixes. Sim adds another 3.51/4.95 points, reaching the best module-only scores of 56.95/47.26. Its inference costs are also lowest at 514.42M/549.07M. First-iteration training costs 405.70M, versus 211.56M for Real and 278.25M for Task-Domain.

Training Cost and Environment Reuse.

Figure fig:training_cost_analysis shows that Creator’s environment construction dominates the initial training cost. Reusing worlds reduces this overhead in later iterations. Explorer collects the same number of trajectories across iterations with comparable inference-token usage. Gains at fixed trajectory volume suggest that cleaner evolution signals from capability-focused environments support more effective Harness updates. Reuse thus amortizes construction costs as Train performance improves. Full results and the evaluation protocol appear in Appendix § 12, Table 2.

Image not extracted

Recursive Self-Improvement

Image not extracted

We track the RSI loop (§ 3.5) from Base (Iteration 0) through Iteration 4 to test whether improvements continue after the first update. With the benchmark split, capability requirements, tree topology, and backbone fixed, Evolver refines modules from training feedback, Creator renews or reuses curricula, and Explorer collects new trajectories.

Evaluation.

Figure 4 reports scores for 28 Train and 18 Unseen benchmarks, with five radial bars per benchmark. Scores retain benchmark-specific metrics on a 0–100 scale; Appendix § 12 gives full results and protocols. Figure 5 averages benchmarks equally. Train covers all 28 benchmarks, with a dashed curve for the 17 native benchmarks; Unseen and its Codex [68] and DeepSeek [69] references cover the 16 non-robot benchmarks. From Base to Iteration 4, Train rises from 39.1 to 73.2 and Unseen from 42.1 to 64.1. The first iteration yields the largest gains, but Iterations 2–4 add another 9.4 Train and 6.4 Unseen points. Native Train also improves from 64.4 to 68.8 after Iteration 1, with smaller later gains than the full Train mean. Progress varies across benchmarks: between Iterations 1 and 4, ARC-AGI-3 rises from 41.0 to 53.6, SciGym from 45.2 to 57.1, and BuildArena from 93.3 to 97.8. Mastermind stays at 88.9, while Eleusis declines from 82.2 to 81.1. The final Unseen mean exceeds the Codex (47.5) and DeepSeek (46.2) references, although Crafter and DiG-bench remain below both comparators (Appendix § 12).

Capability-Aware Harness Routing

We compare five configurations on the Iteration-4 Explorer Harness tree $\mathcal{H}^{(4)}$ (§ 3.6). Random selects one candidate Harness per task at random. Agent Self-Routing has three variants: public task information and interface descriptions alone; adding capability definitions, annotated branch cards, and aggregate observed performance–cost summaries; and further retrieving execution experience, yielding the full Harness Router. Oracle selects the best compatible Harness retrospectively per instance as an upper reference. In Table tab:exp_1.3, Cap. and Mem. denote explicit capability definitions and retrieved execution experience; these configuration columns apply only to self-routing variants.

Evaluation.

Table tab:exp_1.3 pairs benchmark-equal performance with estimated total inference tokens (M) for each split. Full self-routing scores 71.27 on Train and 60.96 on Unseen, compared with Oracle’s 73.16 and 63.61, respectively. The token estimates cover skill preparation, routing, and formal inference. Deployable variants share the frozen backbone, episode budgets (including routing calls), initial states, and seeds. Each Harness prepares and freezes skills under § 4.1.0.1 using matched instances and budgets. Neither skills nor preparation records enter routing decisions or memory; evaluation capability labels are also excluded from memory. Unseen routing starts from training memory, and verified feedback updates it only for later instances. Technical failures score zero; invalid selections

Capability–Module Relationships

Capability–Module Correlations.

Figure 6 reports Iteration-4 correlations for 29 modules. Rows abbreviate six shared capabilities: PST, perception and state tracking; HCI, hypothesis and counterpart inference; CFR, constraint checking and feedback repair; GVT, goal commitment and value trade-off; VEA, video evidence acquisition; and VC, video comprehension. Columns denote Perception, Memory, Inference, Planning, Orchestration, and Loop (§ 2.2), with coefficients in $[-1,1]$. The strongest positive association in each row links PST to Memory ($0.306$), HCI to Inference ($0.744$), CFR to Planning ($0.274$), GVT to Loop ($0.444$), and VEA to Perception ($0.347$); VC correlates equally with Perception and Memory ($0.286$). The most negative coefficients link GVT to Perception ($-0.361$) and PST to Loop ($-0.313$). These descriptive associations motivate the

Module Interventions.

Table tab:exp_4 evaluates module interventions on Train (the fixed instance set of § 4.1) with skills prepared under § 4.1.0.1. Scores are benchmark-equal means on a 0–100 scale; reported inference token totals are in millions (M). For addition, we randomly select one relevant or irrelevant module from the same library and add it to $\mathcal{H}_0$. Candidates pass interface checks and exclude installed modules; additions match protocol class and have comparable description lengths. Relevance follows fixed task requirements; irrelevant modules target capabilities outside both these requirements.

Adding a relevant module raises the Base score from 39.06 to 58.45 ($+19.39$), versus 40.08 ($+1.02$) for an irrelevant module; token totals are 551.85M and 583.37M, respectively, against Base’s 582.54M. Removing one relevant installed module from the intact Iteration-4 Harness lowers its score from 73.16 to 70.42 ($-2.74$) and raises tokens from 496.70M to 517.26M.

Embodied Transfer of Capability-Evolved Harnesses

Based on their capability requirements, we map the embodied tasks to the $d\!\to\!a$ node of the capability tree and adopt the Harness configurations evolved there. We then use Real2Sim2Real to learn task-specific skills (Figure fig:embodied_real2sim2real). For each task–Harness pair, we hold the Harness fixed, run five trial-and-error episodes in the reconstructed simulator, and summarize the trajectories into skills. These skills are frozen for formal simulation and real-robot tests; the five preparation episodes are excluded from test counts and success rates.

Protocol.

In SOON [103], a Unitree G1 approaches the desk beside a white fan and reaches towards it; real-robot success requires the target desk first ahead of the extended arm, within 30 cm. In CaP-X [104], an AlohaMini2 uncovers three inverted cups and reports a cube’s presence, colour, and location, or its absence. All five Harness configurations are evaluated with their own prepared skills. Appendix  gives action budgets, observations, and available trajectory records.

Evaluation.

Table tab:embodied_transfer compares all five Harness configurations after skill preparation. SOON improves from 0 to 80% in simulation and from 0 to 60% on the robot; CaP-X improves from 10 to 60% and from 0 to 60%, respectively. Both robots reach 20% with $\mathcal{H}^{(1)}$. SOON reaches its final real-robot score at $\mathcal{H}^{(3)}$, while CaP-X improves from 40 to 60% between $\mathcal{H}^{(3)}$ and $\mathcal{H}^{(4)}$.

Scope.

Recorded deployments differ in message handling, interfaces, guidance, and acceptance rules (including lifting versus pushing). These comparisons evaluate complete Harness–skill configurations and do not isolate the effects of module evolution and skill preparation.

Related Work

Recursive Harness Self-Improvement.

Self-improvement spans Gödel machines [1], LLM systems that rewrite their own agent code [10, 11, 12], automated agent design [16, 18, 17], prompt optimization [19, 20, 21], and learning from self-feedback and reflection [6, 7, 8]. With weights fixed, improvement shifts to the harness, which is synthesized from environment feedback [51], repaired from failed trajectories [54, 53], self-revised [13], optimized as code [14, 15], adapted at test time [56] or per task [48], improved at the meta level [45, 44], and shown to lift frozen MLLMs [41]; benchmarks and surveys map this space [57, 43, 58]. Closest to ours are JIT-Agent’s harness generator [23], HarnessX’s typed primitives [52], HSI’s per-task-family harnesses [36], ModularRSI’s modules evolved on benchmark-disjoint tasks [22], and the flat capability map of Harness Continual Learning [42] and regime-branched harness tree of Adaptive Auto-Harness [55], both evolved on the task stream. Trinity instead induces a capability tree from training trajectories, shares prefixes across 44 heterogeneous benchmarks with selective module inheritance, evolves Harnesses in Creator-generated worlds that exclude target-task layouts and solutions, and evaluates on held-out benchmarks and real robots. Unlike LLM routers [65], ours routes among capability-specific Harnesses over one frozen backbone.

Co-evolution of Agents and Environments.

Open-ended co-evolution [28, 29, 30], unsupervised environment design [31, 38], curricula [32, 33], and embodied co-design [39] adapt training to the learner; Voyager grows a skill library under an automatic curriculum [9]. Loops co-evolve language agents with environments [59], optimizers [60], or harnesses [61, 64]; environment generation spans embodied [25, 24], tool-use [47], and terminal settings [62, 63], language world models [27], and game verification [46]. SPADE is closest [37]: one LLM designs environments with verification code and learns roles by reinforcement learning. Trinity keeps the backbone frozen and couples world generation with Explorer and Creator Harness evolution along a capability hierarchy, execution outcomes refining Explorer and verifier-detected failures refining Creator.

Conclusion

We advocate Capability-Driven Recursive Self-Improvement and introduce The Trinity, a framework that couples world generation with Harness evolution through Creator, Explorer, and Evolver. By organizing heterogeneous tasks around shared capability requirements, the framework constructs simplified, verifiable worlds whose execution feedback guides the evolution of reusable modules. These modules form specialized Harness configurations, with capability–module correlations and controlled interventions providing empirical support for capability requirements as priors for module design and composition. To apply these evolved capabilities across tasks, capability-aware routing selects suitable Harness configurations using public task information and verified execution experience. Experiments across diverse training and unseen benchmarks demonstrate improved aggregate performance and cross-task generalization, while deployment in two real-world embodied settings further illustrates the transfer of these capabilities to physical environments.

Discussion

Limitations.

Our framework uses web search for benchmark discovery, but retrieval coverage and result quality may vary across queries. In addition, our current study focuses primarily on self-improvement at the Harness level.

Outlook.

Capability-driven learning offers a new paradigm for generalizable agent improvement, where shared capability requirements across tasks guide learning and optimization. Our framework and results at the Harness level demonstrate the promise of this perspective. Looking ahead, we envision dynamically expanding the capability tree to capture emerging capability requirements and extending this paradigm to model parameter training, where capability-aware routing and RSI form a closed loop that jointly drives capability discovery, acquisition, and refinement.

Authors

Core Contributors: Weidong Tang$^{1,2}$ Ruiheng Wang$^{3}$ Jingxuan Zhang$^{4}$ Hexin Wang$^{1}$

Contributors: Haoyuan Chen$^{1}$ Zhengfeiyang Zhang$^{1,4}$ Yixing Ma$^{1,5}$ Zichen Jiang$^{4}$ Ziyu Guo$^{6}$ Haodong Li$^{6}$ Zhengbo Jiao$^{7}$ Zhiqing Cui$^{7}$ Xinxiang Yin$^{8}$ Shuo Liang$^{1,4}$ Zhenglin Wan$^{4}$ Hongzhan Lin$^{4}$ Wangbo Zhao$^{7}$ Kaipeng Zhang$^{9}$

Corresponding Authors: Pengfei Zhou$^{1,4}$ Odin Zhang$^{6}$ Yang You$^{4}$

Affiliations: $^{1}$ InfRec $^{2}$ Xidian University $^{3}$ Tongji University $^{4}$ National University of Singapore $^{5}$ University of California, Berkeley $^{6}$ The Chinese University of Hong Kong $^{7}$ The Hong Kong University of Science and Technology $^{8}$ The University of Hong Kong $^{9}$ Shanghai Innovation Institute

Task Tree

The benchmark inventory comprises 44 benchmarks organized into five domains and 15 subclasses (Figure 7): 26 training benchmarks, 16 unseen benchmarks, and two embodied benchmarks, SOON [103] and CaP-X [104], each evaluated both in simulation and on a real robot (Appendix § 13). The five domains are Latent Rule & Mechanism Discovery; Constraint Solving, Puzzles & Design; Perception, Navigation & Control; Multi-Agent Strategy & Social Interaction; and Long-Horizon Open-Ended Environments. Counting the simulation version of each embodied benchmark as a training benchmark and its real-robot version as an unseen benchmark gives the 28 training and 18 unseen benchmarks of § 4.1. Every subclass contains at least one training and one unseen benchmark.

Candidate benchmarks were collected through agent web search over five types of source: research benchmarks released with code or data, public AI competitions, human contests and testing standards, published games and puzzle communities, and professional practice. Because a multimodal agent must perceive its world through whatever interface that world exposes, the inventory spans every input modality in which agentic tasks are posed, and each benchmark retains the observation protocol of its source. Each modality probes a different part of an agent’s capability. Image input (photographs, rendered scenes, puzzle images, and robot camera views) tests perception from pixels, viewpoint selection, and the grounding of decisions in what is seen. Video input tests evidence acquisition over time: selecting frames within a budget, tracking events across them, and understanding what happened. Boards, grids, and maps rendered as text test spatial reasoning and state tracking over a symbolic visual state; with pixel-level perception removed, a failure can be attributed to reasoning rather than to seeing. Plain text tests the capabilities a multimodal agent relies on downstream of perception: rule discovery, experimental design, planning, negotiation, and strategic interaction. Keeping all four modalities in one inventory lets visual and text benchmarks share nodes in the capability tree (Appendix § 10).

Nine of the training sources publish their rules but provide no agent-facing environment: Chess Tactics [82], Eleusis [77], Euro NCAP AEB [79], Master Keying [83], Micromouse [67], Pallet Rack Inspection [84], Saboteur [78], The Long Dark [81], and WCA Cube Solving [80] (marked * in Figure 7). We rebuilt each of them through agent web search from the published rules and examples, preserving the mechanics, information access, and scoring of the source; the rebuilt environments present their state to the agent as images or symbolic text. Every unseen benchmark other than the two real-robot versions runs on its official environment or evaluation code, e.g., the BALROG harness [70], the PHYRE simulator [71], the DiG-bench server [72], the ALE-Bench judge [73], the Video-MME-v2 scorer [74], and the Besiege game of BuildArena [75].

Capability Tree

Independent agents propose capability categories from the task specifications and verified trajectories of the training benchmarks, a judge consolidates them, and reviewers independently check definitions, evidence, assignments, and coverage. The result is six capabilities and 30 defect types (Table tab:defects): a Perception & State Tracking (PST), b Hypothesis & Counterpart Inference (HCI), c Constraint Checking & Feedback Repair (CFR), d Goal Commitment & Value Trade-off (GVT), e Video Evidence Acquisition (VEA), and f Video Comprehension (VC). Each defect type is an observable failure pattern that evidences a gap in its capability. Every training record is used for capability induction, tree construction, level generation, module evolution, and the Router’s training memory. Unseen benchmarks are recorded only after all Harness training has finished, from their runs with H$_0$; these records go through the same categorization procedure and are anchored to the fixed taxonomy without changing it.

The six capabilities are parallel and non-overlapping, with no causal relation among them; ordered by the breadth of the domains each capability spans, the fixed order c, d, a, b, e, f defines the paths of the capability tree, and most benchmarks require more than one capability. The flat capability tree (Figure fig:flat-tree) shows this directly: each capability lists every benchmark that requires it, so a benchmark with several requirements appears under each of them.

The capability tree (Figure fig:capability-tree) organizes the same assignment by combination: the requirement set of each training benchmark, sorted in this order, forms a path from the root, and these paths are merged along their common prefixes. Each node stands for one combination of capabilities, read along the branch from the root: for example, node c holds the benchmarks that require constraint checking alone, its child c$\to$d those that also require goal commitment, and c$\to$d$\to$a those that further require perception and state tracking. A benchmark sits at the node of its own combination, regardless of its domain. AdaPlanBench, Master Keying, Memory Maze, Pooltool Billiards, and TextQuests, for instance, come from three domains and differ widely in content, from adaptive planning and lock-system design to maze navigation, billiard shots, and text adventures; yet they share the same capability requirements and therefore all sit at c$\to$a. An edge adds a capability; it does not imply any dependency or causal relation between the two capabilities. The 11 non-root nodes define the shared structure of the Explorer and Creator Harness trees, and both evolve along the paths and structure of the capability tree (Appendix § 11). Unseen benchmarks are then placed at the nodes of their combinations without modifying the tree.

Harness Tree

Explorer and Creator both start from H$_0$ and evolve along the same capability tree, but they retain their learned modules differently. Explorer keeps a Harness at every node except e: each node selectively inherits its parent’s modules and refines its own local modules, and the resulting Harness tree is retained for routing. Creator keeps a single shared library: within an iteration, its node Harnesses inherit updated parent modules, and at the end of the iteration the modules proposed at all nodes are consolidated with the current library into the Base Harness of the next iteration. Explorer’s trajectories drive Evolver’s local module revisions, whereas worlds rejected by the verifiers drive Creator’s module proposals. Every module is a versioned function behind a prompt-facing interface and is installed only after the host checks its evidence, interface, and version lineage.

Explorer Harness Tree

Explorer plays every benchmark with the frozen backbone (Appendix § 12), and each instance uses the best-scoring compatible node Harness under the Oracle setting. Every node Harness starts from H$_0$, which has no learned module, and combines the inherited modules at their retained versions with the node’s local modules; a benchmark at c$\to$d$\to$a therefore uses the modules of c, c$\to$d, and c$\to$d$\to$a, subject to selective inheritance (Figure fig:explorer). At each node, Explorer plays the admitted training levels with these modules, and Evolver compares successful and failed trajectories to create or revise local modules; the host validates evidence, ownership, interfaces, and version lineage before every update, and ancestor modules are preserved. An updated parent is inherited only if it achieves strictly more host-verified task completions than the previously inherited modules under the same validation tasks, trial count, and budget; otherwise the previous modules are kept. A local module overrides an inherited module bound to the same identifier. Module calls take public inputs and return structured advice without advancing the environment, with at most two calls per step and none forced.

The catalog below lists the 29 modules M01–M29 of the Explorer Harness tree after the final iteration. Each was generated and revised during RSI; the modules are grouped by capability family: a Perception & State Tracking:  Object Evidence Ledger and Rule Classification;  Complete Inspection Coverage and Report Reconciliation;  Identity Binding Across Reversed Views;  Relational Orders, Identity Binding and Position Transforms;  Sealed Observation Archives and Unordered Collection Tours;  Ordered Prefix Validation and Capacity-Constrained Batch Planning;  Execution Receipt Verification and State-Difference Memory;  Stage Revision, Deduction Retraction and Execution Memory;  Target Collection, Current-Phase Routing and Frontier Exploration;  Product-State Routing for Ordered Collection;  Phase-Dependent Edge Repair and Static Corridor Reuse. b Hypothesis & Counterpart Inference:  Parity Reversal and Two-Period Signal Selection;  Contingent Policy Search with Endogenous Signals;  Opponent Inference, Allocation Scoring and Archive Value;  Candidate Ledger, Dynamic State Alignment and Dual-Objective Probing;  Decomposing Repeated Symbols into Multiplicity and Position. c Constraint Checking & Feedback Repair:  Joint Gate Planning, Proposal Validation and Milestone Scheduling;  Return Reachability Under Asymmetric Gates. d Goal Commitment & Value Trade-off:  Investment Timing and Scored Value Trade-offs;  Resource Reserves and Delivery Opportunity Trade-offs;  Goal Verification, Stopping Decisions and Plan Value;  Evidence Verification, Counterexample Stopping and Submission Budget;  Relation Verification Within One Object and Coordinate Frame;  Fixed Goal Conditions, Evidence Ledger and Bounded Commit Review. e Video Evidence Acquisition:  Adaptive Frame, Region and Audio Evidence Acquisition;  Delivered Evidence Coverage and Acquisition Budget Verification;  Evidence Gap Acquisition and Unproductive Retry Suppression. f Video Comprehension:  Handoff Episode Aggregation, Event Ledger and Endpoint Audit;  Candidate Identity Association Across Frames.

Creator Shared Harness

Creator builds the simplified training worlds of each node with a coding harness, created per node and iteration, with a workspace for the world and an evidence directory outside it. Its Base Harness at the first iteration is H$_0$ extended with the pre-RSI modules listed below. Within each iteration, Creator visits the nodes top-down: the children of the root start from the Base Harness, and every other node inherits its parent’s updated modules. Each node keeps its own guidance, one construction note, and one public action budget per iteration. Verifier-detected failures trigger local evolution, and at the end of the iteration the validated proposals of all nodes are consolidated with the current library in learning order (Equation (7)): validated revisions replace their registered predecessors; among new modules, distinct capabilities are retained, partial overlaps are merged to preserve complementary functionality, and near-duplicates keep the earlier-learned module and discard the later one. The consolidated library becomes the Base Harness of the next iteration; it is shared by all nodes and exposed as a single tool that runs one module per call. The host, not the model, supplies the inputs of each call: the build digest, the submission allowance, and, for a rule module, a measurement of the build. Fields that the host does not supply remain unknown, and missing evidence never passes. Before submission, the host reruns the applicable audits and blocks any missing, stale, or conflicting result; Creator returns errors in the frozen task design or verifier contract to their owner instead of rewriting them.

In the module names, a witness is a recorded route run on the current build; the commitment cost is the number of extra actions that a wrong commitment costs over the direct route; the screening band is the performance range into which a world must fall; and a neutralized control is the previous version with the changed difficulty axis reset. The final Creator module library holds 25 modules (Figure fig:creator). Eleven are pre-RSI modules, audits that form the initial module library of the Creator Harness and apply the host’s formulas to recorded routes, claims, edits, or submissions:  Commitment Cost Arithmetic Audit,  Witness and Action Ceiling Audit,  Difficulty Axis Range and Feasibility Audit,  Screening Band Direction Diagnosis,  Layout Novelty Ledger,  Effective Difficulty Change Audit,  Single Change Attribution Audit,  Repair Scope Gate,  Claim and Execution Evidence Census,  Bounded Search Declaration Audit, and  Submission Budget and Repeated Rejection Guard. The other 14 are rule modules, predicate programs over one kind of host measurement learned from rejected worlds, each listed with the nodes at which it was formed:  Production and Private Witness Isolation (d),  Accepted Entry and Terminal Consistency (d$\to$a),  Reasoning Change and Direction Audit (a, c, d$\to$a, e),  Public Visual State and Probe Coverage Audit (a, b, c),  Required Composition and Negative Route Audit (b, d$\to$b),  Target Attributes, Classes, and Acceptance Audit (a, b, c, d$\to$b),  Controlled Identity and Frame-State Alignment Audit (b, c, d$\to$a),  Action Polarity and Coordinate Basis Audit (a, b),  Interaction Coverage and Decision-Time Visibility Audit (b, d),  Neutralized Control Initialization and Completion Audit (b, d$\to$a),  Meaningful Exploratory Witness Pricing (e),  Submission Artifact Completeness (a),  Task Design Schema and Axis Type Handoff (c, d$\to$a), and  Authoritative Verifier Contract Handoff (all 11 nodes).

Evaluation Details

Every run uses the same frozen backbone, Claude Opus 5 [115] with adaptive thinking at low effort, and the benchmark’s native driver, which validates each action, returns the observation, and assigns the outcome. The Base Harness H$_0$ plays with no learned module and no skills; for H$^{(i)}$, each instance uses the best-scoring compatible node Harness under the Oracle setting, together with evaluation-time skills summarized from five preparation trials of that node Harness on the benchmark. Levels, action budgets, and scoring are fixed before the first run and shared by every Harness. Each benchmark reports performance on a 0–100 scale: task-completion, win, or solve rates where episodes pass or fail; the published bounded score where one exists; and, for ALE-Bench, the rank percentile among human entrants. The Codex Harness [68] and the DeepSeek Harness [69] ran the 16 unseen benchmarks other than the real-robot versions with the same backbone and settings through their native tool interfaces. Table 2 reports every score together with each benchmark’s measure, number of distinct instances, and number of episodes; * marks environments rebuilt from source rules through agent web search. Train benchmarks use their fixed instance sets (§ 4.1), and ARC-AGI-3 covers the 25 games of the public set. Six unseen benchmarks run on a fixed subset of their official set: Pencil Puzzle Bench uses the official Golden 30 set, PHYRE the 50 test tasks of fold 0 in the within-template B tier, and Video-MME-v2 a stratified subset of 400 of the 800 videos (1,600 questions); DiG-bench uses 13 of the 21 public games, all games of tiers 1–3 and the first game of each of tiers 4–7; ALE-Bench uses 26 of the 40 problems and SciGym 126 of the 137 small systems, those on which the backbone’s safety layer did not refuse the task inputs. NetHack is scored after a budget of 500 steps.

Train
* AdaPlanBench	accuracy, 3 queries, 27 episodes	22.2	70.4	74.1	74.1	74.1	HarnessMuted--	HarnessMuted--
Among Us	win rate, 3 games, 27 episodes	11.1	48.1	63	63	63	HarnessMuted--	HarnessMuted--
ARC-AGI-3	success rate, 25 games, 183 levels	22.4	41	45.9	50.3	53.6	HarnessMuted--	HarnessMuted--
BoxingGym	success rate, 3 environments, 45 episodes	60	80	84.4	84.4	84.4	HarnessMuted--	HarnessMuted--
Chess Tactics*	mate found, 3 positions, 27 episodes	66.7	92.6	96.3	96.3	100	HarnessMuted--	HarnessMuted--
Codenames	win rate, 3 games, 27 episodes	33.3	66.7	81.5	81.5	81.5	HarnessMuted--	HarnessMuted--
Colonel Blotto	win rate, 3 matches, 27 episodes	55.6	85.2	85.2	85.2	88.9	HarnessMuted--	HarnessMuted--
DiscoverPhysics	pass rate, 2 worlds, 30 episodes	40	70	73.3	73.3	73.3	HarnessMuted--	HarnessMuted--
Eleusis*	rule found, 6 rules, 90 episodes	43.3	82.2	81.1	81.1	81.1	HarnessMuted--	HarnessMuted--
Euro NCAP AEB*	success rate, 3 scenarios, 9 episodes	66.7	77.8	88.9	88.9	88.9	HarnessMuted--	HarnessMuted--
GLEE Persuasion	revenue$\geq$50%, 3 games, 27 episodes	33.3	63	63	63	63	HarnessMuted--	HarnessMuted--
Master Keying*	success rate, 3 designs, 33 episodes	45.5	84.8	84.8	84.8	84.8	HarnessMuted--	HarnessMuted--
Mastermind	solve rate, 3 codes, 45 episodes	53.3	88.9	88.9	88.9	88.9	HarnessMuted--	HarnessMuted--
Memory Maze	success rate, 3 mazes, 9 episodes	0	11.1	11.1	11.1	11.1	HarnessMuted--	HarnessMuted--
Micromouse*	success rate, 3 mazes, 27 episodes	55.6	66.7	66.7	77.8	77.8	HarnessMuted--	HarnessMuted--
Pallet Rack Inspection*	success rate, 3 racks, 27 episodes	0	29.6	37	37	59.3	HarnessMuted--	HarnessMuted--
PInVerify	accuracy, 3 pairs, 45 episodes	66.7	88.9	93.3	93.3	93.3	HarnessMuted--	HarnessMuted--
Pooltool Billiards	success rate, 3 seeds, 27 episodes	33.3	66.7	66.7	66.7	66.7	HarnessMuted--	HarnessMuted--
puzz.link / Penpa+	solve rate, 3 puzzles, 9 episodes	33.3	44.4	44.4	44.4	44.4	HarnessMuted--	HarnessMuted--
PuzzleScript	solve rate, 3 levels, 9 episodes	66.7	77.8	77.8	77.8	77.8	HarnessMuted--	HarnessMuted--
Saboteur*	win rate, 3 games, 27 episodes	55.6	77.8	77.8	77.8	77.8	HarnessMuted--	HarnessMuted--
TextQuests	success rate, 3 games, 9 episodes	0	11.1	11.1	11.1	22.2	HarnessMuted--	HarnessMuted--
The Long Dark*	success rate, 3 runs, 27 episodes	77.8	88.9	88.9	88.9	88.9	HarnessMuted--	HarnessMuted--
Video-Index	accuracy, 777 questions, 777 episodes	47.9	87.5	87.5	88.9	89.4	HarnessMuted--	HarnessMuted--
WCA Cube Solving*	solve rate, 3 scrambles, 45 episodes	13.3	51.1	80	80	80	HarnessMuted--	HarnessMuted--
WILT	accuracy, 8 rules, 120 episodes	80	94.2	94.2	94.2	94.2	HarnessMuted--	HarnessMuted--
SOON (simulation)	success rate, 1 route, 10 episodes	0	20	20	80	80	HarnessMuted--	HarnessMuted--
CaP-X (simulation)	success rate, 10 layouts, 10 episodes	10	20	30	40	60	HarnessMuted--	HarnessMuted--
Unseen
* ActiView	accuracy, 1,625 questions, 1,625 episodes	73.5	93.7	94.6	95.7	97.4	77.2	73.7
ALE-Bench	percentile, 26 problems, 26 episodes	81.3	85.4	86.4	87.4	91.9	85	91.4
BuildArena	pass rate, 9 levels, 45 episodes	73.3	93.3	95.6	95.6	97.8	77.8	80
Coup	win rate, 40 games, 40 episodes	45	57.5	57.5	65	65	32.5	35
Crafter	progress, 10 seeds, 10 episodes	51	56	57	58	60	82.7	70
DiG-bench	levels passed, 13 games, 13 episodes	32.5	33.3	34.2	35.1	36.8	40.4	54.4
Entity Deduction Arena	success rate, 200 entities, 200 episodes	64.5	95	95	94.5	95	72.5	67.5
Hanabi	success rate, 40 games, 40 episodes	0	5	10	15	20	0	0
Heads-Up NL Hold'em	matches ahead, 20 matches, 20 episodes	60	80	80	80	85	30	35
MiniHack Boxoban	solve rate, 10 levels, 10 episodes	0	10	20	20	30	10	0
MiniHack Maze / Corridor	success rate, 20 levels, 20 episodes	55	80	80	80	85	60	75
NetHack	progress, 5 seeds, 5 episodes, 500 steps	2.2	3	3	3	4	3.7	2.3
Pencil Puzzle Bench	solve rate, 30 puzzles, 30 episodes	20	26.7	26.7	26.7	30	23.3	23.3
PHYRE	solved, 50 tasks, 50 episodes	42	82	86	86	90	84	52
SciGym	recovered, 126 systems, 126 episodes	25.4	45.2	47.6	50	57.1	26.2	33.3
Video-MME-v2	accuracy, 1,600 questions, 1,600 episodes	48.4	77.4	79.5	80	80	54.5	45.9
SOON (robot)	success rate, 1 route, 10 episodes	0	20	20	60	60	HarnessMuted--	HarnessMuted--
CaP-X (robot)	success rate, 10 layouts, 10 episodes	0	20	20	40	60	HarnessMuted--	HarnessMuted--
Train mean (26 benchmarks, excluding SOON and CaP-X)	41.68	67.17	71.03	71.68	73.40	HarnessMuted--	HarnessMuted--
Train mean (28 benchmarks)	39.06	63.80	67.75	70.85	73.16	HarnessMuted--	HarnessMuted--
Unseen mean (16 benchmarks, excluding SOON and CaP-X)	42.13	57.72	59.57	60.75	64.06	47.49	46.18
Unseen mean (18 benchmarks)	37.45	53.53	55.17	59.56	63.61	HarnessMuted--	HarnessMuted--

Visual Record

This appendix records what the agent sees and does. Appendix § 13.1 pairs H$_0$ and H$^{(4)}$ on the same configuration of each of the 44 benchmarks and shows where the two Harnesses part in reasoning and in outcome. Appendix § 13.2 follows the 11 capability nodes through four iterations of training levels, from the benchmarks that feed a node to the modules its levels produce. Appendix § 13.3 presents SOON and CaP-X in their reconstructed simulators and on the real robots, with the runs of H$_0$ and H$^{(4)}$ in both.

Interaction Process

Figures fig:pair-first–fig:pair-last show the actual decisions and outcomes of the agent on each of the 44 benchmarks (26 training, 16 unseen, and the two embodied benchmarks in simulation): on the same configuration, the different Harnesses lead H$_0$ and H$^{(4)}$ to different reasoning and judgements, and hence to different results.

Node Training Levels

At every capability node, Evolver designs short training levels from the node’s requirement, and Creator implements and revises them under the Creator Harness of Appendix § 11.2; each level is a simulation world with a 3D scene, public rules, a fixed action budget, and a scorer, and one level per node and iteration gives 44 levels. Because e and e$\to$f form a separate path for video understanding, Video-Index, the only training benchmark with video input, feeds both nodes. Figures fig:node-first–fig:node-last show how each node evolves: on the left are the training benchmarks that form the node’s input, and on the right its four levels are played in turn, each tracing how the failure on that level is distilled into a new or revised module and how the next run with that module completes the level. The levels of a node keep one task family and raise the difficulty from iteration to iteration. At c, two robots deliver crates through gates that open only while the partner stands on a linked plate ( M07,  M08). At c$\to$d, a factory must meet orders due on fixed shifts under staged shortages ( M12,  M13,  M14). At c$\to$d$\to$a, ring-marked cells must satisfy relations set in stages ( M15,  M16). At c$\to$a, similar jars must be collected in a revealed order ( M10,  M09,  M11). At d, a claim may be submitted only once an object’s hidden faces have been seen ( M17,  M18). At d$\to$a, stamps and a parcel must be brought back while gates close on the return ( M19,  M20,  M21). At d$\to$b, a hidden pattern with repeated symbols must be identified by probes ( M22,  M23). At a, structural members are inspected for defects beside look-alikes ( M01,  M02,  M03). At b, tokens are allocated over three fields against a rotating formation ( M06,  M04,  M05). At e, the segments holding a parcel’s hand-offs must be bought within a budget ( M25,  M24,  M26). At e$\to$f, the parcel must be followed across hand-offs to its endpoint ( M28,  M27).

Embodied Benchmarks

The simulation of each embodied benchmark runs in an environment built from its real scene, which closely reproduces the layout and furnishings of the site, with a model of the same robot as the real runs: a Unitree G1 for SOON and an AlohaMini2 for CaP-X. For SOON we rebuilt the office from its floor plan and from photographs and video of the site: the side room where the robot starts, the doorway into the office, the rows of desks with their chairs and cabinets, and the white pedestal fan beside the target desk. The office is a 3D scene in which the walls and furniture are collision obstacles: each action moves the robot by the nominal distance or angle of the real robot’s motion profile, a move that hits an obstacle counts as a collision and ends the episode as a failure, and after every action the agent receives the head-camera image rendered from the robot’s new pose with the height, downward pitch, and field of view of the real camera. On the real robot a person judges every episode on site, and an episode in which the robot collides with an obstacle is a failure. The G1 starts in the side room, walks through the doorway into the office, and must stop at the desk next to the white fan and touch it within 30 movement actions. For CaP-X we built the table scene in the MuJoCo physics simulator [76] with the official AlohaMini2 model, and with objects of the same size and colour as the real ones: three paper cups, 9 cm tall, 7 cm across the mouth, and 5 cm across the closed bottom, stand upside down on a white table, and in most layouts a 2 cm cube, red, green, or blue, lies under one of them. The AlohaMini2 stands at the near edge of the table with its two six-joint arms; its mobile base and lift stay still. After every action the agent sees the head camera, the wrist cameras on both grippers, and a fixed side camera; it moves a gripper in small steps while the host solves the arm’s inverse kinematics, and within 30 actions it must report whether a cube is present and, if it is, its colour and the cup it is under. Figure 15 compares the real and simulated scenes directly.

Figure 16–Figure 19 compare H$_0$ and H$^{(4)}$ under the same task settings. In SOON, the robot must judge the distance to the target desk from head-camera images alone. H$_0$ looks around and reaches out as soon as the desk looks close, stopping about 0.5 m short in simulation and out of reach on the real robot. H$^{(4)}$ turns towards the desk right after the doorway and advances in small steps until the desk is directly ahead, so that in both settings the hand ends within the range judged as a successful touch. In CaP-X, the cube is hidden under upside-down cups and can only be found by uncovering them. H$_0$ grasps clumsily, knocks cup 1 over, tries cup 3, and then answers that there is no cube without ever examining cup 2. H$^{(4)}$ checks the cups one by one and answers only after seeing the cube: in simulation it lifts cup 1, finds it empty, retries a missed grasp on cup 2, and lifts it to reveal the green cube; on the real robot it pushes the cups aside until the cube lies uncovered. In both benchmarks, H$^{(4)}$ seeks direct evidence before committing and thus completes the task.