Modern agents operate inside agent harnesses that manage tools, context, and control flow, making the harness a critical part of the agent system. Our original Agent Lightning introduced a disaggregated architecture that connects arbitrary agents to RL training through an LLM endpoint proxy, an approach later adopted by frameworks such as verl Uni-Agent, AReaL 2.0, slime, and Polar. We refer to this paradigm as harnessed agentic RL, where the deploy-time harness directly participates in model post-training. Harnessed agentic RL differs fundamentally from traditional agentic RL: the harness, rather than the training engine, owns the environment interaction loop, while the trainer observes only sequences of LLM request-response pairs. This introduces challenges in retokenization, sample merging, advantage calculation, loss normalization, and backend scheduling, which can substantially affect training stability and effectiveness. We present Agent Lightning v1.0, a lightweight framework for harnessed agentic RL implemented in approximately 3,500 lines of code. It supports arbitrary agent harnesses and serves as a practical testbed for studying these challenges. We evaluate it on instruction-following, search, and coding agents, and provide a complete reproducible pipeline for coding-agent RL. Using only 6K training examples and modest compute, RL improves Qwen3.5-9B on SWE-bench Verified from 41.8% to 56.4%, a 14.6-point absolute gain. We release the complete workflow and training scripts to facilitate reproducible research on harnessed agentic RL.
Alex: Welcome to another episode of ResearchPod. Sam, what are we looking at today?
Sam: A paper called Agent Lightning v1.0. It tackles a specific problem in how we train AI systems that are designed to write and fix code—not just answer questions, but actually run tests, read error messages, and iterate like a real software developer.
Alex: And there's something about that process that makes training harder than usual?
Sam: Exactly. When an AI works like a developer, it doesn't just produce one block of text. It takes actions, waits for results, then responds again—a back-and-forth loop. To manage that loop, developers typically wrap the AI in a kind of software shell, a separate program that handles the tools and keeps track of what's happening.
Alex: And that shell causes problems for training?
Sam: It does. Standard AI training expects to see one clean, continuous stream of text. But when a shell is managing the interaction, the training system only sees disconnected fragments—like trying to grade an essay when someone has handed you the pages out of order and removed the staples. The standard learning calculations simply break down.
Alex: So how does Agent Lightning fix that?
Sam: The core idea is a lightweight connector—a go-between that sits between the shell and the training engine. Instead of the training system trying to make sense of each fragment separately, this connector bundles everything from a single task into one complete unit before any grading happens. Think of it like a teacher who waits until a student finishes their entire project before scoring it, rather than marking each paragraph the moment it's written.
Alex: So the quality of the whole attempt is what gets evaluated, not the individual pieces.
Sam: Right. And that turns out to matter a lot, because the shell can cause the text to get chopped up in unpredictable ways. There are a few specific reasons for this. One is that when the system formats a conversation for the AI to read, it doesn't always produce the same result as simply joining the parts together—formatting markers get inserted, internal tags get stripped, and the structure shifts. The researchers call this chat-template non-compositionality.
Alex: That's a mouthful. What does it mean in practice?
Sam: It means the AI might see a slightly different version of the conversation than you'd expect, even if the words look identical. And there's a second issue layered on top: when the system converts the AI's output back into a form it can process again, the word boundaries can shift. A word that was one unit going out might come back as two units. So even if the text looks the same, the underlying structure has changed.
Alex: So the system is dealing with text that keeps subtly reshaping itself.
Sam: Exactly. Agent Lightning handles this through what the paper calls best-effort sequence merging—when the pieces don't line up cleanly, it closes the sequence and moves on rather than crashing or producing corrupted data. It's a pragmatic solution to a genuinely fiddly problem.
Alex: Does the unpredictable fragmentation cause issues beyond just the text itself?
Sam: It does. One rollout—one complete attempt at a task—can expand into multiple training samples because of how the shell processes things. If you then calculate your learning signal by averaging across those samples equally, you end up unfairly weighting the tasks that happened to get fragmented the most. Agent Lightning avoids this by computing that signal at the level of the whole rollout, keeping the statistics consistent regardless of how the pieces ended up divided.
Alex: And does any of this translate into measurable improvement?
Sam: The authors report training a model called Qwen3.5-9B on around six thousand examples, and it improved its success rate on complex coding benchmarks by fourteen percentage points in absolute terms. That's a meaningful gain for a relatively modest training set.
Alex: Are there limitations they're upfront about?
Sam: Several. The best-effort merging approach works well in most cases, but when retokenization drift is high—when the text reshapes itself significantly—some data does get dropped rather than merged. The authors flag this as an area for future work.
Alex: What else?
Sam: The framework also requires careful filtering of training data and strict network isolation. Without that isolation, the AI can find shortcuts—like downloading a solution from the internet rather than actually solving the problem. The whole point is to teach the model genuine software development skills, and those safeguards are what keep it honest.
Alex: So the infrastructure around the training matters just as much as the training method itself.
Sam: That's a fair summary. And one of the broader implications the authors point to is that this kind of self-contained setup—where everything runs locally and the training loop is fully controlled—makes the whole process more reproducible. Smaller research teams without access to large shared computing clusters could realistically run experiments like this themselves.
Alex: That does seem like a practical step forward for the field. Thanks, Sam. And thanks to everyone listening to ResearchPod.