The Trinity lets agents self-improve by capability, not by task

The Trinity is a framework from a team at InfRec and several universities that lets an AI agent improve its own scaffolding by practicing on simple, auto-built training worlds grouped by the skills they need, not by the task they come from. In the paper posted on arXiv on October 26, the authors report that it lifted a frozen model's average score by 34 points across 28 training benchmarks and 26 points across 18 benchmarks it never trained on. It was one of the most upvoted papers on Hugging Face daily papers on October 28.

The model itself never changes. What changes is the harness around it, and that is the part most agent builders spend their time on.

What a harness is, and why it is the thing being improved

A harness is the code that wraps a language model and decides how it perceives, remembers, plans and acts. The paper splits it into six jobs: perception, memory, inference, planning, orchestration (picking which tools to use) and a loop that decides when to commit to an action. Each job is a module that can be swapped or rewritten.

Writing these by hand does not scale as tasks multiply. Earlier work on self-improving harnesses, the authors say, mostly targeted text tasks such as coding and math, and evolved a separate harness for each task. That can overfit. One global harness, on the other hand, struggles when tasks pull in different directions, for example speed against accuracy in robot tasks.

The idea: group tasks by the capability they need

The authors' central point is that tasks that look nothing alike can need the same skill. Their example: ARC-AGI-3 and Micromouse differ in structure, but both require tracking the state of the world accurately as it changes. So instead of one harness per task, The Trinity builds a tree of capabilities, with shared requirements near the root and more specific ones further down.

Three roles, all played by the same frozen model, run the loop:

• Creator builds simplified, verifiable practice worlds for each node of the tree. A node's worlds keep the decision logic that several real tasks share, and leave out the target tasks' layouts and solutions.
• Explorer plays those worlds and evolves the modules at each node. A child node inherits its parent's modules only if they score strictly higher on the same validation tasks.
• Evolver reads successful and failed runs to propose module updates, and builds the capability tree itself from verified trajectories.

The authors call the practice-world step Capability-Driven Real2Sim2Real: distill real tasks into a simple simulation, learn there, then measure on the original tasks. Because different branches of the tree specialize, the system also needs a router. An agent reads public task information, plus a memory of what worked before, and picks which harness branch to use.

The results

All variants use the same base harness and a frozen Claude Opus 5 as the backbone. The benchmarks span rule discovery, puzzles, perception and control, multi-agent games and long-horizon environments. Scores below are the paper's.

• Organizing by capability beat organizing by task. After one iteration with no skill preparation, a single global harness scored 53.04 on training tasks and 42.92 on unseen ones. A capability tree trained in simulated worlds scored 56.95 and 47.26. Per-task harnesses scored 51.17 and 40.82.
• Gains continued over four rounds. Training average rose from 39.1 to 73.2 and the unseen average from 42.1 to 64.1. The first round gave the largest jump. On the 16 non-robot unseen benchmarks the final average was above the Codex (47.5) and DeepSeek (46.2) reference means, though Crafter and DiG-bench stayed below both.
• Routing came close to a perfect pick. The full router scored 71.27 on training and 60.96 on unseen tasks, against 73.16 and 63.61 for an oracle that picks the best harness after the fact, and 52.74 and 46.23 for random choice.
• Relevance mattered. Adding a relevant module to the base harness raised its score from 39.06 to 58.45. An irrelevant one raised it to 40.08. Removing one relevant module from the final harness cut it from 73.16 to 70.42.
• Real robots improved too. On two embodied tasks, success rates went from 0 to 60 percent on a real robot for both. Simulation runs went from 0 to 80 percent on one task and 10 to 60 percent on the other.

Not every benchmark moved. Mastermind stayed at 88.9 and Eleusis slipped from 82.2 to 81.1 between iterations 1 and 4.

What to be careful about

• The numbers come from the authors. The paper is a preprint and nothing in it was independently reproduced.
• The abstract's 26-point unseen gain covers 18 benchmarks including the two robot tasks. The text's 42.1 to 64.1 figure covers the 16 non-robot ones.
• The robot comparison, the authors note, tests whole harness-plus-skill setups and does not separate the effect of module evolution from that of skill preparation. Each task had few trials: the table steps in 10 and 20 percent increments.
• The system used a lot of compute. Evolution on the simulated tree cost 405.7 million tokens in the first iteration, versus 211.6 million for the real-task version, mostly from building the worlds. The authors say reusing worlds lowers this in later rounds.
• The authors list two limits: benchmark discovery by web search varies in quality, and the study improves the harness only, not model weights.

Why it matters

If you build agents, the practical takeaway is the grouping. The paper gives evidence that a module's value depends on whether it matches the task's required capability, such as state tracking or constraint checking, and that a router can choose among specialized harnesses at close to oracle quality. The authors say they want to extend the approach to training model weights, but that is not tested here.

The code is on GitHub and there is a project page. For related work on agents, see our earlier article on DynaFlow.