How should human approval work in an AI agent workflow?
Human approval should be a deliberate checkpoint before an AI agent takes a consequential action. The agent pauses, shows the proposed action, target, evidence, and likely effect, then waits for a named person to approve or reject it. The decision is recorded, and the workflow resumes from durable state rather than starting over.
That sounds simple until every step gets an approval button. Then the owner is not controlling the agent. The owner is manually operating a slower interface and learning to click “approve” without reading. A useful approval system does not put a person everywhere. It puts a person where a wrong action would be costly, difficult to reverse, private, or externally visible.
The design question is not whether your agent is human-in-the-loop. It is which decisions need human judgment, what the reviewer must see, and what happens when nobody approves. Those choices determine whether approval is a real operating boundary or theater.
What does human-in-the-loop approval actually mean?
Human-in-the-loop approval is a workflow state, not a polite message from the model. Microsoft describes the pattern as an agent requiring user input, such as approval for a function call. The run returns an approval request instead of pretending the task is finished. A person supplies the decision, and the work continues in the same session.
OpenAI's Agents SDK uses the same operating shape. A tool can be marked as requiring approval. When the agent tries to call it, the run pauses and exposes the pending action. After a person approves or rejects it, serialized run state allows the workflow to resume. That resumable state matters. If approval forces the agent to reconstruct the task from memory, the checkpoint can change the very context the person approved.
A good approval gate therefore has four parts: a trigger, an approval request, a recorded decision, and a deterministic continuation path. Remove any one of them and the control weakens. A warning with no enforced pause is not a gate. An approval click with no record is not accountable. A recorded decision that cannot resume the original task creates manual repair work.
This is one reason to [map the business process before turning it into an agent](https://gallmur.com/en/notes/turn-business-process-into-ai-agent/). You cannot place a meaningful checkpoint until you know where the workflow changes money, access, customer communication, contractual commitments, or the system of record.
Which agent actions should require approval?
Start with consequence, not technical complexity. Reading a public page may involve several tools and still be low risk. Sending one message to a customer may use one tool and carry much more risk. Approval belongs before the consequence, not before whichever step looks most sophisticated.
Require approval for irreversible or expensive actions: purchases, refunds, deletion, permission changes, binding commitments, public publishing, and outbound communication in the owner's name. Also gate actions involving sensitive records, ambiguous identity, low-confidence matching, or a change to the business's source of truth. If a wrong result can be cheaply reversed and independently verified, post-action review may be enough.
NIST's AI Risk Management Framework treats human oversight as a documented responsibility across configurations ranging from fully manual to fully autonomous. That spectrum is more useful than a blanket rule. One workflow can contain read-only steps that run automatically, reversible updates that run with monitoring, and a final external action that pauses for a person.
Use conditional gates when the risk changes with the case. A draft under an approved template may proceed automatically, while a draft containing a price change, legal claim, unusual recipient, or missing source stops. OpenAI's SDK documentation describes callable approval rules and a fail-closed default when tool arguments cannot be safely inspected. That is the right instinct: malformed or unclear action data should increase scrutiny, not bypass it.
What must the approver see before making a decision?
Never ask a person to approve “the next step.” Show the exact action in business language. Who receives the message? Which record changes? What value changes from what to what? Which evidence supports the recommendation? Can the action be undone? The reviewer should not need to open three systems and reconstruct the agent's reasoning just to understand the request.
The approval request should separate facts from the agent's recommendation. Facts might include the destination record, source document, current status, proposed value, and policy that triggered the gate. The recommendation explains why the agent thinks the action should proceed. This lets the owner reject weak reasoning without losing the underlying evidence.
Include the minimum context needed to judge the consequence, not the full conversation transcript. Too little context produces blind clicks. Too much produces review fatigue. For a payment, show amount, recipient, purpose, and source authorization. For a CRM merge, show both identities and conflicting fields. For outbound communication, show the final message, recipient, channel, and whether the conversation already exists.
The same buying standard belongs in any system sold to a nontechnical owner. The guide to [choosing an AI system without technical staff](https://gallmur.com/en/notes/best-ai-system-nontechnical-business-owner/) explains why owners should demand visible approval boundaries and evidence rather than accept a generic promise that a system is “supervised.”
How do you prevent approval fatigue and rubber-stamp decisions?
Approval fatigue is a design failure. OpenAI's governance paper warns that people forced to approve many decisions tend to approve each one quickly, reducing meaningful consideration. More checkpoints can create less control because repetition trains the reviewer to treat the gate as friction.
Keep the approval queue small by moving low-risk, reversible work to automatic execution with logs and review. OpenAI describes action ledgers as a lighter-touch option for actions that can be inspected after the fact. This is not weaker by default. For routine actions, a searchable ledger plus exception alerts can provide better oversight than fifty identical prompts.
Batch only when the items share the same risk and the reviewer can inspect the differences. “Approve 40 updates” is dangerous when one record changes a contract value. “Approve 40 formatting corrections, with three policy exceptions separated for individual review” is a real control. Exceptions deserve attention; normal cases deserve evidence.
Measure the gate itself. Track approval volume, rejection rate, time to decision, repeated overrides, and actions that time out. A rejection rate of zero is not automatically success. It can mean the agent is excellent, the gate is unnecessary, or nobody is reading. Review samples of approved actions against their source evidence to learn which explanation is true.
What should happen after approval, rejection, or timeout?
Approval should authorize one exact action, not grant a vague permission window. If the target, amount, message, or arguments change after approval, the authorization is stale and the workflow should request a new decision. The execution receipt should link the approved proposal to what actually happened at the destination.
Rejection needs a defined path too. The agent may revise the proposal, route the case to a person, or stop the workflow. It should not keep asking the same question with slightly different wording until someone gives in. Record the reason when practical because repeated rejection reasons reveal a broken policy, weak input, or a task that should remain manual.
A timeout is not approval. Choose an explicit safe default: stop, defer, or route to another named owner. Never let silence become permission for a consequential action. For time-sensitive but reversible work, the policy may allow a bounded fallback. For money, access, public communication, or deletion, fail closed.
Finally, verify the destination. An approved tool call can still fail, hit the wrong record, or return an ambiguous response. The production [failure-mode guide](https://gallmur.com/en/notes/ai-agent-failure-modes-production/) covers why approval and completion verification solve different problems. Approval grants authority. Read-back evidence proves execution.
What is a practical approval policy for a small business?
Begin with one workflow and name three to five action classes, not dozens of edge cases. For each class, write the trigger, approver, required evidence, expiration time, rejection path, and completion proof. Keep it readable enough that the person responsible can explain it without the builder present.
A practical first policy might let the agent research, classify, draft, and update a temporary work queue automatically. It may require approval before sending, purchasing, deleting, changing permissions, or writing to the canonical customer record. Every external action gets a destination receipt. Every timeout stops or routes to a named person.
Test the ugly cases before expanding autonomy: missing approver, duplicate request, stale approval, changed arguments, contradictory records, unavailable tool, rejection, and a timeout during execution. Google Cloud notes that human-in-the-loop checkpoints add architectural complexity because an external system must hold and resume the work. If your design cannot survive these cases, adding more approval buttons will not fix it.
After a week of real use, remove gates that add no decision value, tighten gates that lack context, and convert repeated exceptions into explicit policy. The goal is not maximum autonomy. It is the smallest amount of human attention that still protects the decisions only a human should own.
What are the limitations of human approval?
Human approval does not make an agent correct, secure, or compliant by itself. Reviewers can miss details, misunderstand technical actions, approve under time pressure, or rely on evidence selected by the same system they are supposed to supervise. A compromised interface can also present one action while executing another unless the approval is bound to exact arguments.
Approval is also a poor substitute for narrow permissions. If an agent only needs to draft a refund recommendation, it should not hold unrestricted refund authority and depend on a prompt that says “ask first.” Tool permissions, identity controls, durable logs, deterministic validation, and destination read-back remain necessary.
Use approval for judgment and authority. Use software boundaries for enforcement. Use evidence for verification. If you are deciding where those three belong in a real workflow, [apply for a workflow-to-agent map](https://gallmur.com/en/contact/?utm_source=seo&utm_medium=organic&utm_campaign=human-approval-ai-agent-workflow) before connecting the agent to production systems.