Decide which actions need a person
Start with the consequences of an action. Reading an authorised record, preparing a draft and sending that draft to a customer are different operations. Write down the allowed behaviour for each tool rather than relying on a general instruction to be careful.
A useful policy can permit low-risk preparation automatically, require approval for specified external commitments, and prohibit actions outside the workflow’s remit. For example, a service assistant might draft responses but have no facility to change bank details. Human approval should not turn a prohibited action into an available one.
Agree these boundaries with the operational owner. Consider reversibility, who receives information, the scale of an error and existing company authority limits. There is no universal monetary threshold or list of actions that suits every UK business.
Illustrative example: a service team prepares a customer offer
Imagine a UK maintenance company using AI to prepare a response to a customer complaint. The assistant assembles a draft email and proposes a £75 service credit. This is an illustrative workflow, not a Fewzen client story, a recommended threshold or evidence of savings.
The reviewer sees the customer account, complaint reference, exact message, proposed credit and supporting service record. They can accept the proposal, return it for changes or reject it. Approval to send the message does not automatically authorise issuing the credit: the workflow must identify both actions and the authority each requires.
If the customer has already received a credit by the time someone reviews the request, the system should stop and refresh the proposal. An approval queue needs current business context as well as a well-written draft.
Show the action that will actually happen
OWASP’s transaction-authorisation guidance says users should be able to identify and acknowledge the significant transaction details. It also recommends a final authorisation check tied to execution. Applied to an AI workflow, the review should expose the actual destination, important values and scope of the proposed change.
Prefer a concrete summary such as “Send this message to this customer” to “Allow the agent to continue”. For a record update, show the old and new values. For several actions, make the selection explicit rather than hiding an entire plan behind one button.
- Show the source evidence needed to make the decision, with access restricted to the right reviewers.
- Make edits visible before submission, including changed recipients and attachments.
- Give rejection a clear meaning: this proposed action will not execute.
Store approval as workflow state
A chat message saying “looks good” is a poor operational record if nobody can tell which draft it refers to. As a design recommendation, store a proposal identifier and version, reviewer identity, decision time and the exact action approved. Keep the pending proposal separate from the executed result.
Check the reviewer’s current authority on the server. Decide how long a proposal remains valid and what events cancel it. If significant details change, create a new version for review rather than applying an old decision to a different action.
Use explicit states such as awaiting review, rejected, expired, approved, executing and completed. A closed browser should not erase a pending decision. A restarted worker should not assume that every saved proposal was approved. Restrict access to these records and avoid retaining unnecessary customer content.
Use framework support, then check its boundary
LangChain documents human-in-the-loop middleware that can pause tool calls, save state through LangGraph persistence, and resume after approval, editing or rejection. That supplies useful orchestration machinery. Your application still needs the business policy, reviewer identity and review interface.
Vercel’s current AI SDK documentation describes tool-execution approval for locally executed tools. It explicitly says that provider-executed tools do not use this approval setting. Check where each action runs before assuming one configuration protects every tool.
These are documented implementation options checked on 1 November 2026, not a comparison of their reliability. Check your installed version’s documentation before implementing an API example. An existing workflow platform may already provide suitable approvals; adding an agent framework is not a prerequisite.
Plan for waiting, rejection and uncertain outcomes
Give the queue an owner and a backup. Set an escalation route for overdue requests, but do not interpret silence as approval. Show staff whether work is waiting for review, blocked by changed information or failing in the destination system.
After approval, recheck the relevant record before acting. If execution times out, establish whether the destination accepted the operation before retrying. Approval establishes permission; it does not prevent duplicate actions or confirm success. Keep the execution receipt linked to the proposal.
Prevent an agent from bypassing a rejection by submitting the same action under another tool or slightly different wording. Allow a genuinely revised proposal when the reviewer requested changes, with a visible connection to the earlier decision.
Pilot the review process as well as the AI
Try one workflow with representative cases: a correct proposal, a changed recipient, an expired request, a reviewer without permission, two simultaneous decisions and a timeout after the destination has accepted the action. Verify the resulting records, not only the approval screen.
Track review time, queue age, corrections, rejections and actions executed incorrectly. Too many low-value requests can encourage hurried decisions; too few checks can let consequential mistakes through. Adjust the policy using observed failures and the team’s capacity.
Your next step is to list the tools in one proposed automation and mark each as automatic, approval-required or unavailable. Then sketch the review screen for one consequential action. If the reviewer cannot explain exactly what will happen, the proposal is not ready to execute.