Set approval boundaries around the specific effect an agent can produce. Allow routine actions only within an agreed scope, pause consequential actions before they happen, and keep prohibited actions unavailable. The reviewer must be able to inspect the proposed change, authorize it and refuse it. If the proposal or a material condition changes, the earlier decision must not silently authorize the new action.
For an operations leader, this means deciding more precisely than “a person checks important things.” One agent might inspect stock, prepare a delivery proposal and release goods. Those steps need different authority, even when they belong to the same customer request.
Separate permission from approval
A connected account determines what a system can reach. A task instruction describes what someone wants. Approval authorizes a defined proposed action. None should be treated as an unlimited substitute for the others.
An employee asking an agent to resolve a delivery complaint has not necessarily authorized it to send replacement stock to any address, waive charges or change the customer's account. Start with the organization's approved tools, information and tasks, then agree the narrower actions this workflow may perform.
The technical operator needs to demonstrate that the running system enforces those limits. A prompt saying “ask first” is not enough if another available tool can produce the same restricted effect. Keep unneeded access out of the workflow, and check the actual identity and permissions used when an action runs. The agent ownership guide explains why the maker's account and a connected service may have different access.
Decide what each action can change
Suppose Claire Bennett coordinates dispatch at a furniture wholesaler. A retailer reports that two dining chairs arrived damaged. An agent can gather the order details and prepare a replacement delivery. Claire and the warehouse supervisor must decide where preparation ends and permission to release goods begins.
OpenAI's practical guide to building agents recommends assessing tools through factors including read or write access, reversibility, account permissions and financial impact. Translate those factors into questions about the actual work:
- Consequence. Could the action release goods, expose information, change access or create an external commitment?
- Reversibility. Can the effect be undone completely, and who would do that? Recalling a delivery is different from deleting an unsent proposal.
- Uncertainty. Are the order, item, destination and supporting evidence clear enough to justify this action?
- Authority. Does the proposed action fit the company's rules and the person authorized to decide it?
The same tool can have different consequences depending on its arguments. Updating an internal dispatch note differs from changing a delivery address that another system immediately uses.
| Proposed action | Possible operating boundary | What the team must establish |
|---|---|---|
Read the original order and available stock | Automatic within permitted access | Correct customer record and allowed information; no disclosure to another service. |
Prepare an internal replacement proposal | Automatic preparation, with no release | Saving the proposal does not reserve, dispatch or notify anyone. |
Release two specified replacement chairs | Approval before release | Authorized reviewer sees the items, quantity, destination and relevant charges. |
Substitute a different model or change the destination | Hold for a new decision | The changed effect is assessed before goods move. |
Remove delivery-history records | Unavailable in this workflow | Record maintenance follows its own authorized process. |
Check these boundaries in the team's actual dispatch system. Reading confidential records may itself be restricted. An apparently reversible update may trigger a downstream notification or shipment. Ask the operator to trace that effect before granting automatic execution.
Let the reviewer inspect the actual dispatch
“Approve the replacement?” is too vague. Claire needs the original order, damage report and current stock beside a proposal identifying the two chairs and the retailer's delivery address. Any charge or unresolved discrepancy must be visible before she decides.
LangChain's human-in-the-loop documentation illustrates the implementation distinction: execution can pause before a tool call, and the reviewer can approve its original arguments, edit them or reject it. That mechanism does not decide who has authority in your company or whether the proposal is sound.
Agree what the reviewer must be able to inspect:
- The effect. Which order, items and destination will change, and what happens next?
- The evidence. Which customer request and source records support that change?
- The exceptions. What is missing, conflicting or outside the normal replacement rule?
- The decision. Can this person approve, reject or return the proposal for correction under the company's authority rules?
The human-review guide covers checking an AI-generated result against its originals. Here, the additional requirement is that the checked proposal is the one the system will execute. Keep the decision and resulting dispatch reference connected, using existing access and retention rules rather than copying unnecessary customer information into another log.
Recheck changes before releasing goods
Suppose the retailer requests a different destination while Claire's proposal waits. An approval for two chairs to the original address should not release them to the new one. The workflow needs to stop, show the changed destination and obtain the decision required for that revised action.
A September 2026 security preprint by Adithyan Arun Kumar studied cases where an approval was applied to a materially different operation. Its controlled tests used selected product paths and configurations, including a negative control. They do not establish how common the problem is. The practical lesson is to test the link between what the person approved and what actually executes.
Ask the operator to demonstrate that a changed item, quantity or destination cannot inherit approval unnoticed. The same applies when relevant permission is revoked or the decision expires. Define validity around the task: a stock-dependent dispatch may need a fresh check sooner than an internal note. There is no universal approval lifetime.
Also distinguish a failed action from an unknown result. If the dispatch system times out, the goods may already have been released. Check the authoritative dispatch record before retrying. The technical team should provide a supported way to prevent a repeated request from creating a second release; a second click on Approve is not that mechanism.
Make waiting work operationally manageable
An approval rule needs an available reviewer, enough evidence and time for the decision. Otherwise, the agent can produce proposals faster than the team can safely finish them.
In an August 2026 Reddit reply about an approval system, a Reddit user described outbound drafts sitting for days while waiting specifically for them. Increasing the drafting allowance did not clear the backlog. The user explicitly said they had no clear incident to report. It is an unverified account of a queue problem, not evidence of a general failure rate or a reason to remove every approval.
For Claire's team, agree who can cover her absence and what happens near the dispatch cutoff. If no authorized reviewer is available, the replacement stays unreleased and a person handles the customer update through the existing process. A timeout must not become permission by default.
Watch the age of pending proposals, expired items, corrections and unresolved outcomes alongside completed work. If reviews accumulate, investigate the cause. The team may need a narrower task, clearer evidence, reviewer cover or less incoming work. A queue count alone cannot tell you that the agent deserves more authority.
Rehearse the boundary before expanding it
Use a safe test environment or a supported dry run with the authorized operator. Start with one normal replacement and test the exceptions that could change its effect:
- Reject the release. Confirm that no goods move and the requester can see what needs attention.
- Change the destination after review. Confirm that the old approval cannot release the revised delivery.
- Leave the reviewer unavailable. Check the hold, expiry and handoff rather than assuming someone will notice.
- Make the result uncertain. Demonstrate how an operator finds an existing dispatch before retrying.
Include an ordinary permitted case too. A system that blocks everything has not demonstrated a useful workflow. Record what the test actually proves and leave unsupported actions unavailable.
The broader tools-and-workflows guide helps decide whether an agent is needed at all. For an existing agent, expand only a defined scope supported by the trial and the company's authority rules. Several clean proposals do not erase the consequences of releasing the wrong goods.
Questions about agent action approvals
Should every agent tool call need human approval?
No. A team can allow defined routine actions within permitted access while reserving consequential actions for review. Classify the effect, including downstream changes and information exposure, rather than approving or rejecting an entire agent. Use the dispatch comparison to discuss a specific workflow with its technical owner.
Can a confident agent approve its own action?
A model's confidence does not establish permission or replace an approval required by company policy. The agent may propose an action and explain its evidence, but the system must enforce the applicable authority rules. Keep prohibited actions unavailable and have an authorized operator demonstrate the permission and approval boundary.
What if the proposal changes after approval?
A material change needs the decision required for the revised action before execution. Changing a delivery destination, quantity or item can alter what the reviewer authorized. Define which conditions matter, how long approval remains valid and how the system checks them. Rehearse a changed-destination case before relying on the workflow.
What should happen when nobody answers an approval request?
Keep the approval-gated action on hold. Use a named authorized deputy, an expiry rule and an existing manual fallback where appropriate. Do not turn silence or a deadline into permission. Check pending-item age and reviewer coverage before increasing the work entering the queue.
Does approval mean the action succeeded?
No. Approval authorizes a proposal; execution can still fail or return an uncertain result. Check the destination system's authoritative record and preserve the resulting reference. Before retrying a release, establish whether it already happened and use the supported protection against duplicate execution described in the changed-condition checks.
