An agent proposes publishing a help article, then asks a reviewer to “approve this run.” The reviewer needs to know which revision will go live and where. If the system only records a yes or no against the run, it can lose that distinction when someone edits the article while the request is pending. AI agent human approval works best when the interface shows one concrete action and the workflow binds the decision to the exact version reviewed.
Place the checkpoint before the action
Let the agent gather evidence and prepare a proposal first. Pause when the workflow is ready to create a consequence the reviewer needs to assess. In a publishing flow, that usually means showing the finished draft, its target site and its audience just before the publish step. A checkpoint earlier in the run can still help with editorial direction, but it answers a different question.
Separate questions that supply missing information from decisions that grant permission to act. Google’s Workflow Builder documents these as distinct step types. Microsoft’s Agent Framework illustrates how a workflow can send an external request and continue after it receives the matching response. Both provide mechanisms for waiting. The application team still decides what the reviewer must see and what a decision authorizes. Google Cloud’s human review steps and Microsoft’s workflow request and response documentation explain these patterns.
Show the action in terms the reviewer can check
Give the request a title that states the action, such as “Publish revision 12 to the public help center.” Include the exact target, what will change, the relevant evidence, the deadline and who can make the decision. For a change to an existing article, link to the draft and show the edited paragraphs first. A reviewer who only has a minute should be able to tell what clicking approve will do.
- Action and destination. Name the operation and show the site, workspace or record that will receive the change.
- Version and evidence. Identify the revision and link to the proposal. Show a before-and-after view if the reviewer needs to evaluate edits.
- Decision and deadline. State the expiry and label the buttons with their consequences. Include a way to request changes or decline.
- Open issues. Surface any unresolved dependency that could affect the decision. For example, show that a localized page will be published separately if the proposed action only covers the English revision.
Put the decision details in the review screen itself. A notification can point to that screen without duplicating an entire draft. Use text labels for each status so reviewers can distinguish a pending request from a completed action even when the status colors look similar.
Bind the decision to the proposal
Store a stable request ID, the proposed operation, the target, the revision and the expiry. Record the reviewer’s identity, decision and time against that request. When execution resumes, check that the proposal still matches those details and that the authorization remains valid. Do this at the point of execution, since a draft may change between receiving the approval and processing the job.
Suppose someone approves revision 12 for the public English help center. If revision 13 replaces the draft while the job waits, show the new changes and ask for a fresh decision. The same applies if the destination changes from the English help center to a site with a different audience. Define which fields are material to the approval. An internal reminder label can usually change without affecting the action, while a different document revision or destination changes what the reviewer is authorizing.
Handle retries, expiry and rejection explicitly
Keep review status separate from execution status. “Approved” means a reviewer granted permission. “Published” means the destination accepted the change. The workflow can display an execution failure even when the approval record is valid. If the publishing response is lost, reconcile the action with the destination before retrying. Where the destination supports idempotency keys, reuse the same key for retries of the same approved operation so a delayed response does not create a second publication.
On expiry, leave the action pending or mark the request expired according to the workflow’s rules, and require a new valid decision before execution. If the reviewer asks for edits, return the proposal to the author with the review notes and create a new request when it is ready. If the reviewer rejects it, record the decision and end that execution path. Distinct outcomes help both reviewers and support teams explain what happened.
Test whether the checkpoint works under pressure
Give reviewers realistic requests and ask them to describe the action and destination before they decide. Try a changed revision, two reviewers acting at once, an expired request and a duplicate response. Check what the interface shows when a publish attempt fails after approval. For reviewers using the workflow on a phone, check that the action, destination and expiry are visible without relying on a wide comparison table.
If the agent prepares the proposal as structured data, define explicit fields for the destination and version so the interface can display them consistently. A schema can enforce that the fields exist. The application still needs to verify that their values describe the actual operation. See how Structured Outputs differs from JSON mode.
Start with one consequential action. Make it possible to trace the proposal, the reviewer’s decision and the result using the same request record. Expand to other actions once reviewers can reliably tell what they are approving and the workflow handles changes after review.
