By Microsoft released a reinforcement learning framework this month that trains your existing AI agent without touching a single line of agent code. The headline result: a Qwen3.5-9B model jumped from 41.8% to 56.4% on SWE-bench Verified — a 14.6-point absolute gain — using just 6,000 training samples on modest compute. Agent Lightning v1.0 is MIT-licensed, open source, and available now on GitHub.
The Problem It Actually Solves
Reinforcement learning for AI agents has always had an adoption tax: to train your agent, you typically had to rearchitect how it calls the model, rebuild how it handles tools, and gut the context management your team spent months tuning. For most engineering teams running production agents on LangChain, AutoGen, or CrewAI, that tax is too high. You do not retrain — you prompt engineer until you hit a ceiling.
Agent Lightning’s answer is a proxy. Instead of taking over the interaction loop, it inserts an API gateway between your agent and the model endpoint. Your agent keeps making the same API calls it always did. The gateway intercepts them, logs every request and response, and hands that data to the trainer. Your agent framework is untouched. Your tools, context management, and control flow all stay in the loop — which is exactly what you want, because that’s where your production logic lives.
What “Harnessed Agentic RL” Means
This approach has a name: harnessed agentic RL. The distinction is worth understanding. In standard agentic RL, the training engine owns the environment interaction loop — it simulates tool calls, manages state, and generally replaces the real agent harness. In harnessed agentic RL, the harness continues to own the loop. The trainer only observes sequences of LLM request-response pairs.
That matters because agents trained on simulated environments often fail to transfer to real ones. When your harness is in the training loop, you are training on production-representative behavior. The Agent Lightning paper credits this design with enabling generalization that simulated-environment approaches miss. Several frameworks that came after Agent Lightning — verl Uni-Agent, AReaL 2.0, Polar — adopted the same architecture, which is a reasonable signal that it solved a real problem.
Three Components, One Install
Agent Lightning v1.0 is built on three lightweight pieces:
- API Gateway — Proxies all LLM calls from your agent, stores rollouts, and forwards requests transparently. Your agent sees it as a regular model endpoint.
- Rollout Controller — Spins up your agent as Kubernetes Jobs (or local processes) for each training episode. Each run gets an isolated environment, which matters especially for coding agents that need sandboxed file systems and shells.
- Trainer — Built on verl and vLLM. Picks up rollout data, assembles training samples, and runs PPO or GRPO to update the policy. Also supports APO (Automatic Prompt Optimization) if you want a cheaper, non-gradient alternative.
The full implementation is approximately 3,500 lines of Python. Microsoft treated simplicity as a first principle in the v1.0 rewrite, and the line count reflects that. Installation is straightforward:
pip install agentlightningRequirements: Python 3.10 or newer, Linux (Ubuntu 22.04 or later recommended). macOS and Windows outside WSL2 are not currently supported.
The Benchmark Numbers
SWE-bench Verified is the current standard for coding agents. It tests whether an agent can resolve real GitHub issues — not contrived exercises, but actual bugs and feature requests from open-source repositories with verified ground-truth patches. Moving the needle on it is harder than the raw numbers suggest.
Using Agent Lightning’s RL training pipeline, a Qwen3.5-9B model improved from 41.8% to 56.4% on SWE-bench Verified. That’s 14.6 percentage points on a benchmark most teams treat as a ceiling, not a variable. The training run used 6,000 examples on hardware Microsoft describes as “modest compute” — not a hyperscale experiment reserved for teams with GPU clusters.
What to Watch Before You Commit
A few things worth knowing before you allocate sprint time:
- Reward function design is your job. Agent Lightning gives you the training infrastructure, but defining what “good” looks like for your agent is entirely on your team. Reward hacking is a real risk in coding agents; the framework surfaces full rollout visibility to help you debug it, but does not design rewards for you.
- v1.0 is a full rewrite. That is a good sign for the architecture, but expect some API churn in minor versions as the edges get knocked off.
- Linux only for now. Plan accordingly if your dev environment is macOS.
- Pair it with ThinkingBox. Microsoft also open-sourced ThinkingBox on August 19 — a benchmark framework that verifies agent reliability by checking actual database state changes rather than transcripts. Run it before and after training to measure real improvement.
Who Should Try This Now
Agent Lightning is a reasonable next step if you are running production agents on any of the major frameworks and you have hit the ceiling of prompt engineering. The zero-code-change architecture removes the biggest practical obstacle. If your team has already invested in Kubernetes infrastructure, native Job support is a further accelerant.
For teams earlier in the agent maturity curve — still iterating on tools and architecture — it is worth bookmarking for later. You need a stable agent and a clear reward signal before training makes sense. Build those first.
The official documentation includes an examples catalog with bite-sized scripts, a full coding-agent training example with reward-hacking prevention, and a RAG agent training walkthrough. The Microsoft Research blog post covers the design rationale in depth if you want the full picture before committing.
