openwiki

Guide · Human in the loop

Build a human-in-the-loop Agent approval workflow

A human-in-the-loop system is not created by showing a plan in a browser. The decision must be tied to a specific candidate, returned as structured state, and enforced before the Agent performs the governed action.

Updated August 3, 2026Practical guide

Define the decision boundary

  1. What exact action is blocked?
  2. Which candidate revision is being reviewed?
  3. Who receives the review capability?
  4. What evidence and rollback information must be visible?
  5. How long can the workflow wait?

Publish and wait

ow a2ui draft check ./plan
ow a2ui draft build ./plan
ow a2ui digest ./plan/document.mdw
ow publish ./plan/document.mdw --review --no-open --timeout 900

Map every result to behavior

  1. Approved: execute only the reviewed authority.
  2. Changes requested: revise and publish a new candidate.
  3. Rejected: stop the proposed path.
  4. Timeout: report no decision and remain blocked.
  5. Error: preserve the current formal state and remain blocked.

Prevent approval drift

Record the immutable approved revision with the execution evidence. A later materially changed plan must not inherit the old decision merely because it uses the same canonical URL.

FAQ

Frequently asked questions

Is a visible approval button enough for human-in-the-loop control?

No. The decision must be bound to the exact candidate and enforced by the Agent workflow before action continues.

What should the Agent do when the reviewer does not respond?

Treat timeout as no approval, report it, and remain blocked or resume waiting according to the authorized workflow.

Use the real workflow

Publish what your agent creates.

Give every report, document, or plan its own reader-ready page. Comments, review decisions, and formal revisions can flow back from there.

Choose HostedSign in