A human-in-the-loop AI workflow pauses at a defined decision and gives an authorized person enough information to approve, edit or reject the next action. To make that useful in production, the application also needs to preserve the proposal, resume the right work, check current permissions and show what actually happened. An approve button by itself does not provide those guarantees.
Use this guide when an AI feature is moving from generating drafts to sending messages, updating business records or triggering connected workflows. It follows a fictional customer-follow-up proposal through review and execution. The state model and test cases are implementation planning aids, not a claim that one approval pattern makes every AI application safe.
Key takeaways
- Place review where a decision matters; distinguish approval, clarification and handoff.
- Show the exact destination, content and effect that the person is authorizing.
- Persist the proposal and decision separately from the conversation.
- Expire or reopen approval when relevant details change, and recheck permissions before execution.
- Treat uncertain execution as a reconciliation task rather than an automatic retry.
Why approval workflows matter for operational AI
When AI prepares text, a person can inspect the result before using it. Connected agents introduce another step: the system may use tools to change something outside the conversation. The product needs a deliberate boundary between preparing a proposal and executing it.
Recent guidance reflects that shift. Zapier's human-in-the-loop article, updated October 14, 2026, describes approval, escalation, feedback and audit patterns. Anthropic's containment engineering also explains that human supervision has limitations and that access boundaries remain important. These ideas complement each other: design a useful review step and constrain the actions available behind it.
Start with a task the business can describe clearly. For example, an assistant may draft a reply to an inbound project enquiry. The business might allow summarization and internal routing while requiring review before an external message is sent. That is a concrete authority boundary a team can implement and test.
Choose the kind of human involvement the task needs
Approval means a person authorizes a specific proposed action. Clarification means the system needs missing information before it can prepare a useful proposal. Handoff means another person or team takes responsibility for continuing the work. These states need different interfaces and outcomes.
Do not turn every uncertainty into a yes-or-no question. A reviewer cannot meaningfully approve an email when the intended recipient is unknown. Ask for the missing destination first. Similarly, a support incident outside the agent's scope should move to an accountable support process instead of returning to the same model for repeated guesses.
Classify operations with the business owner. Some can run under bounded rules, some need review before execution and some should remain outside the integration. The classification should reflect the effect of a mistake and the ability to recover, rather than whether the model sounds certain.
| Situation | Human step | Successful outcome |
|---|---|---|
| A complete reply is ready to send | Approval | The authorized reviewer accepts or changes the exact proposed message |
| The customer's requested date is ambiguous | Clarification | The missing detail is supplied before a proposal is finalized |
| The issue needs account investigation | Handoff | A named team receives the evidence and owns the next step |
| A requested action is outside the service boundary | Decline or separate process | The integration does not obtain extra authority merely to finish the request |
Show the action the reviewer is actually approving
For the fictional follow-up, the review screen should identify the enquiry, destination address, full message and expected effect. Show the supporting source and mark assumptions separately. If a tool will update a CRM stage as well as send a message, make both effects visible or split them into separately reviewable operations.
Give the reviewer an edit and rejection path. A generic 'Continue' control can hide whether the person is approving a draft, granting ongoing authority or executing a one-time action. Use wording that matches the actual operation. Keep the presentation short enough to inspect without hiding the details that determine the consequence.
An illustrative approval record can contain a proposal ID, target resource, exact action payload, source version, policy version, reviewer identity, decision time and expiry. It should refer to evidence the reviewer can access. Protect that record according to the data it contains; an audit trail should not become an unrestricted copy of customer messages.
- What will change, and in which account or system?
- Who receives the result, and what exact content will they see?
- Which evidence supports the proposed action?
- What other effects happen as part of the same execution?
- What will cause this decision to expire or require another review?
Make pause and resume durable
A review can outlive a browser tab, a worker process or an ordinary request timeout. Persist the proposal and pending status so the workflow can resume after a restart. Keep the decision associated with the right work item, rather than relying on whichever message happens to be latest in a conversation.
Microsoft Agent Framework documents request-and-response interactions in which a workflow waits for external input. LangChain's HITL middleware documents interrupted tool calls with persisted graph state and configured decision types. These mechanisms can support a review flow, but the product still needs its own authorization, lifecycle and operational decisions.
The following is an original state contract for the fictional message workflow. Names can differ in your system; what matters is that waiting, rejection, uncertainty and confirmed execution remain distinct and recoverable.
| State | What is known | Allowed next step |
|---|---|---|
| Proposed | A draft action exists | Validate required details and create a review item |
| Awaiting review | The action has not run | Approve, edit, reject or expire the proposal |
| Approved | A specific payload has a current decision | Recheck authority and relevant state before execution |
| Rejected or expired | No current permission to execute | Close the item or prepare a new proposal |
| Executing | An identified operation is in progress | Record the result or reconcile an uncertain response |
| Confirmed | The destination reports the intended result | Show the actual outcome and destination reference |
| Needs reconciliation | The result is uncertain | Check the destination before deciding whether to retry |
Recheck the details that can invalidate approval
A decision can become stale even when the reviewer clicked the right button. The customer may change their request, the recipient may be corrected, the proposed content may be edited or the reviewer may lose access. Decide which changes invalidate approval and enforce that rule where execution happens.
For the message example, bind approval to the final reviewed recipient and message version. If either changes, return the proposal to review. At execution time, verify that the reviewer and service still have the required permissions and that the action is still relevant to the work item. A stored 'approved' flag should not override current access rules.
Use expiry based on the workflow's operating needs. A time-sensitive response may need a fresh check after a queue delay; a durable internal classification may have different requirements. Set those limits deliberately and show expired items as expired, rather than quietly treating a missing response as acceptance.
Which decisions should your team keep?
Share one repeated task and the actions your AI should prepare. We can help design the review experience, connected execution and recovery checks.
Keep retries from turning one decision into two actions
A double click, repeated queue delivery or worker restart can revisit an approved item. Give the external operation a stable identifier and use the destination's supported duplicate-protection mechanism where available. Also keep your own execution history so the system can recognize work already attempted.
If the destination sends a definitive failure, follow the agreed recovery path. If the response is lost, preserve the uncertainty. For a sent message, check the provider's available operation or delivery reference before sending another copy. Where reliable reconciliation is impossible, route the item to an operator instead of retrying blindly.
Separate the decision from execution attempts. One reviewed proposal may require investigation after a timeout, but that does not mean the model should generate a fresh message and reuse the earlier approval. Retain the reviewed payload and show staff the actual state.
Design the review queue as a real operational tool
Assign a responsible team, backup owner and escalation path. A queue that waits indefinitely can be less useful than a clear manual process. Show age, reason for review and what information is missing so the reviewer can prioritize without reopening every conversation.
Review workload matters. Requiring a click for every harmless step can encourage people to approve without inspection. Reduce avoidable requests through clear rules and better preparation, while keeping meaningful decisions visible. Human review and technical access controls should reinforce one another; neither should be presented as eliminating all risk.
Measure waiting time, edit and rejection reasons, expired proposals and uncertain actions. Repeated edits to the same field may reveal poor source data or a misleading prompt. Repeatedly unattended items may reveal an ownership or staffing issue rather than a model-quality problem.
Record only the information needed for operation and review. Establish access, retention and deletion behavior for proposals and logs as part of the product scope, including what happens when the source record changes or is removed.
Test decisions and recovery before increasing authority
Write the expected outcome before running each test. Include ordinary approvals, useful edits, rejections, stale data and interruptions. Use an isolated destination or appropriately controlled test environment so a successful test does not create a real customer action.
The cases below are a planning checklist. They are not evidence that any named framework handles the entire workflow automatically. Your implementation must demonstrate the behavior with its own persistence, tool configuration and destination integration.
| Test | Required result | Failure to investigate |
|---|---|---|
| Reject the proposal | No external action runs | A rejection is recorded as a successful execution |
| Edit the recipient after review | A new review is required | Old approval authorizes a new destination |
| Restart while awaiting review | The same pending item is recovered | The item disappears or runs without a decision |
| Deliver the execute job twice | One intended action with a reconciled status | Duplicate messages or CRM changes |
| Revoke reviewer access | Current permissions are applied | A historical flag bypasses revoked authority |
| Lose the destination response | The item enters reconciliation | The system claims completion or sends blindly again |
Scope one useful approval workflow first
A first release should identify the task, permitted reads, proposed writes, review payload, authorized reviewers, persistence mechanism and recovery owner. Keep the initial authority narrow enough that the team can explain every external effect. Expand it only when reviewed evidence supports the next step.
For an inbound-sales pilot, that might mean an AI-generated qualification summary and one reviewed response, with CRM routing visible to the receiving team. It does not require automatic negotiation, an unrestricted mailbox or permission to change every customer record.
MUBBITS can help turn that boundary into a working product: the interface people review, the backend checks, the connected action and the tests that show how it behaves. Bring one repeated task and the decisions your team needs to keep. Those details provide a better starting point than an open-ended request for a fully autonomous agent.
Frequently asked questions
Is human-in-the-loop the same as human handoff?
No. Approval usually authorizes a defined proposed action, while handoff transfers responsibility for continuing a task. Clarification collects information needed to prepare a proposal. A product can support all three, but each needs an explicit owner and outcome.
Does adding approval make an AI agent secure?
Approval is one control. Permissions, data boundaries, constrained tools, current-state checks and recovery behavior remain necessary. Reviewers can also misunderstand or overlook a proposal, so the interface and operational process need testing.
Should every AI tool call require approval?
Not automatically. Classify operations by their effects, constraints and recovery options. Keep meaningful decisions reviewable while allowing suitably bounded operations to follow agreed rules. Reassess the classification when the workflow or available tools change.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.