When an experienced engineer says, "This is ready," the sentence carries an invisible record. They know which files changed, which test would catch the common regression, which part of the system is risky, and which concern was investigated and dismissed. A reviewer who knows the codebase can often reconstruct most of that context from a diff.

An agent does not share that history. Its completion message needs a visible basis.

The solution is not to attach every terminal line to every task. More output does not automatically produce more confidence. A thousand-line build log can conceal the one warning that matters, and a gallery of screenshots can make a missing data check look like thoroughness. The product problem is to create a legible link between a claim and the evidence that can reasonably support it.

Claims have different weights

Not every completion claim deserves the same evidence.

If the claim is that a label has changed on a marketing page, a screenshot at the relevant viewport and a diff may be enough. If the claim is that a payment integration remains compatible, the relevant evidence may include a contract test, a review of the API version, and a statement of the behavior that was not exercised. If the claim is that a migration is safe, the reviewer may need an execution plan, a rollback path, data-volume assumptions, and a record of how partial failure is handled.

The point is not to create a bureaucratic matrix for every task. It is to avoid the opposite failure, in which a single green check is displayed as general proof of correctness.

Claim	Useful evidence	What it does not prove
A visible interface behaves as intended	Focused interaction check and preview	Accessibility, performance, or production data behavior
A refactor preserves behavior	Targeted tests, type checks, and review of changed contracts	Uncovered integration paths
An external action is safe to take	Scoped request, preview, policy decision, and approval	Every downstream consequence
A data change is reversible	Tested rollback or recovery procedure	That real production data matches the test assumptions

An evidence surface should make these limits plain. Honest uncertainty is not a weakness in the task report. It is what lets a reviewer allocate attention intelligently.

Verification begins while the work is happening

Verification is often treated as the final stage: first build the thing, then prove it works. That ordering makes sense when implementation is slow and checks are expensive. It works poorly for agents, which can create a large change before a person has looked at the first artifact.

An agent should gather evidence as it reduces uncertainty. Before editing, it can identify the test that governs a behavior. After a local change, it can run the smallest check capable of disproving its hypothesis. Before asking for approval to publish a preview or send a message, it can present the exact action and why it is needed. At the end, the evidence is already attached to the decisions that created it.

This does not mean making the agent narrate every move. A concise record is better than a theatrical one. The important distinction is between a task that merely reports activity and a task that leaves behind the artifacts needed to assess its claims.

Consider a bug report about an export that silently omits rows. A weak completion message says that the export has been fixed and tests pass. A useful record says that the query previously filtered on a nullable field; the change preserves rows without that field; a regression test covers the case; the sample data did not include an unusually large export, so performance at that scale remains unverified. The second message does not sound more impressive. It is more useful.

Negative evidence is evidence

Teams sometimes hide failed attempts because they fear a task will look less competent. This produces brittle records. A test that failed and was understood may be one of the most valuable artifacts in the review, especially when it reveals the edge condition the final fix now protects.

There is a difference between a failure that has been investigated and a failure that has been made invisible. The first can strengthen confidence: the system encountered a boundary, the task located the cause, and the new check records the expected behavior. The second merely shifts uncertainty to the next person.

Negative evidence also keeps agents from optimizing for a clean story. An agent that always produces a pristine summary is difficult to trust if its process includes retries, changed assumptions, and missing external access. A better agent can say, without drama, that a proposed path was rejected because the preview exposed a mobile regression, or that a request was not executed because the approval scope was too broad.

The record should distinguish repaired failures from unresolved ones. It should never imply that a vanished error message is identical to an understood system behavior.

Review is an allocation problem

No team can inspect every artifact in full. Review is the practice of allocating limited human attention where it has the highest value.

An agent platform can support this by keeping a risk-shaped summary close to the task:

• what changed in plain terms;
• which checks ran and their result;
• which claims are directly supported;
• what remains unverified or depends on an assumption;
• which actions were blocked, approved, or intentionally skipped;
• where a reviewer can drill into the diff, logs, preview, or source data.

The task should start with the smallest useful account and allow the reviewer to expand it. A modest CSS fix should not demand a forensic investigation. A change to permissions, payments, or persistent data should make deeper scrutiny convenient rather than forcing a reviewer to hunt through a transcript.

This is why evidence belongs in the product experience. It determines whether the human can review quickly without reviewing carelessly.

Evidence must retain provenance

A screenshot without a branch or environment is weak evidence. A passing test without its command or relevant revision can be hard to reproduce. A tool call without the agent identity, policy decision, and approval state is not an adequate audit record for a consequential action.

The systems around an agent need to preserve enough provenance to answer simple questions: what produced this artifact, against which state, under whose authority, and after which change? These questions are not paperwork. They determine whether evidence can be trusted when the original task context has faded.

Provenance also makes recovery possible. If a reviewer sees that a preview was produced from an outdated branch, they can request a new one. If a task is resumed after an interruption, it can identify which checks are stale and which need to run again. Evidence that has no relationship to time or state becomes decoration.

A completion message is a product surface

The final report from an agent is often the one part of the system that a busy reviewer reads. It should therefore be treated as an interface, not as generated prose.

A good completion message is concise, specific, and inspectable. It names the change, points to the evidence, states the remaining uncertainty, and offers a clear next decision. It does not claim more than the task can support.

For AI-native software, this is a foundational design principle. People will not trust autonomous work because an agent writes more confident summaries. They will trust it when the system makes the basis of its claims clear enough to inspect.