The Trinity: Capability-Driven RSI for Multimodal Agent Evolution

Introduction

Making an agent complete more tasks does not necessarily mean it is continuously evolving. The key challenge is how to consolidate scattered task feedback into shareable, composable, and continuously evolvable capabilities. Researchers from InfRec, Xidian University, Tongji University, and the National University of Singapore propose The Trinity , a multimodal recursive self-improvement (RSI) framework that organizes environment generation and agent evolution around capability requirements shared across tasks.

Framework Overview

The core idea is to shift the basic evolutionary unit of RSI from "task" to "capability", allowing improvements dispersed in different tasks to be shared, inherited, and further optimized. After four RSI rounds, the main experiment shows average score improvements of 34.1 points on 28 training benchmarks and 26.2 points on 18 unseen benchmarks , with preliminary transfer demonstrated on two real robot tasks.

From Tasks to Capabilities: Connecting Experience Across Tasks

In multimodal tasks, surface forms differ but underlying capability demands may overlap. For example, ARC-AGI-3 requires recognizing grid states and changes, while Micromouse requires continuous environment updating during maze exploration; both rely on accurate perception and state tracking. A single task may need multiple capabilities, and the same capability may serve multiple tasks.

The Trinity first collects diverse tasks into a Task Tree , then lets an initial agent execute them, recording verifiable interaction trajectories. The system then analyzes task definitions and actual executions to identify required capabilities and failure points, building a Capability Tree . Paths in this tree represent sets of capability requirements; tasks from different domains sharing these requirements become linked in a unified structure.

Capability-Driven Harness Organization

A Harness is the runtime framework organizing perception, memory, reasoning, planning, tool use, and execution around a base model. Optimizing per task yields isolated configurations; stuffing all experience into one Harness causes interference. The Capability Tree offers a third way: shared requirements accumulate common modules, while differentiated requirements branch out for specialized optimization . This creates a Harness Tree where experience has clear inheritance relationships, giving subsequent improvements a starting point.

Three-Role Co-Evolution: Creator, Explorer, Evolver

The Trinity uses three roles with a fixed base model; evolution occurs at the Harness level:

Creator : builds interactive, verifiable simulation environments.

Explorer : executes tasks, producing interaction trajectories.

Evolver : analyzes task demands and execution feedback to guide environment and Harness improvements.

Environment generation employs Capability-Driven Real2Sim2Real : extract common capability demands from raw tasks, transform them into simplified simulation environments, then validate transfer back on original tasks. For instance, if multiple tasks require the agent to verify information sufficiency before acting, the training environment focuses on the "gather evidence → check condition → decide action" loop, preserving the decision mechanism while reducing irrelevant scene complexity.

Generated environments undergo verification and difficulty filtering. Execution feedback improves the Explorer; environment construction failures drive the Creator to correct its own Harness, forming a mutually reinforcing loop.

Harness Evolution Along the Capability Tree

The Explorer learns node by node along the Capability Tree. Each node can selectively inherit parent modules and modify or add modules based on its own feedback. As capability demands grow, the system continues improving on existing configurations. Different branches retain specialized configurations, forming the Harness Tree. The Creator integrates verified module updates each round for the next round's environment building.

To deploy specialized configurations to appropriate tasks, The Trinity introduces a Capability-Aware Harness Router . It selects the suitable configuration based on public task information, candidate Harness capability descriptions, and past verified execution experience. Thus the loop closes: tasks provide capability demands, environments provide training feedback, modules save improvements, and the Router applies them to new tasks.

Experimental Results

Evaluation on 28 training benchmarks and 18 unseen benchmarks covering rule discovery, constraint solving, perception and control, multi-agent interaction, and long-horizon tasks. Over four iterations, the base model, capability categories, and Capability Tree structure remained fixed while modules and Harness configurations were updated.

The first round gave the largest boost; the next three rounds continued improving both training and unseen averages, showing the system can accumulate effective improvements along a fixed capability tree with benefits transferring beyond training tasks.

Ablation: Capability Organization vs. Simulation Environments

In the first round without Skills, using the same capability tree with raw tasks yielded training/unseen scores of 53.44 / 42.31 . Switching to capability-generated simulation environments raised scores to 56.95 / 47.26 . Although simulation environments incurred higher initial training cost, they are reusable in later iterations and reduce inference token consumption during evaluation. This supports the judgment that simplified environments focusing on shared decision mechanisms can provide effective training signals for cross-task transfer .

Harness Routing Effectiveness

Selecting Harnesses using only public task info and interface descriptions gave an unseen average of 52.36 . Adding capability information and execution experience retrieval brought the full Router to 60.96 on unseen benchmarks, with training score 71.27 approaching the Oracle reference of 73.16 / 63.61 .

Module Selection by Capability

Analysis of 29 modules and six capability categories after the fourth evolution round, plus module addition/removal experiments, showed that adding task-relevant modules to the initial Harness increased training average by 19.39 points , while adding irrelevant modules increased it by only 1.02 points . Removing relevant modules from evolved configurations caused performance drops, providing empirical evidence for "selecting and combining modules according to capability demands".

Real-World Robot Transfer

The evolved Harness was tested on two real robot tasks:

SOON : Unitree G1 must locate a target desk next to a fan in an office and move within reach.

CaP-X : AlohaMini2 must inspect an overturned cup, determine if a block is hidden, and report its color and position.

The team prepared task Skills in reconstructed simulation environments, then fixed configurations for real robot testing. In 10 trials each, the evolved Harness+Skill combination raised success rates from 0% to 60% (0 to 6 successes) on both tasks.

Conclusion

If RSI is always driven by independent tasks, the system tends to optimize around local objectives. Adding more tasks accumulates more solutions but does not guarantee those experiences connect into reusable capabilities. Expanding evolution scope, improving version selection, seed task sets, or involving decision agents in evolution all optimize the search and update process. Yet even with a perfect improver that retains all history, we must answer: which experiences should be shared, which modifications kept independent, and what should organize the evolution direction across tasks?

Capability-driven approaches use shared capability demands as the improvement basis. The Trinity organizes environment, experience, and Harness evolution this way, creating a structured training data distribution: connecting different tasks through shared capabilities, while preserving distinct optimization directions through separate branches . This organization lets local improvements accumulate into composable, transferable capability structures, and offers a potential path to mitigate overfitting and reward hacking. The key to RSI may not be merely completing more tasks or running loops continuously, but choosing what drives improvement and whether those improvements can crystallize into shareable, composable, and transferable capability structures.