Agentic RL

The model works over many turns, calling tools and reading their output, and is rewarded for finishing the whole task. The same algorithms, with new problems.

Key idea
Multi-turn episodes, loss masking, environments, and credit across turns
Real world
A mechanic fixing a car runs a diagnostic, reads the result, replaces a part, and tests again. They're judged on whether the car runs at the end, not on any single step.
In an LLM
A coding agent in a sandbox runs the tests, reads the failure, edits a file, and runs the tests again. The reward is 1 if the hidden tests pass when it's done.

What changes with agents

In single-turn RL, the episode is one answer. In agentic RL, an episode alternates between the model and an environment: the model writes a tool call, the environment runs it and returns output, the model reads that and continues. Episodes can run for dozens or hundreds of turns.

Try it

task
test_add fails. Fix calc.py so the tests pass.
Loss mask over the episode so far, one block per message, width = words
turns0
model words (trained)0
tool words (masked)0
The model chose what to run and what to edit; it did not choose what pytest printed. Only its own tokens get the advantage.
Purple text is trained on. With the mask on, the environment's replies are context only.

Train only on what the model wrote

The environment's output is part of the state, not an action. The model chose to run pytest; it didn't choose what pytest printed. So tool outputs are kept in the context but masked from the loss (ignored when working out what to learn). Training on them would teach the model to predict tool output, and to imagine results instead of calling tools.

example · the mechanic's version

When a mechanic's repair works, you credit their decisions: which test to run, which part to replace. You don't credit them for what the diagnostic machine printed. Training on tool output is like praising the mechanic for the machine's readout.

Credit across turns

A single reward at the end of a 50-turn episode says little about which turn mattered. Current approaches:

  • Outcome only: give every model token the episode's advantage, exactly like GRPO over long answers. Still the default.
  • Grouping by state (GiGPO): when different rollouts reach the same intermediate state, compare what they did next there.
  • Turn-level rewards: process rewards or judges that score individual turns.
  • A critic again: some 2026 recipes bring back a value model for long agent episodes.

Environments

An environment packages a task, a sandbox to act in, and a verifier. Examples:

TaskSandboxReward
Question answering with searchSearch APIExact match of the final answer
Fixing a GitHub issueContainer with the repositoryHidden tests pass
Terminal tasksShell in a containerFinal state checked by a script
Data analysisPython interpreterAnswer matches a reference

Each rollout runs in its own isolated container, and these are created and thrown away in huge numbers. Building enough realistic, hard-to-hack environments is now widely seen as the main bottleneck in agentic RL, and several labs and projects run shared environment hubs.

example · an environment that can be gamed

A coding environment rewards "all tests pass". The agent discovers it can edit the test file. The fix belongs in the environment, not the model: make the tests read-only, run hidden tests the agent never sees, and check the diff. See reward hacking.

going deeper

Masked loss

With a mask mt=1m_t = 1 for tokens the model generated and 00 for prompt and environment tokens:

L=−1∑tmt∑tmt A^ log⁡πθ(ot∣st)L = -\frac{1}{\sum_t m_t} \sum_t m_t\, \hat A\, \log \pi_\theta(o_t \mid s_t)

The importance ratios and clipping from earlier pages apply to the masked tokens unchanged.

Papers

Related

  • rl-loop - An agent acts, the world responds with a new state and a reward, and the agent learns to collect more reward. Every later page builds on these five parts.
  • async-rollouts - Generating answers takes most of the time in RL. Overlapping generation with training keeps the hardware busy, at the cost of training on slightly stale answers.
  • reward-design - When a program can't check the answer, or you want credit for individual steps, you need other reward sources. Each brings new ways to be gamed.