Where to put human approval in an agent workflow.

An agent can gather records, compare alternatives, prepare a document, or propose a change. These activities can be valuable before the organization is ready to let it execute the final action. The design question is where preparation becomes a decision with consequences.

Take a commercial exception as an example. The agent may collect the customer context and explain why a discount was requested. A person may need to approve the discount. Another step may issue the resulting quote. Treating all three as one instruction obscures the authority required at each point and makes it harder to understand what a reviewer actually accepted.

A reviewer needs the target record, the proposed change, the supporting evidence, and the relevant policy. An approval should identify the version or state that was reviewed, especially when amounts, recipients, or scope can change while the request waits.

Decide what invalidates the decision. If the commercial amount changes after review, does the process return for approval? If the recipient changes, does the original authorization still apply? These are business rules to configure and test, not details to leave to the agent’s interpretation. A clear rule prevents an old decision from silently authorizing a different action.

Access to submit a request is different from access to approve it. Identify the role or person authorized for the decision and how substitutions or escalations should work. Where independent review matters, test that the requester cannot complete the approval through another screen or client.

ERP.AI workflows support human approval gates alongside conditions, AI Agent nodes, and actions. The gate belongs within the wider permission model: the caller still needs appropriate access, and the owning service remains responsible for enforcing the operation. An approval should add a business decision, not erase the surrounding access boundary.

After approval, the executing step should use the reviewed target and values. Avoid re-reading a loosely defined set of records and assuming it is still the same proposal. If the task deliberately uses current data, make that rule explicit and decide which changes require another decision.

External side effects deserve particular care. Sending a message, issuing a payment instruction, or writing to another system may not be reversed by restoring an internal record. Define a stable reference, a repetition policy, and the checks needed before retrying. The receiving system’s result is part of the evidence that the action completed.

Real approvals are delayed, rejected, withdrawn, or superseded. Give each state a visible owner and a clear next step. A rejection should preserve the reason and the proposal it applies to. A new proposal should be distinguishable from the one already considered.

Test a changed record while approval is pending, a reviewer without authority, an expired credential at execution, and a retry after a partial external result. These cases reveal whether the workflow has a coherent decision model or only an Approve button on the happy path.

The operator should be able to follow the request, the evidence used, the reviewer’s decision, the attempted action, and the result. Workflow state, node output, audit events, and business records each explain part of that chain. Their available detail and retention depend on the relevant service and configuration.

Begin with one consequential action and make its approval boundary precise. Once the team can explain and test that boundary, it becomes easier to expand agent assistance without losing accountability. The goal is useful work with clear authority, not a review prompt attached to every low-risk step.