An AI agent can be authorized to process customer refunds, access an order-management system and communicate with customers. But should that authorization also allow it to issue every refund, regardless of amount, circumstances or recipient?
Not necessarily.
The important distinction is between approving an agent's task and approving the specific action it is about to execute. An organization might authorize an agent to handle refund requests without authorizing it to transfer money independently. Human-in-the-loop (HITL) approval is designed to preserve that distinction by pausing an agent workflow until a person reviews a proposed action.
However, adding an approval button does not automatically make the workflow safe. The system must ensure that the action presented to the reviewer is the same action that executes after approval.
1. What does human-in-the-loop approval actually control?
Consider a customer-service agent handling a refund.The agent retrieves the order, checks the refund policy, calculates the eligible amount and prepares a refund request. It then calls a payment API to issue the refund. There are two different decisions here:
- Task authorization: The agent is allowed to handle refund requests within an approved scope.
- Action authorization: A particular refund, involving a specific customer, amount and payment destination, is approved for execution.
OpenAI Agents SDK: Human-in-the-loop supports this pattern by allowing individual tools to require approval. When a tool call requires human review, the run pauses and exposes the pending approval, including the tool and its arguments. Once the decision is recorded, the original run can resume.
Importantly, this approval mechanism also works with nested agents and handoffs. An approval requirement does not have to disappear simply because a specialist agent is executing the tool on behalf of another agent.
2. Where should the approval checkpoint sit?
A useful way to decide is to follow the workflow until it reaches an operation that changes something outside the agent's reasoning process. For example:- Retrieve the customer's order.
- Check the refund policy.
- Calculate the eligible refund.
- Prepare the refund request.
- Pause for human approval.
- Submit the refund to the payment system.
- Record the result.
A reviewer should see enough information to make a meaningful decision. What the reviewer sees with example:
Requested action: Issue a refundThe important point is that the reviewer is approving a defined operation, not giving the agent general permission to continue.
Customer/order: Customer 4821, Order 1098
Amount: ₹18,500
Destination: Original payment method
Supporting information: Order record and refund eligibility
Consequence: Payment reversal
Available decisions: Approve, reject or request changes
This distinction also explains why approval should not be required for every agent step. Reading an approved knowledge base, calculating a value or preparing a draft may not need the same intervention as issuing a payment, changing permissions or sending an external communication.
The objective is to place human review where it can change the outcome, without turning routine operations into a sequence of unnecessary confirmations.
3. The overlooked problem: What if the approved action changes before execution?
This is one of the most important implementation details in an approval workflow.Suppose a manager reviews a refund request for ₹18,500 and approves it. While the workflow is waiting, the agent receives new information and modifies the request to ₹28,500.
Should the original approval still be valid? No. The manager approved a particular amount and transaction, not every future version of the request.
This is closely related to a software security problem called a time-of-check to time-of-use issue. A system checks something at one point, but the underlying state changes before the operation actually uses that information.
In an AI agent workflow, the gap can occur between the approval screen and the eventual API call. A safer implementation binds the approval to the specific proposed action. This can include:
- The tool or API operation.
- The exact arguments submitted to it.
- The target account, customer or resource.
- The agent identity and relevant workflow context.
- The approval decision and reviewer.
- The version or identifier of the pending request.
If a material argument changes, the previous approval should no longer authorize execution. The system should generate a new approval request.The same principle applies if the underlying account details, permissions or business conditions change while the workflow is waiting.
OpenAI's Agents SDK provides a useful implementation detail here: tool input guardrails can run again after approval, immediately before execution. This helps catch a call that became unsafe while waiting for the reviewer.
The lesson is simple: approval must remain attached to the action that was reviewed, not merely to the workflow that requested it.
4. Pausing an agent is an execution-state problem, not just a user-interface problem
An approval request may be resolved in seconds, but it might also remain pending for hours or days. The agent cannot simply keep running in the background while waiting for a person.The execution state must be preserved so the workflow can resume safely. Frameworks implement this differently.
LangGraph uses interrupts and checkpointing. A workflow can pause, preserve its state and resume when a human supplies a decision. Its documentation also contains an important implementation warning: when an interrupted node resumes, the node starts again from the beginning.
That has a practical consequence. Imagine a workflow that performs a database update and then requests human approval later in the same node. If the node is re-executed after resumption, the earlier operation may run again unless it is protected.
Developers therefore need to place interrupt points carefully, separate consequential operations from replayable steps, and use idempotency controls where appropriate.
Idempotency means that repeating the same operation does not create an unintended second effect. For example, if an agent retries a refund request after a timeout, the payment system should be able to recognize the same transaction rather than issue another refund.
Cloudflare documents another pattern through durable workflows. Its approval mechanism can suspend an application task while waiting for a person, then continue when the approval arrives. The documentation also demonstrates timeouts, escalation and audit records.
These implementations reveal an important distinction: a human approval mechanism must manage both the review decision and the technical execution state behind it.
5. Human-in-the-loop vs. human-on-the-loop
The two approaches describe different levels of intervention.- Human-in-the-loop (HITL) means execution pauses until a human provides the required decision. It is appropriate when a particular action must not proceed without explicit authorization.
- Human-on-the-loop (HOTL) means the system operates within defined boundaries while a human monitors its behavior and can intervene when necessary.
- It can automatically retrieve order information and prepare refund recommendations.
- It can issue refunds below a defined threshold if the business process permits it.
- It must pause for approval before issuing a high-value or exceptional refund.
- A human team monitors exceptions and reviews the broader workflow.
Neither approach is universally better. Requiring approval for every low-impact operation can overwhelm reviewers and create rubber-stamping behavior. Relying entirely on monitoring is insufficient when an action must be authorized before it happens.
The approval design should reflect the potential consequence, reversibility, business rules and ability to detect or correct an error.
6. What should an enterprise record for every approval?
An approval record should establish what was requested, what the reviewer saw, what decision was made and what happened afterward. For a consequential action, retain:- Original task: Process customer refund
- Proposed operation: Issue refund through payment API
- Exact parameters: Order ID, amount and destination
- Initiating agent: Customer Support Agent v2.1
- Reviewer: Authorized Support Manager
- Decision: Approved
- Decision timestamp: Date and time of approval
- Execution result: Payment system accepted refund
- Change after approval: None, or a new approval required
This also means an approval record and an execution record should be connected. A reviewer might approve an action that subsequently fails, or a system might reject the request despite approval. Those are different outcomes and should remain distinguishable.
For further reading, see KlaritiQ's articles on AI Agent Access Control and AI Deployment Approval.
7. Questions to ask before deploying an approval workflow
Before allowing an AI agent to execute consequential actions, its owners should be able to answer:- Which exact operations require human approval?
- Does the reviewer see the actual tool arguments and consequences?
- Is approval bound to a specific action rather than the overall task?
- What happens if the action changes after approval?
- Can the workflow resume without repeating earlier side effects?
- What happens if the reviewer does not respond before the approval expires?
- Can the organization distinguish an approved action from a successfully executed one?
- Are the reviewer, decision, action and execution result connected in the evidence record?
8. From human approval to continuous assurance
Human approval is one control within a larger AI assurance process. Its effectiveness depends on whether the organization can establish what the agent was authorized to do, which action required review, whether the approval remained valid and what actually happened afterward.KlaritiQ approaches this through evidence-backed decisions, ownership and change tracking. The objective is to help organizations maintain a reliable record of approvals and the system context they relate to as AI systems and their responsibilities evolve.
The critical question is not simply whether a human approved the agent.
It is whether the organization can prove that the action executed was the action the human actually approved.