An agent can only be given consequential work if somebody can eventually decide whether to accept what it did. That makes verification more than a safety feature — it makes verification an economic constraint on delegation.
If an agent performs a week of work but understanding the result requires another week from the person who delegated it, very little leverage has been created. If the review is skipped because it is too expensive, the problem has not disappeared: the organization has simply accepted work it does not understand. As agents become capable of operating for longer periods, this constraint becomes harder to ignore.
Output is not enough
The simplest agent interface returns an answer or an artifact. For short work, that may be sufficient. For long work, output-only delivery forces the reviewer to reconstruct the path that produced the result. Why was this source preferred? Why was this implementation chosen? Was another approach attempted? Did a test fail? Did the system encounter ambiguity? Did a person correct something midway through? If the result contains none of that structure, checking it begins to resemble doing the work again.
Logs are not enough either
The obvious response is to preserve everything — every tool call, every browser action, every intermediate message, every file access, every command. That creates observability. It does not necessarily create understanding. A transcript of activity forces the reviewer to perform another task: determine which events mattered. For sufficiently long execution, complete history becomes its own form of information loss. Nothing is missing; significance is buried. We think the useful review surface has to be smaller than the execution history.
The decision as a unit of review
Consider two failures. In the first, an agent chooses the correct implementation and mistypes a command. The error is local, and it can usually be detected and repaired locally. In the second, the agent misunderstands an important constraint near the beginning of the task. Every subsequent action may be executed correctly — and the entire task can still be wrong. The expensive failures often begin at decisions. That suggests a reviewer should not primarily inspect actions; they should inspect the places where the work could have gone meaningfully another way.
- What was being decided, and what was chosen
- What evidence supported that choice
- Which alternatives mattered, and what uncertainty remained
- Whether a person later corrected it
- What downstream work depended on it
The execution history still matters for debugging and forensics. But the decision record may be the more useful interface for review.
Dead ends matter
Systems often preserve successful paths and discard unsuccessful ones. That can make the final result cleaner. It can also remove exactly the information needed to understand the work. A failed approach answers a question: it tells the reviewer what was attempted, it explains why the current path exists, and it prevents the same failure from being rediscovered after a restart. Not every failed action deserves permanent attention. Meaningful dead ends do.
Human correction matters more
A correction is unusually valuable information: it identifies a gap between what the system inferred and what the person responsible for the outcome actually intended. A long-running task should not treat that correction as another transient chat message. It should change the state of the work. Future decisions should be able to depend on it; if the task resumes later, the correction should survive; if work is delegated elsewhere, the relevant correction should travel with it. The person should not have to teach the same lesson repeatedly inside one task.
The compression problem
This leads to the question we care about most: how small can the review surface become without becoming misleading? A useful system should compress execution. A dangerous system can compress away evidence of failure — and those outcomes can look similar in a polished interface. The problem is therefore not simply summarization. It is deciding what information must survive compression because omitting it would materially change a reviewer's understanding of the work.
Our current position is that material decisions, their evidence, consequential dead ends, human corrections, and unresolved uncertainty are strong candidates for that boundary. We do not yet have a measured result demonstrating the right representation or compression ratio. That result has to be earned. Until then, this is a design hypothesis.
Why this matters
Agent capability will continue to make longer delegation possible. That also increases the amount of execution a human cannot realistically watch. If autonomous execution grows faster than our ability to review it, the practical limit on delegation will not be what an agent can do — it will be what a person can responsibly accept. The work of making an agent useful therefore does not end when the agent produces the output. It ends when the work can be understood.