An agent finishes a customer announcement and asks whether it can proceed. The reviewer likes the wording. A few seconds later, the message goes to every customer, although the team intended to contact a small pilot group.
The problem began before the approval button. Nobody made clear whether the person was accepting the draft, approving its audience or authorizing delivery.
An AI agent approval workflow needs a specific decision, an authorized reviewer and an execution path that honors the decision's scope. Start by separating preparation, review and action. Then define what the person sees, what their response permits and what should happen if the circumstances change while the work waits.
This guide follows a customer announcement from draft to possible delivery. The same approach applies to a proposed account change, a purchase request or a production operation. The important question is what the human decision actually allows.
Write the approval rule before running the task
Consider a software company increasing its file upload limit for an invited pilot group. Product has confirmed the new limit, support has prepared the guidance and an account owner maintains the approved recipient list. An agent can help prepare the announcement.
The initial assignment should permit reading the approved product note and preparing a draft. It should exclude sending messages, adding recipients or changing account settings. The reviewer can then judge the proposed communication before anyone grants access to a delivery route.
A useful rule might be: the account owner reviews the exact message and the current pilot recipient list before delivery. Approval covers that message for that audience, subject to the pilot still being active.
This rule gives the team several things to inspect. There is a named decision owner, a defined output, a bounded audience and a condition that can invalidate the decision. “Ask a human before doing anything important” leaves all of those details for the agent to interpret.
For the broader concept, our guide to human in the loop AI explains the different contributions people make during agent work. Here, the focus is turning a particular decision into an operating workflow.
Separate the decisions your interface might otherwise combine
Three approvals can appear in the same process. They answer different questions.
| Decision | What the person is deciding | What it does not establish |
|---|---|---|
| Permission to begin work | Whether a defined execution attempt may start under its stated limits | That its eventual output will be correct |
| Acceptance of the result | Whether the finished draft or analysis meets the brief | That a later external action is authorized |
| Permission for an external action | Whether a particular operation may affect a defined target | That the operation has already succeeded |
In the announcement example, an agent could finish the preparation task successfully while the draft still awaits review. A person could accept the draft but ask the account owner to verify the audience. Delivery remains a separate operation.
Use language that makes these differences visible. “Approve this draft as ready for audience review” communicates a narrower decision than “Approve and send.” If the interface offers a combined operation, its target and effect need to be equally explicit.
Keep permission enforcement outside the agent's own account of what happened. A sentence in the conversation saying “approved” should not become an authorization token. The system responsible for the action needs to recognize the valid decision and the operation it covers.
Give the reviewer a complete but manageable packet
The review should begin with the decision being requested. Put the evidence close enough that the person can check it without reconstructing the entire conversation.
For this announcement, the packet needs the proposed message, the product note supporting its claims, the intended audience and any unresolved condition. If a source says the pilot begins after an operational check, preserve that condition in the draft. Do not convert a planned capability into an announcement that it is already available.
Identify who maintains the audience. An agent's interpretation of a customer spreadsheet is not equivalent to the account owner's current recipient list. If the workflow uses a linked source, confirm that the reviewer has permission to inspect it.
Show what changed when a draft returns for another review. A person who already checked the wording should be able to see that a later revision changed the launch date or removed a limitation. Small edits can change the commitment a customer reads.
Do not ask a reviewer to approve missing information. A compact statement such as “recipient list awaiting confirmation” helps the person decide what is ready and what still needs an owner. Hiding the gap behind a polished preview makes the approval less useful.
Make waiting a normal state
People close tabs, finish their working day and hand responsibility to colleagues. The proposal should remain understandable during that interval.
Retain the request, its evidence, the responsible reviewer and the specific response needed. Give the team a way to reject the proposal or request a revision. An unanswered request should remain unanswered unless the organization has explicitly defined another permitted route.
Software can support that waiting state. Microsoft's Agent Framework documentation describes workflows that request external input and wait for a response. LangGraph interrupts provide a mechanism for pausing execution and later resuming it. The application still has to connect the response to the correct reviewer and proposed operation.
Decide how the proposal becomes stale. In this example, the pilot may be postponed, the recipient list may change or the product note may be corrected. A person returning tomorrow needs to know whether they are reviewing a current proposal.
Set a sensible escalation route for an unavailable reviewer. It could involve another authorized account owner, a revised delivery date or cancellation. Repeatedly asking different people until somebody clicks Approve weakens the decision process.
Try the preparation and review stages in Swarm
Create a private Swarm Space for the pilot announcement. Add a sanitized product note and a description of the intended audience. Invite the reviewer with the appropriate access. For a first exercise, use example recipients and keep actual delivery unavailable.
In the conversation composer, choose Ask agent and request a draft based on those sources. Ask it to preserve the pilot scope, identify unsupported claims and list the decisions still needed. Select an available execution route with the permissions needed for preparation.
Enable Decision gate before selecting Start agent work. In Swarm, this asks a human to review the completed output. It is not a switch that pauses every tool call before it happens. The Run may show Succeeded while the result approval is still Pending.
Open the full output and its sources. From Approvals, an authorized human can inspect the specific request, leave a note and choose Approve or Deny. Confirm the saved decision afterward. The current Runs guide explains result review, execution approvals and external actions as separate states.
You can also have an existing compatible agent prepare the work through the connection guide. Its access should cover only the intended Space and contribution. A connection does not grant the agent human approval authority.
The result of this exercise is a reviewed draft with an inspectable decision. It does not send the announcement. That narrower first result is useful on its own and lets the team evaluate the review process before adding a consequential integration.
Check the proposal again before an external action
If the team later connects a delivery system, define that action separately. Specify the approved content, audience, permitted sender and conditions that must still hold. The responsible application or integration must enforce those boundaries.
Before sending, check whether the message or audience changed after review. A new recipient is a new disclosure. A corrected product limit changes the claim. A postponed pilot can make the entire announcement premature.
If relevant conditions changed, return the revised proposal to the appropriate reviewer. Avoid silently applying an earlier decision to a materially different action. Preserve the previous draft so the reason for another review remains clear.
Confirmation matters after the action too. A delivery attempt can fail, partly complete or return an uncertain response. Record what the delivery system actually confirms. If a response is lost, inspect the operation's state before retrying an action that might create duplicate messages.
This is where a shared work record helps the next participant. They can distinguish a prepared announcement, an accepted draft, an authorized send and a confirmed delivery without interpreting the last chat message as the entire history.
Rehearse the decisions that are easy to get wrong
Use an exercise with external actions disabled before relying on the workflow. Write down the expected behavior for each situation.
The reviewer accepts the wording while the recipient list remains unconfirmed. The workflow should preserve the outstanding audience decision.
The pilot date changes while approval is pending. The person should see a current proposal or a clear reason that the earlier request cannot proceed.
Someone rejects the draft. The work should stop or return for an explicitly requested revision.
An agent writes that a human approved it. That statement should not satisfy a required human gate.
A different colleague takes over the review. Their authority and access need to be appropriate for the requested decision.
The delivery system returns a timeout. The next step should reconcile the result before attempting another send.
Review the effort involved as well as the decisions. If people routinely open the request and then search elsewhere for basic facts, improve the packet. If they approve nearly identical low consequence requests all day, examine whether the boundary is too broad or poorly placed.
An approval count does not tell you whether people exercised useful judgment. Look for corrections that changed the proposal, missing evidence that prevented premature action and decisions that remained understandable when somebody else continued the work.
Start with one decision your team already makes
Choose a recurring proposal that currently arrives through chat or email. Put its brief and permitted evidence in a private Space, have an agent prepare the output and ask the responsible person to review that exact result.
Keep the first trial limited to preparation and review. Once the team can tell what was accepted, by whom and under which conditions, decide whether a separate external action belongs in the workflow.
Good approval design lets people spend their attention on a real decision. The agent prepares the work, the person understands what they are allowing and the record remains clear enough for the next participant to continue.