Human in the loop: AI agent approval workflows

'Should I continue?' is hard to assess. 'Review this proposed campaign budget change from $100 to $120 per day' gives a reviewer something concrete to decide. The amount is only part of the proposal: the reviewer also needs the account, campaign, timing, reason, and conditions under which it should proceed.

Put review at the action boundary. Let the agent gather evidence and prepare the proposed change first. Ask for a decision when the work is concrete enough to judge and before the action takes effect. Repeated permission questions during ordinary analysis can create noise without making the eventual decision clearer.

This guide offers a workflow design and evaluation checklist for business teams. Its examples are illustrative. They are not a claim that type.com or every agent platform automatically enforces each control. Test the actual tool, access configuration, and failure paths you plan to use.

NIST's AI glossary sorts systems into human-in-the-loop, human-on-the-loop, and human-out-of-the-loop by how meaningfully people are involved. For agents, the useful version is narrow: a person decides on a specific action, such as a refund, an email to a customer, or a CRM update, before it takes effect, rather than supervising everything the agent reads.

The mechanisms look different but share a shape: mark a tool or step as needing approval, pause, show the pending action to a person, and resume with the decision. LangGraph interrupts save graph state and wait indefinitely, and the OpenAI Agents SDK surfaces pending approvals as interruptions that you can serialize and resume later. The table compares how the major options pause and resume, from each vendor's documentation.

Durability is the detail to check. A review often takes hours, so a pause that lives only in a running process will be lost on the next deploy. Persist the paused state, record who approved, and make sure an approval can't be replayed against a different proposal.

In type.com, published apps ask for confirmation before any action that can delete data or change data through a person's connected account, and agent runs in threads can wait for a person's approval or answer, which you can also review from the command line with type-cli approvals. Code automations can also start from a Slack reaction, so a ✅ on a proposal can kick off the approved step.

Separate gathering evidence, preparing an output, and applying a change. A campaign analysis may be read-only. A proposed budget adjustment is a draft. Updating the budget changes the external account. A team can permit the first two while reserving the third for a named reviewer.

Make that scope specific to the workflow. 'Ask before important changes' leaves importance undefined. Describe the target systems, allowed actions, exclusions, and the person responsible for decisions. Start with one narrow operation so its effect and verification are easy to observe.

If a task creates several proposals, decide whether review is item-by-item or for a defined batch. A batch request should enumerate its members and limits. Permission to change one campaign is not permission to adjust every campaign that looks similar after the agent has started acting.

Use identifiers alongside readable names when similar records exist. 'Spring campaign' may refer to several accounts. A reviewer should be able to open the intended destination and compare the proposal with its current state. Give the reporting period and limitations behind the recommendation, not just its conclusion.

Show what remains uncertain. Perhaps revenue attribution is incomplete or a promotion ends tomorrow. Those facts can change whether a budget increase makes sense. The approval packet should help a person exercise judgment rather than push them toward an apparently inevitable yes.

Treat the proposal as a versioned object in your workflow design. If the target, amount, recipient, or material conditions change, the reviewer should see the revised proposal. An approval is only meaningful when it refers to the work that will actually be performed.

The campaign example below is deliberately narrow: one proposed budget change and one accountable reviewer. The analysis does not assume that a higher budget is the right answer. It prepares the evidence and states the reason for the recommendation so the reviewer can reject it or ask for a revision.

Keep the approved proposal available to the execution step. The tool should receive the intended account, record, and value rather than reconstructing them from an informal summary. How a platform stores and enforces that relationship is a capability to demonstrate, not something a well-written prompt proves.

Define the completion message in advance. It should state what was approved, what was attempted, and what the destination now shows. If verification is unavailable, report that uncertainty. Do not turn a successful tool request into a claim that the business outcome has already improved.

Start with rejection and no response. The demonstration should show that the proposed external action does not happen in either case. If the reviewer requests a different amount, verify that the revised proposal replaces the original and receives the appropriate decision before execution.

Next, change the destination while review is pending. Another teammate may have already edited the campaign budget. The workflow should detect the changed state and reconsider the proposal rather than overwrite it with a now-stale assumption. Choose the exact conditions that matter for your operation.

Finally, simulate an uncertain tool outcome. A timeout can happen after a destination accepted the action. Inspect the destination before retrying. For operations such as sending a message or creating a record, an unexamined retry can produce a duplicate. Where the integration supports an idempotency mechanism, test it; do not assume every tool has one.

An account may have permission to edit a campaign without the current workflow having approval to make this edit. Conversely, a reviewer may like the proposal but lack the authority or service access required to execute it. A workflow needs both the relevant access and a valid decision for the intended action.

A written instruction to ask first is not proof of an enforced approval gate. During evaluation, ask where execution is blocked, which identity can authorize it, and what happens if the agent tries to call the write tool without a decision. Inspect the actual behavior rather than relying on the wording of the instruction.

In type.com, Spaces control access to an area of work, while documents, apps, private threads, and connected services can have narrower permissions. AI acts with the effective access available to the person and conversation that started the work. Use that documented access model as the starting point, then test the exact tool and workflow.

Read type.com’s permissions and access documentation

Read about tool calls, files, and previews in type.com

Keep enough detail for someone who was not present to understand what happened. Include the target, approved version, reviewer decision, relevant preconditions, execution outcome, and verification evidence. Use the destination's own record or activity history where available.

Separate technical completion from business impact. A verified budget update confirms the setting changed. It does not prove the campaign became more profitable. Evaluate that later with a defined period and the relevant performance data. Keeping those claims separate prevents the result message from becoming an unsupported success story.

Review the first few runs before expanding the workflow. Look for unclear proposals, repeated revisions, slow handoffs, and unresolved outcomes. Improve the weakest step before allowing larger batches or more consequential actions. The product demonstration below shows a fictional proposal conversation, not a real approval log or a product enforcement guarantee.

Ask for a read-only analysis first, followed by a proposed change with its target and evidence. Inspect the tool activity and resulting state during the demonstration. Use a suitable test context for failure cases so evaluating the workflow does not create unwanted changes in live business systems.

Write down which controls the platform enforces and which still depend on team procedure. That distinction is useful when selecting a tool, onboarding reviewers, and deciding whether a workflow is ready for unattended preparation. A clear process can support good review; it should not be represented as a technical guarantee it does not provide.

Package the repeatable preparation as a shared workflow

Keep current facts separate from remembered context