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

Overview

Researchers from InfRec, Xidian University, Tongji University, NUS, UC Berkeley, CUHK, and other institutions propose The Trinity , a full-modal full-task recursive self-improvement (RSI) framework that changes the basic evolution unit from tasks to capabilities . The system employs three roles — Creator (builds worlds), Explorer (explores worlds), and Evolver (analyzes feedback and guides improvements) — all using a fixed base model while improvements occur at the harness level.

After four RSI rounds, The Trinity improves average scores by 34.1 points on 28 training benchmarks (ARC-AGI-3, buildarena, video mme v2, phyre, SOON, CaP-X, etc.) and 26.2 points on 18 unseen benchmarks . It also demonstrates sim-to-real transfer: on two embodied tasks (SOON with Unitree G1, CaP-X with AlohaMini2), success rates rise from 0% to 60% each.

Bottlenecks in Task-Driven RSI

Current RSI loops optimize around individual tasks: execute, get feedback, adjust prompts/tools/flow, repeat. Scaling to multimodal long-horizon tasks introduces two bottlenecks:

Environment construction at scale — diverse observation forms, state spaces, action rules, and success criteria across ARC-AGI-3, interactive games, GUI operation, robot navigation/manipulation make manual environment building unsustainable.

Harness iteration at scale — agent performance increasingly depends on prompts, tool configs, and execution flows; manual harness design cannot keep pace with task diversity.

Automating both via agent-environment co-evolution helps but raises a deeper issue: 100 optimized solutions may remain 100 independent local optima rather than cumulative progress. Two intertwined problems emerge:

Experience organization — task-centric accumulation limits transfer; merging all into one harness causes interference.

Evolution mechanism — improvements must be retained, inherited, reused, and gradually adapted across capability demands, not re-optimized from scratch each time.

Two Core Mechanisms

1. Agent–Environment Co-evolution

Environments generate and adjust training challenges based on agent performance; agents use environment feedback to continuously improve harnesses. Mutual drive reduces manual dependency, enabling scalable recursive improvement.

2. Shared Capability Requirements

Different tasks (e.g., ARC-AGI-3 and Micromouse) may rely on the same underlying capability (accurate perception and state tracking). A task needs multiple capabilities; a capability serves multiple tasks. Organizing experience around shared capabilities turns scattered task feedback into shareable, transferable learning signals.

The Trinity Framework

1. Task Tree → Capability Tree: Reorganizing Experience

Collect multimodal tasks into a Task Tree, run initial harness to get verifiable interaction trajectories. Evolver analyzes task definitions and execution traces to extract required capabilities and failure decision points. Rebuild a Capability Tree where paths represent capability combinations, not task categories. This gives scattered benchmark experiences a common organizational basis.

2. Capability-Driven Real2Sim2Real: Training Environments Around Capabilities

Traditional Real2Sim2Real replicates specific real tasks. Here, for each Capability Tree node, Creator extracts shared decision mechanisms across relevant tasks and generates simpler, verifiable simulated worlds. Example: multiple tasks require verifying evidence sufficiency before acting → environment designed around that decision process, omitting unrelated visual details, scene structure, action rules. Explorer learns in these simulations; original benchmarks test transfer. Key principle: retain the decision mechanism to be learned, reduce irrelevant complexity, obtain cleaner evolution signals .

3. Harness Tree: Making Existing Improvements the Starting Point for the Next Round

Harness decomposes into modules: Perception, Memory, Inference, Planning, Orchestration, Loop. Explorer evolves harnesses node-by-node along the Capability Tree. Each node can selectively inherit parent modules and modify/add modules based on its own failure trajectories. When tasks demand more capabilities, the system continues improving on existing configurations rather than rebuilding from zero. Branches share modules while retaining specialized modifications. Over iterations, a Harness Tree forms. Creator also improves its harness based on environment validation failures, integrating verified modules each round for next-round environment building.

4. Capability-Aware Router: Selecting the Right Harness for New Tasks

With specialized harness branches, a Capability-Aware Harness Router chooses the appropriate harness for a new task using public task info, candidate harness capability descriptions, and past verified execution experience. It does not need ground-truth capability labels nor a monolithic all-module harness. This completes the loop: tasks → capability demands → Creator generates environments → Explorer evolves modules → Harness Tree retains improvements → Router deploys suitable configs to new tasks.

Experimental Analysis

1. Task vs. Capability Organization

Comparing experience organization methods and Capability-Driven Real2Sim2Real benefits. Although sim-first construction cost is higher, environments are reusable in later iterations and inference cost is lower. Organizing by capability and generating training environments for shared capabilities yields better cross-task transfer, demonstrating "less is more."

2. Agent as Router: Can Specialization Be Matched Correctly?

Harness Tree allows branch-specific optimization, but wrong selection negates specialization. Compared different harness selection methods. This justifies avoiding a single ever-growing unified harness: different tasks rely on different module combinations, and selection itself becomes a learnable agent capability.

3. Capability–Module Relationships

Analyzed 29 modules vs. six capability classes after round 4 RSI. Different capabilities show distinct module preferences, confirming that capability divisions can guide harness module selection and combination.

4. Customizable Capability Tree: From Fixed Topology to Structure Exploration

Current The Trinity builds Capability Tree from training tasks and evolves harnesses on a fixed topology. Limitations: structure won't dynamically adjust with further learning. Team open-sourced an exploratory experiment supporting custom capability nodes, adjustable hierarchy/branching, and per-node simulation environments, enabling RSI experiments under different capability organizations. Open questions: which capabilities to share vs. evolve independently? How do tree structures affect harness inheritance/specialization? Should capability tree stay stable or allow node splitting/merging/reorganization as tasks expand? The next step: make the capability tree itself an optimizable, evolvable object — joint evolution of capability structure and harness.

Conclusion

Task-centric RSI risks local optima and non-transferable experience. Capability-driven RSI uses shared capability demands as the improvement driver. The Trinity organizes environment building, experience accumulation, and harness evolution under a common capability structure: cross-task reuse via shared capabilities; branch-wise harness evolution preserves optimization directions, enabling inheritance, adjustment, and combination of prior improvements. This mitigates overfitting and reward hacking from task-level optimization, turning local performance gains into generalized capability accumulation.

Paper & Resources

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

Code: https://github.com/InfRec-Cardinal/The-Trinity

Paper: https://arxiv.org/abs/2610.36077

Project Page: https://trinity-rsi.github.io/

Hugging Face Daily Paper: https://huggingface.co/papers/2610.36077