A Microsoft-affiliated group published Agent Lightning v1.0 on 18 August, arguing that the harness managing tools, context and control flow is a critical part of an agent system rather than scaffolding around the model. The original Agent Lightning introduced a disaggregated architecture connecting arbitrary agents to reinforcement learning through an LLM endpoint proxy, an approach the paper says was later adopted by verl Uni-Agent, AReaL 2.0, slime and Polar.
The paper names that arrangement harnessed agentic RL, where the deploy-time harness directly participates in model post-training, and its claim is that this differs fundamentally from traditional agentic RL: the harness, not the training engine, owns the environment interaction loop, while the trainer observes only sequences of LLM request-response pairs. That inversion is what creates the listed difficulties in retokenization, sample merging, advantage calculation and loss normalization — the trainer has to reconstruct structure it no longer controls.
This is the same conclusion arrived at empirically in an ARC-AGI-3 result showing the harness is part of the score, and it is the training-side counterpart to agent work moving into harnesses, factories and accepted artifacts. The agent harness hub tracks the pattern.
This is a preprint abstract: the framing and adoption list are the authors' own, and no independent reproduction is cited. The condition to watch is whether harnessed training runs publish the harness version alongside the model, because a result produced under an unnamed harness is not reproducible by anyone else.