Agent work becomes trustworthy when people can judge the result, inspect the evidence behind it, and focus their attention where uncertainty is highest.
An agent says the work is done. That is the moment when product design matters most. The reviewer was not present for the search, the choices, or the actions in between. A polished answer may look plausible, but polish does not reveal whether the agent used the right source, misunderstood a constraint, or changed something it should only have read. The reviewer needs a practical way to decide whether the work deserves confidence. I think the goal is not to make every action pass through a person. That turns capable software into a queue of approval requests. The better goal is to make work reviewable: show enough evidence for judgment, make uncertainty visible, and preserve the ability to investigate. Correctness and inspectability are different qualities A result can be correct but hard to inspect. It can also be beautifully documented and wrong. Product teams should treat these as separate qualities. Correctness asks whether the result matches reality and the task. Inspectability asks whether another person can understand how it was produced, what it affected, and where it may fail. A reviewer often cannot establish correctness directly. They build warranted confidence from the available evidence. Consider a hypothetical agent asked to compare renewal terms across several vendor contracts. It returns a clean table. The interface should not expect the reviewer to trust its formatting. Useful evidence would connect each term to the relevant passage, identify any unreadable document, and flag where the agent interpreted ambiguous language. The output answers the question; the evidence makes it reviewable. Evidence should follow the claim Not every task needs a raw transcript. In many cases, a transcript is the least useful evidence: long, repetitive, and organized around the agent’s process rather than the reviewer’s decision. A stronger evidence model starts with what the agent is asking someone to believe. For a factual claim, show the source and relevant passage. For a changed artifact, show the difference. For an action, show what happened and within which authority. For a recommendation, state the assumptions and rejected options. For incomplete work, name the missing inputs and unresolved decisions. This creates a compact set of review questions: What changed or was concluded?What evidence supports it?Which assumptions shaped the result?What remains uncertain?What can be corrected or reversed? These questions are more useful than a generic confidence label. A high-confidence badge can compress uncertainty without explaining it. A linked source, visible change, or stated limitation gives the reviewer something to evaluate. Disclosure should be proportional to risk More visibility is not always better. If every minor task arrives with a wall of logs, people will learn to ignore the evidence. Review cost is part of the product. Exhausting verification encourages shallow acceptance. The interface should use progressive disclosure. First, show the outcome, material changes, and open questions. Next, offer supporting sources, assumptions, and action history. Keep a deeper record available for investigation, but do not make reading it the price of understanding an ordinary result. The evidence shown by default should rise with consequence, novelty, and uncertainty. A hypothetical agent that standardizes headings in an internal draft may only need a change summary and undo option. A hypothetical agent that prepares payment details should expose source fields, validation status, discrepancies, and the action that will follow. The difference is not whether a human must ceremonially approve both. It is whether the interface directs attention to work that can cause meaningful harm. Design for uncertainty, not just success Completion states often erase the most important information. “Done” can mean the task was finished, the best available attempt was made, or the agent could not continue. Those states should not look identical. A reviewable system makes uncertainty specific. It can distinguish a missing source from a conflicting source, and an interpretation from a fact. It can show which parts are well supported and which deserve attention. It can also make recovery legible: what can be edited, what can be undone, and what has already reached another system. Trust is shaped after mistakes as much as before them. If correction is easy and its consequences are clear, an imperfect result can remain useful. If the product hides its path and offers no recovery, even a small error can cast doubt on everything else. The counterargument for simpler interfaces There is a reasonable objection: most people do not want to audit software. They want the result. Evidence controls can clutter an interface and imply that the user remains responsible for checking every detail. That objection is right about the burden, but not the conclusion. The answer is to design inspectability around exceptions and decisions. Routine,...