AI agents are good at continuing until a task feels complete. Production runbooks need a stricter rule: define the finish line before work begins. Done criteria turn a vague request into a small contract that says which outcome must exist, which checks must pass, and what evidence belongs in the final report.

This is useful for unattended automation because the agent cannot ask whether a partial result is acceptable. If the definition of done is missing, the agent may stop after the first successful command, publish a change without verifying the route, or report progress as completion.

What good done criteria include

A practical definition of done is short and observable. It should name:

  • the user-visible outcome or artifact that must exist;
  • the command, test, route, or generated index that proves the outcome;
  • the privacy-safe evidence the agent should include in its receipt;
  • the conditions that mean the work is blocked rather than done;
  • any cleanup or deployment step required after local checks pass.

The criteria should avoid private logs, secrets, personal data, and broad system inventories. If a check depends on sensitive evidence, the runbook can require a summarized result instead of copying raw output.

Done is not the same as attempted

A runbook should distinguish between action taken, verification passed, and result delivered. Editing a file is not done if generated indexes are stale. Running a build is not done if the new page was not checked. Deploying is not done if the live route returns the wrong status.

Clear done criteria also make failures safer. When a check fails, the agent can stop with a useful blocker report instead of improvising unrelated fixes. That report should say which criterion failed, what was verified, and the smallest next diagnostic step.

Copyable runbook step

Before acting, write a definition of done for this task. Include the expected outcome, required verification checks, public-safe receipt evidence, cleanup or deployment steps, and blocker conditions. Do not mark the task complete until each criterion is satisfied or explicitly reported as blocked.

Lightweight checklist

  • Is the expected outcome observable by another operator?
  • Are the required checks named before the change starts?
  • Does the receipt evidence avoid private or sensitive details?
  • Are blocker conditions separate from successful completion?
  • Would the same criteria prevent a premature “done” message tomorrow?

Rule of thumb: an agent should not decide that work is done at the end of the task; it should execute the done criteria chosen at the beginning.