Human approval for AI agents: what to commission

Before connecting an agent to a tool that writes data, define three stages: preparing a proposal, authorizing a specific action and verifying execution. Reading information to draft a message needs a different scope from sending that message or changing a record. The reviewer needs to see the effect before it happens.

The n8n documentation for human review of tools describes a pause before a selected tool runs: approval allows execution with the proposed parameters, while denial cancels that action. This documented capability does not establish that your workflow is configured correctly.

Ask the supplier to identify the point where data changes and every path that reaches it. A prompt telling the agent to ask permission does not replace enforcement by the executing system. OWASP recommends limiting functionality and permissions, requiring approval for high-impact actions and validating authorization in downstream systems.

We propose the following record for agreeing delivery with operations and IT. It is a design and acceptance criterion, rather than a feature included in every platform. A reviewer should understand the proposed change without reconstructing the agent conversation.

Authorization should apply to the content that was reviewed. If the recipient, fields, attachments or batch scope change later, require a new request. The supplier should explain how the decision is bound to the version that executes and how it handles source data that changes while approval is pending.

Agree who can approve each action, how that role is checked and who covers an absence. Access to the notification channel should not automatically confer authority over every operation. The agent should not approve its own request.

Define expiry and an outcome for each request: pending, rejected, expired or canceled. For actions you have made subject to authorization, silence keeps execution paused. Any different behavior needs to be agreed as a process rule and tested before being enabled.

Include the review workload in scope: the information reviewers receive, their available time and how they correct a proposal. If each case requires manually rebuilding the evidence, you have automated preparation but still need to resolve operations.

After approval, record whether the tool ran, whether the destination confirmed the effect and what remains unresolved. A model response saying “sent” does not replace confirmation from the messaging system. Retain an output identifier when the destination provides one.

The difficult case is when the destination made the change but the connection failed before returning confirmation. Require a procedure for checking state before trying again. Agree a stable operation key where the integration supports it and explicit handling where it does not: blindly repeating a request can duplicate its effect.

Restoring files or a workflow should not be presented as automatically undoing a sent message or an external change. For each effect, ask what can be compensated, who performs that action and what cannot be undone. Recovery depends on the connected system and the contracted scope.

This matrix uses a fictional example: an agent drafts an email about an internal ticket and a person decides whether to send it. Test data and recipients need authorization, with outputs isolated. This is neither a client case nor an implementation already tested.

Set the expected result before each test. Keep the workflow version, input, decision, tool attempt and observed destination state. We propose blocking write access if an action executes despite denial, without authorization or with content different from the reviewed request. After correction, repeat the affected tests.

If your platform already supports reviewing the action and meets the agreed test cases, the work may be configuration and testing. If destination connectivity, binding approval to the operation or result verification is missing, you need an integration. Reserve custom development for rules the selected platform cannot cover; replacing the entire tool is not necessarily required.

Ask for an action and permission matrix, the implemented workflow, approval and expiry rules, reproducible tests, records with defined access and retention, and an operating guide for the review queue. The proposal should identify which system blocks unauthorized writes and who handles uncertain outcomes.

Separate paid discovery from implementation when information needed to scope delivery is missing. Specify systems, included actions, environment, owners, acceptance criteria and exclusions. Maintenance, on-call coverage and additional integrations need their own terms; project approval does not include them automatically.

Duotach develops AI agents connected to business processes and systems. You can enquire about one process with a bounded write action, an accountable reviewer and agreed acceptance tests. Discovery and implementation are contracted work, scoped to the available APIs and business rules.

To start the conversation, describe the action you want to automate, its destination system and who needs to approve it. Do not send credentials or sensitive information through the form. If you are still choosing who will build it, our Claude agent supplier guide covers that broader decision.