An agent can prepare a change without being allowed to make it. That distinction is the simplest way to get useful automation into an enterprise workflow while keeping a person accountable for consequential actions.
Consider a supplier onboarding assistant. It reads a request, checks whether mandatory fields are present, compares the supplier against an approved registry, and prepares an ERP record. It must not create the supplier or release a payment on its own. The approval step belongs between prepare and execute, not as a polite question the model asks after it has already called the write API.
Split the workflow into explicit states
A practical state machine is received → validated → proposed → awaiting_review → approved/rejected → executed → reconciled. Persist the proposal and its source references before asking for approval. An approver should see the original request, the exact fields to be written, the evidence used, uncertainty, and any policy warnings. The approval decision should refer to a versioned proposal ID, so an edited proposal cannot inherit an earlier approval.
The write operation should be a separate service endpoint. Give the agent read access and permission to create a proposal, while the execution service accepts only a valid approval token from the workflow system. A prompt such as “always ask before writing” is helpful guidance, but it is not an access control.
Make approval specific
“Looks good” is too vague. Ask the reviewer to approve the exact action: create supplier S-1042 with the displayed bank and tax details, or send the displayed reply to a named recipient. Show a diff against the current record. Let the reviewer edit, reject or escalate. For financial, identity, personal-data or regulated decisions, the appropriate reviewer and evidence may differ; encode those rules outside the model.
A minimal approval record contains the proposal ID and version, actor identity, action type, target system, payload hash, reviewer identity, decision, timestamp, reason, and execution result. Set an expiry and do not reuse the approval for a later attempt with a changed payload.
Handle failures after the click
Approval is not proof that the write succeeded. The executor needs an idempotency key so a retry does not create two suppliers. Record the target system's response and reconcile it with the intended change. If execution fails, leave the item in an exception queue rather than asking the model to invent a recovery path. Test the rejected, expired, modified, duplicate and unavailable-system paths before a pilot.
Microsoft's Agent Framework documentation describes a related pattern: an approval-required tool pauses the workflow and emits a request that an external reviewer can approve or reject. The exact SDK is optional; the durable pause and the separate authorisation boundary are the important parts.
Start small: choose one low-volume workflow, one write action and one reviewer group. Measure time from proposal to decision, reviewer corrections, false positives, and failed executions. Those measures tell you whether the agent reduced work or merely moved it to the approval queue.
I work at OneBonsAI Gulf. For teams planning a bounded agent with human oversight, see our agentic AI implementation service.
Further reading: Microsoft Agent Framework human-in-the-loop workflows.
Top comments (0)