Source: https://jtpck.com/blog/human-approval-in-ai-workflows

# Where Human Approval Belongs in an AI Workflow

Before AI sends emails or changes business records, define what it can do alone, what needs review, and how approval stays tied to the actual action.

By JTPCK Team · Oct 25, 2026

An AI tool that drafts a customer reply and one that sends it have different responsibilities. The draft gives a person something to review. Sending commits the business to a message, a recipient, and any attachments included.

That distinction matters more than whether a demonstration looks impressive. Before connecting AI to a working inbox or business system, we recommend writing down where preparation ends and authorized action begins.

Our [AI integrations](/services/ai-integrations) work connects models to existing software. A useful integration needs an action policy as much as it needs a good prompt.

## Separate reading, drafting, and acting

List the individual steps instead of approving a broad instruction such as handling customer requests. Reading a request, finding an account, drafting a reply, changing a delivery address, and sending a message are separate operations.

Give each step only the access it needs. A drafting assistant does not need permission to delete messages. A tool that looks up an order does not necessarily need permission to change it. Narrow tools and limited credentials reduce the consequences of an incorrect model decision.

For a hypothetical equipment supplier, an initial workflow might prepare a reply about an order without changing that order. A staff member checks the account and proposed response in the software they already use. Automating preparation can be worthwhile even when execution stays manual.

## Reserve approval for meaningful decisions

Requiring a click for every small step does not automatically produce good oversight. We recommend identifying decisions where an error could disclose information, create a commitment, or make a difficult-to-reverse change.

A routine internal classification may be eligible for automation under an agreed rule. Sending a customer-specific attachment or changing a delivery destination deserves a different policy. The right boundary depends on the actual data, recipients, and consequences, not just the tool's name.

Decide who can approve each kind of action. Being able to use the assistant should not automatically grant authority to approve every change it proposes. If nobody with the required authority is available, the workflow should remain pending rather than treating silence as consent.

## Show exactly what will happen

An approval screen should make the decision understandable without requiring the reviewer to reconstruct the conversation. For an outgoing message, show the recipient, full message, and attachments. For a record update, show the specific record and the old and proposed values.

Keep the evidence close to the proposal. In our hypothetical supplier workflow, that could mean showing the customer's request beside the proposed address change. The reviewer needs to distinguish what the customer supplied from what the model inferred.

Approval should apply to that version of that action. If the recipient, attachment, or proposed values change afterward, require another review. A general approval earlier in a conversation is not a substitute for checking the operation now awaiting execution.

## Enforce the boundary outside the model

A prompt telling the assistant to ask first is useful guidance, but it should not be the only control. The component that performs the action should independently check the user's authority and the approval for the exact proposed operation.

Treat incoming documents and messages as material to process, not permission to expand the workflow. A sentence inside an attachment should not grant the assistant new tools or authority to send data elsewhere.

This is also a reason to keep the first version small. One document source, one proposed action, and a clear review step are easier to inspect than a workflow with broad access to every connected system.

## Plan for retries and uncertain outcomes

A connection can fail after the destination has accepted an action. Retrying without checking can create a duplicate record or repeat a message. Approval and successful execution therefore need separate status records.

Some APIs provide idempotency keys, allowing repeated requests for the same operation to be recognized rather than performed again. Their scope and retention rules vary, so the integration needs to follow the destination's documented behavior.

Where that protection is unavailable, plan how to reconcile an uncertain result before another attempt. A timeout should not automatically become a second send. Give staff a clear pending state and a way to investigate.

## Test the review process, not just the draft

Before rollout, test a changed recipient after approval, a rejected proposal, an unavailable approver, and an interrupted request. Include an incoming document that contains instructions unrelated to the approved task. These checks help establish whether the boundaries hold when the happy path breaks.

Record enough to understand what was proposed, approved, attempted, and completed, while limiting sensitive information in logs. Also define how staff can pause the workflow and correct mistakes that cannot simply be undone.

Custom AI is not always necessary. An existing application's approval queue or a conventional rule may handle the job more simply. If the hard part is interpreting variable requests and preparing useful work for review, [talk with us about AI consulting](/ai-consulting). Start with the action you want help preparing and the decision you want a person to retain.