Your AI Agent Is Not Done When It Says “Done”

Output is not outcome

In a chat interface, the presence of an answer feels like progress. Business systems work differently. An email is complete when the approved message appears in Sent. An application is complete when the receiving system issues a receipt. A record update is complete when the intended record contains the intended value.

Without that distinction, agents report intermediate events as outcomes: a button was clicked, a request was queued, or a form appeared to submit. The operator moves on. By the time someone notices the missing result, the evidence needed to diagnose it may be gone.

The five-part definition of done

A useful definition of done says more than “the action succeeded.” It identifies the final business state, how that state will be verified, and what the agent must do when verification is impossible.

Approval and verification are different controls

Approval answers one question: may the system perform this exact action? Verification answers another: did the approved action produce the intended result? Combining them creates a blind spot.

For external sends, publication, payment, deletion, or any other hard-to-reverse action, freeze the target and payload at approval time. After execution, read the destination again and retain the resulting URL, receipt ID, or final value. If the payload changes, the previous approval should not silently cover the new version.

Design the stopping behavior

A reliable agent is not merely good at succeeding. It is good at stopping. When the destination is ambiguous, access is missing, or the target cannot be uniquely identified, the agent should preserve what it knows and hand the unresolved decision to a person.

At minimum, separate completed, partial, blocked, and failed. Completed means the final state and evidence are present. Partial means a bounded subset finished. Blocked means a missing decision, permission, or input prevents safe progress. Failed means the execution itself failed. For sends and publication, never retry an ambiguous result until the destination has been checked for a possible first submission.

Examples by workflow

The fields stay consistent, but the evidence changes with the workflow.

• Email: the approved recipient, subject, body, and attachments appear in Sent, with a provider message ID.
• Content publishing: the approved title, body, and media are visible at a canonical public URL.
• Customer data: the intended customer is uniquely identified, the new value is present, and the change is auditable.
• Booking or application: the provider issues an ID and the date, subject, and requester match.
• Internal reporting: the period and data sources are explicit, and missing fields are reported rather than guessed.

A production checklist

Start with one workflow and document how a careful human currently knows it is finished. The screens, IDs, notifications, and exception rules people check without thinking are the verification path your agent will need.

• Can the destination system and target record be identified uniquely?
• Which fields must be frozen before approval?
• Which URL, ID, screen, or value will be read back after execution?
• Are partial, blocked, and failed conditions written down?
• Will an ambiguous result stop automatic retries?
• Does the handoff include what was attempted and what remains?
• Can an operator later see who did what and when?

Let the definition of done set the automation boundary

If a team cannot describe how a workflow ends, that workflow may not be ready for autonomous execution. Raising model capability will not fix a process whose target changes by operator, whose records are ambiguous, or whose failures have no owner.

Begin with a narrow workflow whose result can be checked objectively. Define the agent’s scope, the human approval point, and the evidence to read back. AIRAX designs production AI operations around those boundaries: authority, approval, receipts, exception handling, and a verified final state.