For owners deciding what an agent may do, this guide explains approval before an action, permissions and monitoring afterward. It shows how to design a review queue, test execution routes and change authority using evidence from the particular workflow.
What you'll learn
- How pre-action approval differs from reviewing completed work
- How to check provider permissions and alternate tool routes
- Which details a reviewer needs before approving
- How to handle rejected, expired and interrupted actions
- How to revise authority without relying on approval rates alone
Approval workflows hold defined actions before execution. Combine them with checked permissions, a usable review queue and monitoring of completed outcomes; test the routes that could otherwise bypass the decision.
An approval workflow holds a defined action before it runs, so a person can approve, edit or reject it. Permissions limit which tools and records the system can reach. Use both to define an AI agent’s authority, then monitor the completed work to check that the limits and results behave as intended.
Say an agent prepares a client reply. The draft can be useful even when it names the wrong recipient. A pre-send gate gives the reviewer a chance to stop that particular send. A log reviewed afterward can help detect and repair the mistake, but it cannot prevent a completed send. Neither mechanism guarantees that a reviewer will catch every error.
What do people mean by approval before an action?
An approval gate holds a proposed action before execution; post-action review examines what already happened. Decide which job you need at each point. Prevention, detection and recovery complement each other.
For a customer message, the proposed recipient, attachments and text should be visible before the send. For a record change, the reviewer needs the selected record and the proposed difference. An “approved” badge with no connection to the action being executed supplies little assurance.
A later review can reveal a pattern of wrong recipients or missing source information. Use that evidence to improve the workflow and check whether other completed actions were affected. Human review remains useful after launch; it serves a different purpose from the gate that holds an action.
Avoid assuming that every error can be undone. You might correct a CRM field while another system has already acted on its previous value. A delivered email may have been read or copied. Trace the downstream effects before calling an action reversible.
How does an approval workflow actually work?
The workflow prepares a specific action, presents it for review and executes the authorised version only after approval. If the reviewer rejects it, it should remain unexecuted. If they edit it, the changed action needs the approval decision that applies to those final details.
As of October 2026, LangGraph’s documented interrupt mechanism can pause a workflow, save its state and resume when external input arrives.[1] That is one implementation mechanism, not a guarantee that every business action in a product is covered by review.
An approval is useful when it authorises the action that will actually run.
Check every route that can perform the action. A sending tool might be gated while a broader command tool still has access to the same account. A second agent might hold different credentials. A retry might reuse an old approval after the recipient or content changes. Those are cases to test, not reasons to trust the name of the approval feature.
Tie the decision to the action’s final details and record who made it. Set behaviour for rejection, timeout, cancellation and a lost connection. A pending item should have an identifiable state; it should not quietly turn into permission to execute.
What do you decide when designing the approval layer?
Classify actions by consequence, external visibility, reversibility and downstream effects. Use the following table as an illustrative starting point, then adjust it for the actual workflow. A tag can be low-risk in one CRM and trigger a customer message in another.
| Action | Reversibility to check | Visibility | Possible consequence | Suggested starting point |
|---|---|---|---|---|
| Tag a contact | Check dependent rules | Usually internal; check recipients | Routing or targeting changes | Automatic only after checking downstream use |
| Log a call note | Corrections possible; copies may remain | Check who sees the note | Incorrect customer history | Trial under review if consequential |
| Draft internal summary | Editing possible | Internal intended audience | Wrong information used in a decision | Draft automatically, define acceptance |
| Schedule internal task | Check notifications | Internal intended audience | Wrong owner or deadline | Automatic within agreed limits |
| Send client email | Delivered copies cannot be recalled reliably | External | False statement or wrong recipient | Pre-send review |
| Update payment record | Check accounting and connected systems | Depends on setup | Financial discrepancy | Review and independent reconciliation |
| Close deal or change stage | Check triggered actions | Team and connected tools | Wrong handoff or communication | Review consequential changes |
| Issue refund or credit | Check settlement and reversal limits | External | Financial loss | Review and separate payment authority |
| Escalate ticket externally | Check recipient and information disclosed | External | Wrong routing or data disclosure | Review before disclosure |
| Add internal CRM record | Check duplicates and triggers | Depends on setup | Duplicate or misrouted work | Automatic or reviewed after testing |
The placement is a recommendation, not a statement about a provider’s permissions. Record why an action is automatic, what input conditions qualify and when it must stop. “Internal” and “reversible” are questions to investigate, not automatic permission to bypass review.
What can permissions prevent independently of approval?
Permissions constrain the access granted to a connection. They may be broader than the task you want the agent to perform. Check the actual grant and the controls around its use, not only the label on a workflow step.
In October 2026, Google’s Gmail scope definitions distinguish viewing messages and settings from managing drafts and sending email. gmail.readonly provides the former; gmail.compose includes both draft management and sending.[2] A request for “draft-only access” therefore needs more than a Gmail compose grant. One option is to prepare drafts outside Gmail using a read connection, with sending performed separately under review.
| System | Behaviour required for the example | Access or route to examine | Failure to test |
|---|---|---|---|
| Read required messages and prepare a draft | Draft storage, granted scopes and any sending tool | A draft task sends without approval | |
| CRM | Read the selected account; change approved fields | Account access, field checks and bulk operations | A different record or field is changed |
| Calendar | Check availability and prepare a proposed invitation | Event-writing rights and notification settings | An invitation is sent before review |
| Slack | Deliver a review item to an agreed channel | App scopes, channel membership and permitted destinations | Content reaches a different channel or person |
| Invoicing | Read status and prepare a proposed invoice | Sending and payment authority | A draft creates a financial action |
Slack’s current chat:write documentation describes sending messages as the app.[3] A workflow’s choice of one review channel is not, by itself, proof that the app’s authority is limited to that one destination. Ask which restriction is enforced and test a different recipient.
If the available grant is broad, use a narrower connection or an enforced action boundary where possible. Document the remaining authority and who can change it. A useful permission map includes the account, tools, approved operations and the way unauthorised operations are denied.
What do systems without an approval layer depend on?
A system can restrict actions through permissions, tool availability or other enforced policies even without a human approval gate. A prompt instruction is a different kind of control: it tells the model how to behave, rather than withdrawing the ability to perform an action.
Check both the permission and every execution route. An instruction to “ask before sending” is useful guidance, but the business needs an enforced pre-send boundary if approval is required.
OpenClaw’s October 2026 documentation describes command-execution approvals and distinguishes those approvals from which tools are available. Its default fallback when the review interface is unavailable is denial, but the fallback can be configured differently.[4] A command approval feature is not a universal email, payment or CRM approval policy.
Ask the implementer to demonstrate the consequence of a forbidden request. What happens if the agent calls a different tool, if no reviewer is reachable or if the source message tells it to ignore the approval rule? Inspect the business record and action log after the test.
Keep instructions clear as well. They help the agent prepare the right action and explain why it needs review. Use an enforced boundary for authority and instructions for behaviour; neither removes the need to check the result.
How do you decide what belongs in the review queue?
Start with consequential actions and uncertain inputs, then assess the queue’s workload. A queue should give the reviewer a real decision and enough information to make it. Moving an action out of the queue is an explicit authority change.
Do not use approval rate alone as the release criterion. Approvals may reflect correct drafts, easy inputs or reviewers who did not read them. Examine edited, rejected and missed cases, and include representative difficult inputs before changing a boundary.
| Example action | Automatic candidate | Review candidate | What to check first |
|---|---|---|---|
| Tag CRM contact | If no consequential trigger | If tagging starts outreach | Downstream rules |
| Log call note | If scope and readership are agreed | If note affects an important decision | Correct account and source |
| Send client message | Only within explicitly approved authority | Pre-send review during the trial | Recipient, statement and attachments |
| Update payment record | Within a separately approved controlled process | Review consequential updates | Record identity and reconciliation |
| Close CRM deal | Only after validating triggered handoffs | Review during trial or exception | Connected actions |
| Add reporting row | If corrections and duplicates are managed | If row drives a consequential decision | Unique case and accepted data |
| Escalate support ticket | Within agreed routing rules | External disclosure or unclear recipient | Destination and information shared |
A long queue may mean the scope is too broad, context is missing or the reviewer has too little time. Reduce the scope, improve the draft and assign enough review capacity before deciding that fewer gates are the answer. The consequence of an error still matters even when drafts often need no edits.
What does control look like in daily work?
The agent can assemble a decision so you spend less time finding context, while a person still examines the consequential details. Measure that review time on the real workflow; there is no fixed number of seconds or minutes that every queue should take.
Permissions and gates can reduce the amount of work requiring intervention. Monitoring still checks completed outcomes, exceptions and whether the agreed controls are working.
Define authority before launch, and check how it is used afterward.
Each review item should show the proposed action, intended recipient or record, source information, changes and reason for review. Offer clear approval, edit and rejection choices. If a reviewer must open another system to verify a fact, account for that work instead of promising that all context is always sufficient inside the queue.
Give waiting items an owner and a response policy. Explain what happens to urgent cases, who covers absence and how pending work expires. A deadline can route or cancel an item; it should not create an unreviewed send by accident.
For the full operating setup, see what an AI agent implementation involves. This approval and control guide brings the permission map, decision queue and monitoring into the same workflow.
How should the approval boundary evolve?
Change authority after examining evidence for the particular action and its consequences. A period of correct drafts makes an action a candidate for reconsideration; it does not make removing review automatically safe.
| Illustrative stage | Queue | Permission scope | Review responsibility |
|---|---|---|---|
| Initial trial | Consequential and uncertain actions held | Minimum justified authority | Read each item; test errors and denied actions |
| Stable task evidence | Consider changing particular action classes | Add authority only by explicit decision | Examine accepted outcomes and missed cases |
| New inputs or workflow changes | Tighten review where assumptions changed | Recheck connections and downstream actions | Retest the changed scope |
| Ongoing operation | Review queue and scope on an agreed cadence | Remove unused grants; revisit changes | Named owner and absence cover |
These are stages, not a calendar or a universal approval-percentage threshold. Set cadence and response times from the work’s urgency and risk. A quiet queue may mean the work is stable or that cases are not reaching review; check both possibilities.
Where drafts need repeated edits, examine the cause. The source may be incomplete, the output expectation may be unclear or the decision may need human judgement. Improve what can be improved and retain the review where judgement remains necessary.
What happens when control design fails?
Investigate the route by which an unwanted action ran. The cause can be excess authority, a missing gate, changed scope or an ineffective review process. The following patterns are possibilities to test, not an estimate of how often failures occur.
| Failure pattern | How it can appear | Cause to investigate | Response |
|---|---|---|---|
| Excess access | Email or record change without required review | Broad grant or alternate tool route | Stop that action and review connections |
| Missing gate | Consequential action runs directly | Execution path not covered | Hold the action and test the corrected route |
| Scope drift | Work outside the agreed brief | Changes not reconciled with permissions and rules | Update the scope through an explicit decision |
| Queue neglect | Items approved without useful examination | Volume, context or reviewer capacity | Reduce scope and restore meaningful review |
Record the affected cases and check the completed business state. Correcting a configuration does not undo past actions. Decide whether people or connected systems need a correction, then test both the repaired workflow and the failure that exposed it.
Anthropic’s December 2024 guidance describes human checkpoints and stopping conditions, and warns about costs and errors compounding in autonomous work.[5] Use those mechanisms for a specific job, with measurable stopping behaviour and clear responsibility.
How do you set up control before the agent runs?
Make the permission map, action list and review responsibility part of the agreed scope. Test them before live authority is enabled. Then keep the record current when the work changes.
List every connected system
Name the account and the information or action the task needs. Include the tools that can reach the same account through a different route.
Check the actual permission grant
Compare the granted access with the task. A draft label may still include sending; a field filter may still sit on a broader write grant. Define how the narrower boundary is enforced.
Map direct and downstream actions
List drafts, writes, sends and routing decisions. Check what a record or status change triggers elsewhere.
Assign automatic or reviewed authority
Consider visibility, reversibility and consequence. Bind any required approval to the final action and define rejection, expiry and failure handling.
Record the scope and review it
Name the owner, reviewers, absence cover and stopping process. Revisit the map when tools, inputs or responsibilities change; keep evidence of authorised changes.
Frequently asked questions
What do approval workflows do in an AI agent system?
An approval workflow holds the configured action before execution. The reviewer approves its final details or rejects it. Test every tool route, changed inputs, retries, expiry and unavailable review; the feature name alone does not prove that the action is covered.
What is the difference between an approval gate and post-action review?
A gate holds an action before it runs. Later review examines completed work and supports detection and correction. It cannot prevent an action already completed, and a person can still approve a wrong action.
What should go in the review queue?
Start with consequential, externally visible or difficult-to-reverse actions and uncertain inputs. Check downstream effects before treating an internal action as low-risk. Automatic authority needs an explicit decision and evidence for the particular task.
How is an approval workflow different from a prompt instruction?
A prompt describes intended behaviour. An enforced boundary checks authority independently of the model’s interpretation. Permissions and tool policies can also restrict actions; a human approval gate is not the only possible enforced control.
What happens if a review queue gets too full to manage effectively?
Examine scope, missing context and review capacity. Reduce work or improve the proposal before removing consequential gates. A high approval rate may reflect correct outputs or unread items; it is not sufficient evidence by itself.
Can approval workflows be adjusted after initial setup?
Yes, through an explicit decision about the specific action and its consequences. Review accepted outcomes, edits, rejections and missed cases. Retest after changes and retain a named owner; no universal calendar or approval percentage establishes safety.
How do you stay in control of an AI agent?
Define the task, granted connections and actions requiring review before launch. Test denied actions and completed outcomes. Keep monitoring, exception handling and recovery alongside pre-action controls.
What is permission scoping for an AI agent?
It means granting only justified access and checking any broader authority the provider supplies. In October 2026, Gmail’s gmail.compose scope includes managing drafts and sending. A draft-only workflow therefore needs an enforced boundary or separate draft storage and sending path.[2]
Notes
- LangChain, Interrupts. Accessed October 14, 2026.
- Google, Choose Gmail API scopes. Accessed October 14, 2026.
- Slack, chat:write scope. Accessed October 14, 2026.
- OpenClaw, Exec approvals. Accessed October 14, 2026.
- Anthropic, Building effective agents. Accessed October 14, 2026.
