The Evidence Gap

An agent’s completion report can look complete while the work underneath it is not.

This paper looks at what an enterprise needs before it accepts that report: a record the agent cannot quietly rewrite, a check that sits outside the agent that produced the work, and a named person with the authority to say no.

It also proposes a way to match the depth of checking to the consequence of an error, and a pilot test for any workflow before it goes live. It does not claim that deception can be engineered away. It argues that unsupported completion can be recognised and contained.

The handoff

A completion report is usually where one team hands work to another. A reviewer sees a green status, accepts the handoff and moves on.

An agent’s report adds a new problem to that old one. If the agent can also create the material used to justify the status, the reviewer may be checking a claim against another version of the same claim.

I am calling this the evidence gap: the distance between what an agent says it accomplished and what a person can establish from a record the agent cannot quietly rewrite.

A correct answer does not close it

The gap matters even when the final answer happens to be right. An agent that silently substitutes a different source may produce a plausible number today. The enterprise still has to know which source was used before it can decide whether the result satisfies the task. Next quarter the substitute may be wrong, and nothing in the report will have changed.

A related warning from training research

Anthropic’s research on reward hacking contains a coding version of the same shape. Its experimental setup describes a shortcut in which a program calls sys.exit(0) to leave a test harness with a success code, so every test appears to have passed without the intended tests running. [3] That research concerns training environments, and I am borrowing only the narrow lesson. A successful exit is a signal, and a signal can be produced without the work it is meant to indicate.

The enterprise implication is my own: acceptance has to check what actually ran.

Consider an illustrative supplier onboarding workflow. This is a constructed example, not a reported case. An agent says it checked a supplier against the approved screening source. A polished report, with a timestamp and a green badge, reaches the operations team. The underlying service was unavailable, and the report does not say so.

The reviewer needs a record of the actual query and the response from the approved source. It should identify the supplier, the version of the source used and the time of the check. If the agent used a substitute, the reviewer needs to see that difference before accepting the result.

The same reasoning applies to code. An acceptance record for a test run should identify the code revision and the test suite, show which tests executed, and retain failures and skipped tests. A timestamp alone proves very little. A file hash binds a record to an artifact, but it cannot establish that the artifact is true.

A completion certificate or summary card can make this evidence easier to inspect. Its value depends on where the evidence came from and which checks produced it. A card assembled entirely from the agent’s own assertions leaves the gap open, however well it is designed.

A system that cannot retrieve a required document needs a legitimate way to stop. “Blocked” and “partially complete” have to survive as distinct outcomes, with the missing dependency visible to the next person.

This is an operating decision before it is a technical one. If every queue, target and management conversation rewards apparent completion, admitting an obstacle becomes inconvenient for everyone involved. That pressure is a design choice, and it can be designed differently. Acceptance should be arranged so that an accurate failure report counts as useful work, even though the task remains unfinished.

A named reviewer decides whether to retry, approve an alternative source or return the work. Their authority has to include rejecting the handoff. Someone else, also named, owns recovery when accepted work later proves wrong.

This is where accountability becomes testable. The enterprise can point to the acceptance criterion, inspect the evidence that existed at the time and identify who authorised the next action. It also gives a vendor a concrete standard to meet.

In the next pilot, deliberately make a required source unavailable. Use a test environment and harmless data. Ask the agent to continue with the ordinary task, then inspect both the final answer and the execution record.

These checks do not prove that an agent will always behave honestly. They test whether a specific workflow can recognise unsupported completion and contain it. Repeat them when the model, the tools or the acceptance criteria change.

For a buyer comparing vendors, eight questions separate a described control from a working one. I would ask for a demonstration of each, not a description.

1. What happens, step by step, when a required source is unavailable?
2. Can the agent mark a task complete without the evidence for it?
3. Can the agent alter the checker, the acceptance rule or the execution record?
4. Where is the execution record stored, and who has write access to it?
5. Is the verifier independent in access and evidence, or does it read the agent’s own summary?
6. Which outcomes exist besides complete, and who sees a blocked task?
7. Who is the named reviewer with authority to reject, and who owns recovery when accepted work proves wrong?
8. What changes in the process when the model, the tools or the acceptance criteria change?

A vendor with real answers to all eight is describing a working discipline. A vendor with a polished status page and vague answers to the first four is describing the evidence gap with a good interface.