Disclosure: This article was generated with AI and reviewed against the source transcript.
A team asks an AI assistant to improve an onboarding guide. The assistant returns a fluent document, announces completion, and supplies no indication that the instructions work. The team now has a new review task: discovering what changed and whether a new user could follow it.
The delegation was missing a description of the evidence that should accompany the result.
Nick Saraev’s video about managing AI work argues for giving agents goals, relevant context, examples, and repeated feedback. It also includes predictions about model progress and anecdotes about unusually long autonomous sessions. Those accounts do not establish the reliability or economics of a particular workflow.
My practical extension is to define the completion evidence before starting the task. That makes the handoff reviewable without pretending the agent’s own confidence is a test result.
Start with the decision the result must support
For the hypothetical onboarding guide, the team wants to know whether a new contributor can complete the approved setup process. Better prose is useful only insofar as it supports that job.
The brief should name the intended reader, the supported environment, the allowed scope of edits, and the reference material that remains authoritative. It should also say what to do when the required environment is unavailable.
A missing prerequisite should produce a clear report of what could and could not be checked. It should not produce an invented successful walkthrough or a silent change to the supported setup.
This distinction lets useful editing continue while preserving uncertainty about execution. A document can be improved even when a particular validation step remains blocked.
Request a small evidence package
The completed handoff could contain the revised guide, a concise description of material changes, the checks actually performed, and unresolved limitations. Each check should identify the relevant version or environment.
For example, correcting a broken internal link and successfully opening that link support one claim. Following the complete setup in an approved clean environment supports a broader claim. Reading through the instructions supports a different, more limited judgment.
Keep these observations separate. A long list of activities should not make a limited review appear more comprehensive than it was.
The evidence package needs to be proportionate. Requiring an elaborate report for a spelling correction would add work without helping the decision. Request the few observations that distinguish a usable result from a plausible-looking one.
Use an example to expose judgment
A sample of acceptable work can clarify tone and structure. It can also demonstrate how the team handles uncertainty.
For this guide, the example might show a short prerequisite section, an exact command supported by the repository, and a clearly labeled explanation of what successful output means. It should use material the team is permitted to supply.
Ask the assistant to explain where the current task differs from that example. A useful example communicates standards; it should not encourage reproducing irrelevant details or copying another author’s expression.
Then review representative outputs against the same standards. Preserve the failure and the correction together, so that future instructions explain the underlying issue rather than accumulating unexplained prohibitions.
Evaluate the whole cost of the handoff
Saraev discusses the importance of watching cost as AI use expands. For an individual workflow, the relevant accounting should include the operator’s review and repair work alongside whatever resources the execution uses.
Track the time spent clarifying the brief, inspecting the result, and fixing omissions. Record whether the work required another person to reconstruct the agent’s reasoning from logs. Those observations help distinguish a faster draft from a better handoff.
Anthropic’s guidance on effective agents recommends starting simply and adding complexity when simpler approaches fall short. Applied here, that suggests testing a bounded delegation before turning it into a persistent process.
The proposed onboarding example has not been benchmarked. It is a way to make that benchmark possible: keep the task, scope, and evidence requirements stable enough to compare actual outcomes.
Before the next delegation, write one additional sentence: completion will be supported by these specific observations. If the team cannot finish that sentence, the task still needs definition.