MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

An approval button is useful only if the reviewer understands what it will permit. “Allow this action?” is a weak question when the action could send an email, update a customer record or share a confidential attachment. A meaningful approval presents the exact proposal, its destination and its consequences before execution.

Human review is not a decorative pause in an automated workflow. It is a decision with a scope, an authorized reviewer and a limited lifetime. Designing those elements carefully helps people make informed choices without forcing them to inspect raw tool calls all day.

Start with the action preview

Imagine a hypothetical sales assistant preparing a follow-up email after a customer meeting. A useful review card shows the verified recipients, subject, message body and attachments. If the assistant proposes sharing a document link, the card should also show the intended access level and whether the link can be forwarded.

The reviewer should not have to infer a destination from a display name alone. Similar names and stale contacts are common sources of ambiguity. Show enough identity information to distinguish the intended recipient, while avoiding unnecessary personal details. If the identity remains unresolved, resolve it before asking for approval.

For a record change, show before and after values. For a purchase request, show the relevant item, quantity and commitment. For a deletion, show what will be removed and whether recovery is available. The preview should match the action that will actually execute, not a simplified description that hides material details.

Bind the decision to a specific proposal

A reviewer may approve one email draft and reject a later version with a different attachment. Store an identifier for the proposed action and the version reviewed. If recipients, content or other material parameters change, require a fresh decision rather than reusing the earlier approval.

The OpenAI Agents SDK human-in-the-loop guide documents approval-gated tool calls, paused execution and resumption. These mechanisms support a review workflow, but the application must still present the right information and decide how approvals map to business authority.

Be cautious with broad or persistent approvals. A choice that permits future calls to the same tool may cover more than a reviewer expects. For consequential actions, per-action review is often easier to explain. If broader approval is appropriate, its scope should be visible and deliberately granted.

Choose the reviewer by authority, not availability

The person who initiated a task is not always the person entitled to approve its final action. A junior employee may ask for a purchasing draft while a budget owner must authorize submission. A system administrator may have technical access without commercial authority to approve a refund.

Represent reviewer eligibility in application policy. Do not ask the model to infer authority from a job title in an email signature. Check the authenticated reviewer and the action’s scope at the point of approval, then recheck relevant conditions before execution if the workflow can remain pending for a long time.

Keep approval and backend permission separate. A human click should not bypass resource-level access checks. OWASP’s excessive-agency guidance identifies risks arising from excessive permissions and autonomy. Human review reduces some risks, but broad technical authority can still create a dangerous failure path.

Handle rejection as an outcome

A reviewer who rejects an email may want the task stopped, revised or escalated. Offer those choices clearly when they fit the workflow. Do not let the agent keep presenting substantially identical requests until the reviewer gives in.

A rejection reason can help the assistant prepare a better draft, but it should not become a prompt to evade the boundary. “Do not send this externally” should not lead the system to create a public link instead. Preserve the intent of the rejection across subsequent steps.

Record the decision and communicate its effect. The user should know whether the draft remains available, whether the task is closed and whether any action occurred before review. If partial work already changed external state, make that visible rather than implying rejection reversed everything.

Expire stale approvals

Some conditions change while a request waits. A price may expire, a recipient may leave, a record may be edited or the user may cancel the task. Decide which changes invalidate the proposal. A timestamp alone is not enough if the action’s meaning has materially changed.

Before executing a delayed approval, verify that the reviewed version is still the intended version and that the task remains active. If a relevant fact changed, return the proposal to review with a concise explanation. This is safer than silently substituting fresh parameters into an old approval.

Make review effort proportional to risk

Not every read requires a confirmation dialog. Excessive low-value prompts can train reviewers to approve without attention. Classify actions by consequence and reversibility, then place meaningful review where it is needed. Keep routine reads inside narrowly enforced permissions rather than asking users to repeatedly approve vague access.

• Does the card identify the exact destination and affected records?
• Can the reviewer inspect all material content and attachments?
• Is the reviewer authorized for this action and scope?
• Will a material change require another approval?
• Can the reviewer reject, revise or cancel without ambiguity?
• Will the application verify the result after execution?

Test the approval path, including the wrong click

Use synthetic proposals to test a stale approval, a changed recipient, an unauthorized reviewer and a canceled task. Inspect both the interface and the execution trace. The SDK tracing documentation provides execution-observation mechanisms, with sensitive-data settings that should be reviewed before recording approval content.

A good approval workflow makes the consequential choice understandable and preserves what the person actually authorized. It does not ask a human to compensate for every model weakness. Pair a clear preview with narrow permissions, versioned proposals and verified outcomes, and review becomes a real control rather than a reassuring button.

Sources and further reading

OpenAI Agents SDK: Human-in-the-loop. Approval-gated tools, interruption and resumption; checked October 2026.

OWASP: Excessive Agency. 2025 risks of excessive permission and autonomy; checked October 2026.

OpenAI Agents SDK: Tracing. Execution observation and sensitive-data controls; checked October 2026.