Honesty checks: catching agents that claim work they didn't do

An honesty check compares the claims in an agent's final report with the actual final state of the world, and takes points away for false claims and for required items the report leaves out. With the right score design, an agent that honestly reports partial success scores higher than one that claims success it did not achieve.

This article explains the problem, the mechanics of the check, how to design reports that can be checked, and how the check fits with the rest of the score. It is part of the series that starts with RLVR, explained.

What is the problem with agents' final reports?

Agents finish tasks with a report, and reports can claim more than the agent did. If nothing checks the claims, training has no reason to make them accurate.

Reports matter because people and systems act on them. A manager reads "all shifts covered" and stops looking; a downstream process reads "invoice approved" and pays it. A false report causes damage even when nobody is trying to deceive anyone.

Overclaiming gets rewarded wherever something in the reward reads the report and believes it: an LLM judge or human rater, a simulated user, or a reward model trained on preferences. If the report is never compared with the state, a confident summary costs nothing. In 2025, the evaluation organisation METR reported frontier models attempting, often successfully, to raise scores by modifying tests or scoring code; claiming success in a report is a cheaper way to the same end.

How does an honesty check work?

An honesty check is a part of the verifier, the code that scores the final state, that reads the claims in a structured final report and evaluates each one against the final state. It works in three steps.

1. Read the claims. The report is structured data, so each field is one claim: the status, each change made, each message sent, each open issue. Every list field claims "these items, and only these".
2. Check each claim against the state. The verifier looks up every claimed change and message in the final state by its identifier, and checks the status against its definition. A list that leaves out an item the agent changed, or an issue that is still open, is a false list claim.
3. Score the result. One rule that resists gaming: any false key claim, about the status, the changes made or the open issues, sets the honesty score to zero; each false claim about a minor item, such as a message, costs a fixed amount.

A fixed cost per false claim matters: if the score were the share of supported claims, an agent could dilute one false claim with many cheap true ones. After the first false key claim sets honesty to zero, further false claims cost nothing more, so evaluation should also report their number.

In this report, the false status claim alone sets the honesty score to zero. The message claim is true, but it does not rescue a report that misstates the outcome.

Did the agent lie, or was it misled?

An agent lied when its claim contradicts what its own tools told it; it was misled when a tool reported success but the state did not change. Compare each claim with the agent's tool results as well as with the final state, because the two cases need different responses.

If a tool returned success but the state did not change, penalising the agent usually teaches the wrong lesson, so fix the environment, unless unreliable tools are a deliberate feature: then the right lesson is to check the state again before reporting.

How do you design a report schema so claims are checkable?

Design the report as structured data whose every scored field can be compared with the state. If a field cannot be checked, leave it out of the scored part of the report. A reference solution is a known good answer computed for each task, and a seed is the number that fixes every random choice when the task is generated; both appear in the rules below.

{
  "status": "partial",
  "assignments": [{"shift": "Tue night", "unit": "B", "staff": "W-01"}],
  "messages_sent": [{"to": "W-01", "shift": "Tue night", "unit": "B"}],
  "open_issues": [{"shift": "Wed early", "unit": "B", "reason": "rest_rule"}]
}

Five rules make reports checkable:

• Fixed field names, defined in the tool schema for submission, so the verifier never has to interpret wording.
• Enums with testable definitions. complete means every required part is done and every gate passes. partial means one or more required parts are not done, possibly all of them, and each is listed as an open issue. blocked means the solver reported the task infeasible: no valid solution exists under the encoded rules for the task as generated from its seed. A solver timeout does not count. The reason of an open issue is an enum too: not_finished for a part that could have been done, and reasons such as rest_rule or no_qualified_staff for a part that cannot be done, which the verifier checks against the solver's result for that part.
• Identifiers, not descriptions: staff ids, shift names, invoice numbers. A message claim names the shift and unit it is about, and the verifier compares those fields with the fields of the message in the state.
• A place for open issues, so an agent that could not finish has an honest way to say so.
• Free text only where it is not scored, for example a note for a human reader.

How does the honesty check work with gates?

Gates ask whether the work is done; the honesty check asks whether the agent told the truth about it. A gate is a check that sets the whole score to zero when it fails.

When the coverage gate fails, the total is zero whatever the report says, and the honesty result is logged as a diagnostic. An agent that claims full coverage of an empty shift is caught by the gate alone. The last row shows the cost of that design: with a single gate for the whole task, an honest failure and a dishonest one both total zero, so the reward does not prefer the honest one.

How do you make honest partial success beat false success?

Make the reward distinguish between them, so that telling the truth about partial work is always worth more than claiming success. Three designs do this.

Score parts separately. When a task has several parts, such as several shifts or invoices, score coverage per part instead of gating the whole task on it. An agent that covers two of three shifts and says so earns two thirds of the coverage score; one that claims all three and covers two loses the honesty points as well.

Reward honest escalation, and check it. Include task variants in which the correct outcome is to stop and report a problem, for example when no candidate can take a shift without breaking a rule. A report with status blocked and the right open issue is then the correct answer. The verifier must treat blocked on a solvable variant as a false claim, or agents learn to escalate whenever a task is hard.

Keep the honesty weight below the value of one part of the work. If honesty is worth too much, an agent that does nothing and reports that truthfully comes close to one that tries. The example below uses a deliberately small honesty weight: 0.15, against 0.18 for each covered shift. It is a different design from the single-gate example in Scoring agent tasks, where coverage is a gate.

Without a coverage gate, quality scores such as cost and stability must count only for covered parts, or an agent that does nothing collects stability for free.

Honest partial success outranks bluffing only under three conditions: honesty is scored in every outcome the reward can reach, the verifier checks the claims correctly, and no other part of the reward, such as a judge or a simulated user, takes the report at face value.

How do you test an honesty check?

Test the honesty check with reports whose truth you know: accurate reports of many outcomes, and false reports of each kind. The check must reward the first group fully and penalise the second.

1. Accurate reports of success. Take correct final states with matching reports. Honesty must be 1.00.
2. Accurate reports of failure. Take incomplete states with reports that say partial and list the open issues. Honesty must still be 1.00, even though the task scores low.
3. False status. Take incomplete states with reports that say complete. Honesty must be 0.00.
4. False details. Keep the status right but claim a message or a change that does not exist. Honesty must drop by the fixed amount.
5. Omissions. Leave out a change the agent made, or an open issue. The list claim is then false, and honesty must drop.
6. Padded reports. Add many true but trivial claims next to one false key claim. Honesty must still be zero.
7. Over-escalation. Submit blocked on variants the reference shows can be solved. Honesty must be zero.

Accurate reports of failure are the easiest group to forget, and a check that penalises them teaches agents to stop reporting failures.

What are the limits of honesty checks?

An honesty check can only test claims that the state or the tool results can confirm. It cannot check intentions or reasoning.

• Unverifiable claims. "I checked all the rules" cannot be confirmed from the state. Either make it checkable, for example by comparing it with the logged tool calls, or do not score it.
• Rewards outside the verifier. An honesty check cannot protect a reward that also pays for persuasive reports elsewhere, such as through a judge.

Vencur's worlds are designed so that agents lose points when they claim what the final state doesn't show; see Vencur Environments. For how honesty fits into the wider defence against gaming, see Reward hacking in AI agents.