Reinforcement learning with verifiable rewards (RLVR) trains an AI agent by letting it try the work, checking whether the result was right, and rewarding the ones that were. Repeat that enough times and the agent tends toward whatever the reward favors.
Imagine a new employee reviewing invoices. Tell them to approve one when the supplier and amount match the purchase order, and they know what to look for next time. Say only, “Looks fine,” and they learn nothing useful. An agent needs the same clear feedback.
So RLVR works best where correctness has a definition someone can point to:
- Did the code pass its tests?
- Did the answer match the known solution?
- Did the ticket reach the right team?
- Were the required fields filled in?
The closer the reward tracks your own definition of correct, the more the agent learns the job instead of learning to game the score.
What a verifier does
Picture a driving test.
The examiner doesn’t pass someone for looking confident behind the wheel. They check specific things: did the learner stop at the sign, hold their lane, follow the route, complete the maneuver safely. Every part of the drive is measured against a written standard, and the examiner’s job is to apply it the same way for every candidate.
A verifier does that job for an agent. It is the check in the loop: it measures an attempt against criteria your team has defined and returns a result the fine tuning system can use.
Say an agent decides where to route a support ticket. One verifier can check several things at once:
- Did the ticket land in the right queue?
- Did the agent weigh priority and customer tier before deciding?
- Are the required fields complete?
- Did it follow the approved process and leave the rest of the record alone?
A single attempt can pass some of those checks and fail others. The ticket can reach the right queue while the agent skips a step that exists for a reason. Break the attempt into parts and you see that. Look only at the outcome and you see something that looks fine.
Why measured repetition works
Now picture a golf simulator.
You hit a shot, sensors show exactly where the ball landed, and you adjust on the next swing. Each attempt teaches you something because the result is measured. Take the sensors away and you are hitting balls into a net, possibly improving, with no way to tell.
RLVR gives an agent the same kind of practice:
- The agent makes an attempt on a real case.
- One or more verifiers check the result.
- The system returns a reward.
- Over many rounds, the approaches that scored well become more likely.
Five terms are worth pinning down before going further.
- Model. The software that produces an answer or an action.
- Agent. The model put to work inside a task, taking steps through a workflow.
- Verifier. The check that decides whether an attempt was right.
- Reward. The signal that check produces.
- Environment. The practice setup: the cases, the tools, and the actions available, built to resemble the work closely enough to matter.
Tasks with an obvious standard
Some work makes verification close to mechanical.
Math. The agent solves a problem and the verifier compares its answer to the known solution. Wording can vary and still earn credit as long as the value is right.
Code. The agent writes a function and the verifier runs the tests. Passing tests are evidence the function works. Failing tests settle it.
Structured output. The agent returns a form or a JSON payload. The verifier confirms the payload parses, the required fields are present, the values are formatted correctly, and the intended action is represented.
Document retrieval. The agent answers a question from a source document and the verifier checks the answer against that source, including whether it cites the right passage.
A lot of the RLVR work you see published today focuses on tasks like these, which is part of why new reasoning models tend to arrive with math and code scores attached. The standard is written down somewhere, so the check comes out the same every time.
Company workflows are messier. The final state of a record usually tells you that something happened. It rarely tells you whether the decision behind it was right.
Where RLVR earns its keep
RLVR gets more valuable once an agent has to act inside a workflow instead of choosing a label from a tidy dataset.
Document review. An agent reads a document and decides whether to approve, flag, or escalate it. Verifiers can check whether the decision matches policy, whether the agent found the relevant evidence, whether it told an exception apart from a violation, and whether its explanation covers the reasoning. A well-written answer can still be wrong, or right for a reason that won’t hold next time. Separate checks expose that. A single pass or fail hides it.
Internal software. An agent opens a customer record, checks account details, looks up a policy, updates a field, submits the change, and leaves a note. Verifiers can score the end state, the path taken to reach it, and the format of the update.
Multi-step queue work. The routing example above extends the same way once the agent has to read the ticket, confirm an SLA, pull the customer’s history, and post an update. Every step leaves evidence a verifier can check.
In all three cases the agent is doing the work rather than picking an answer, and each action it takes is something you can grade.
When a status is not a verdict
A review queue looks like ready-made training data. Every row carries a final status, and those statuses look like judgments. Often they aren’t.
Suppose an AI system flags a line of marketing copy for breaking a claims policy. A reviewer opens the item and sees the text, the policy, a risk score, and an explanation. From there they might confirm the finding, decide the policy doesn’t apply, mark it for follow-up, close it without giving a reason, or leave it for a colleague. Several of those paths end in the same status, and the status never records what the reviewer believed about the finding itself.
Here is one finding on two different tickets: “The service will never lose your data” breaks the absolute-claims policy.
| What the reviewer found | Status | Verdict | Reason |
|---|---|---|---|
| An internal test page covered by a documented exception | SKIPPED | INCORRECT | Policy exception applies |
| Public marketing copy with nothing to support the claim | RESOLVED | CORRECT | Unsupported absolute claim |
Train on status and the two rows look like opposites for the wrong reason. Train on verdict and you get the distinction you wanted: the first flag was wrong in context, the second was right. The confusion runs the other way too. Two tickets can both end in SKIPPED when one reviewer judged the finding incorrect and another agreed with it but saw nothing worth doing.
So the question to ask of a historical record is not what happened to this item. It is what the reviewer decided about the finding.
Finding the verdict in your own records
A usable reward comes from the field where a reviewer recorded that decision: confirmed, incorrect, irrelevant, out of scope. Any of those is a verdict. A record with no explicit judgment is a workflow outcome. It still tells you about volume and case mix, but it says nothing about correctness.
Keep the training question narrow: given this evidence, is this finding valid in this context? A verifier can evaluate that. Asking an agent to reproduce everything behind a reviewer’s thinking, including policy, risk appetite, business context, and how busy the queue was that week, sets a target nobody can verify.
The gap between a record and a judgment shows up well outside review queues. A closed support ticket doesn’t prove the routing was right. A paid invoice doesn’t prove the amount hit the right account. A resolved security alert doesn’t prove the severity was classified correctly. In each case the operational record and the judgment behind it are two different fields, and only one of them belongs in a reward.
Keep correctness separate from risk tolerance
There is a pull toward writing your company’s risk appetite into the reward. Resist it. Risk tolerance is a business decision that can shift in a quarter without the definition of a correct decision moving at all.
If leadership gets more comfortable with automation and widens the range of cases the agent handles alone, nothing about what counts as a correct decision has changed. What changed is where you allow the agent to act. Keep the two settings apart. The verifier and the reward measure whether the call was right; your launch rules decide which calls are safe to automate today. Bundle them together and every policy change turns into a retraining project.
Test on cases the agent never saw
A strong training score means the agent learned the cases it practiced on. It says nothing about production.
After training, run the agent against held-out cases and compare its decisions to the recorded human verdicts. Overall accuracy is the least interesting number in that report. What you want to know is where it breaks down:
- Do the mistakes cluster around one policy, one content type, or one customer segment?
- How does it do on the ambiguous cases your reviewers argue about?
- How much of the queue could it cover at each confidence threshold?
- Does it escalate when the evidence is incomplete, or does it guess?
That backtest is where the automation boundary gets set: the point at which the business accepts the agent’s expected error rate and lets it act alone, with everything above that line staying with a reviewer. Training measures correctness. Deployment policy decides where correctness is good enough to trust.
When RLVR fits, and when it doesn’t
RLVR fits when three things are true. You can define a correct outcome, you can check it the same way every time, and the agent takes actions that leave evidence behind. Multi-step work benefits most, because a verifier can grade both the result and the steps that led to it.
It struggles when the reward is only standing in for correctness. Bare queue statuses, timer-based closures, outcomes driven by workload, records with no reviewer judgment, verifiers that check formatting while ignoring the result, and decisions made under policies you have since replaced all belong in that group. A weak verifier does more than fail to help. It creates an incentive to find the shortcut instead of doing the work, and the more capable the agent gets, the faster it finds that shortcut. What you end up with is strong scores on work nobody wanted.
If the job is predicting a label from a fully labeled dataset, supervised learning may be all you need. RLVR earns its extra complexity when the agent does the work and you can check its actions as it goes.
Start with the records you can defend
If your team spends review hours on work you would like an agent to take on, pull a sample of that history and go through it record by record:
- What was the original finding, and what evidence did the reviewer see?
- Did the reviewer record an explicit judgment about it?
- Is the final status a verdict or bookkeeping?
- Would a second reviewer understand why the decision was made?
- Could the same standard be applied to a new case?
Sort the sample into two piles: records that carry a verdict, and records that only show what happened. The first pile is the foundation for a verifier. The second is useful for understanding volume and edge cases, but it is not reward data.
A queue doesn’t become a training environment by existing. Someone has to define what the agent can see, which actions it can take, what counts as success, which steps are mandatory, which mistakes are disqualifying, how each verifier scores an attempt, which cases are held back for testing, and where the automation boundary sits. Do that work and you are no longer replaying old rows. You have a setup where an agent can attempt the work, earn a grade you can defend, and be measured on cases it has never seen.
Build the grade with Hookshot™ Environments
Hookshot™ Environments turn one of your workflows into a practice setup for agents. The agent sees a real case, takes an action, and gets scored by verifiers built from the judgments your reviewers already recorded. Those scores work two ways: they grade the agents you run today, and they train a better one.
Bring a sample of your review history. We help you find which records carry a defensible verdict, turn those verdicts into verifiers, design a backtest on cases the agent hasn’t seen, and set the automation boundary your business can accept.
