Human approval workflows for AI agents

A human approval workflow pauses a defined AI agent action until a named person makes a decision. The action must stay held while the decision is open. Approval is not a notification and it is not a comment after the action runs.

The five parts of a useful approval

Every approval point needs five parts:

1. Trigger: the exact action or workflow step that requires a decision.
2. Approver: the person or role allowed to decide.
3. Evidence: the request, actor, scope, policy, expected effect, and relevant artifact.
4. Decision: approve or deny, with the actor and time recorded.
5. Next state: the workflow continues, takes another branch, or stops.

If one part is missing, the control becomes hard to enforce or hard to review later.

Put the hold before the action

An approval can control an outcome only when it happens before the governed action. The workflow should evaluate the policy, create a pending decision, and stop the action from executing. The action resumes only after an authorized approval.

This order also makes denial meaningful. A denied request should leave evidence of the attempted action and the policy decision, but it should not perform the action.

Give the approver enough context

The approver needs a small, complete decision packet. It should state:

• what the agent wants to do;
• which task and run caused the request;
• which tool or resource is affected;
• what policy caused the hold;
• what will happen after approval; and
• what happens after denial or timeout.

Do not make the approver reconstruct this packet from a long transcript. The decision should link back to the full work record for deeper review.

Use named authority

The person who receives the message is not always the person allowed to decide. Approval logic should check the decision-maker's authority when the decision is submitted.

Record both the human identity and the agent or workflow that requested the action. This keeps request authority separate from decision authority.

Design timeout and failure paths

A held action can wait forever unless the workflow defines what happens next. Choose an explicit timeout behavior: remain held, escalate to another named approver, or stop the run.

Do not treat silence as approval. Do not retry the governed action around the gate. A delivery failure in an approval channel should keep the action held and surface the failure on the work record.

Keep the decision with the work

Chat can carry the prompt, but the system of record should retain the governed action and decision. Record:

• the policy version;
• the request and actor;
• the approver and decision;
• the decision time;
• the state before and after the decision; and
• the artifact or receipt produced next.

This lets a reviewer answer what waited, why it waited, who decided, and what the workflow did next.

Test the gate before release

Test approval behavior with a dry run or a safe test action. Verify each branch:

1. an allowed action continues without the gate;
2. a governed action enters the held state;
3. an unauthorized person cannot approve it;
4. approval releases only the held action;
5. denial prevents the action; and
6. timeout follows the declared failure path.

The Aestus accepted-result walkthrough shows a named human step inside an illustrative workflow. For the larger operating model, read what AI agent operations is.