AI Agent Approval Workflows: Control Business Actions Clearly

Last updated: 30 September 2026.

A marketing manager approves a proposed budget adjustment. Ten minutes later, the agent submits a different amount against a different campaign because fresh data changed its recommendation. The system has an approval record, but the manager never reviewed the action that actually happened.

The useful design question is therefore specific: how does the application prove that this action is covered by a valid decision?

For a team building a custom marketing AI agent, answer that before enabling writes. Start with one consequential operation, such as modifying a campaign budget or adding contacts to an active journey. Reading data and preparing the proposal can proceed within existing permissions. The approval should cover the business change that needs judgment.

What needs approval, and what can run within standing permission?

Define permission around the operation and its impact. The label “AI agent” does not tell you whether a task needs review.

A weekly draft report can usually run under standing authorization to read specified data and save an internal draft. Sending that report to a new external recipient creates a different decision. Reassigning one unowned lead within an agreed routing rule differs from replacing ownership across the entire CRM.

Use three practical outcomes in the policy:

• Allow an action within a defined scope and limit.
• Prepare the action and require a qualified reviewer.
• Reject an action that this workflow is not permitted to perform.

The third outcome matters. A reviewer should not be able to approve a customer export through a workflow designed only for budget recommendations. Some requests belong in a separate process with different permissions and evidence.

OWASP identifies excessive functionality, permissions and autonomy as causes of excessive agency. Its guidance includes narrowing tools and permissions and requiring human review for high-impact operations. This supports enforcing a small set of business operations, rather than connecting a broad administrative tool and hoping the prompt supplies the boundaries. OWASP excessive agency guidance.

Standing permission can remain useful and specific: “Generate the Monday report for these accounts and save it in this workspace.” Repeatedly asking for the same already-authorized read adds delay without supplying a new business decision. Review should occur when the proposed action crosses the agreed boundary.

What must the reviewer actually see?

Present the proposed change, its evidence and the limits together. For a budget change, the review screen should identify the account and campaign, the current and proposed amounts, the effective period and the reason for the recommendation.

Also show the consequences of saying yes. A change from USD100 to USD120 per day is a 20% increase. If five campaigns receive that increase, the maximum additional daily allocation is USD100, assuming each starts at USD100. Displaying only “20% optimization” hides the aggregate decision.

Use stable record identifiers beside readable names. Campaign names can repeat. If the action changes several fields, show a field-by-field difference. If the evidence is incomplete, expose that limitation beside the recommendation rather than burying it in a generated explanation.

The reviewer needs the applicable constraints: the maximum amount, affected records, expiration and whether partial execution is allowed. They do not need a transcript of every model token. The goal is enough evidence to assess the proposed change with reasonable effort.

The MCP tool specification recommends confirmation for sensitive operations and displaying inputs before calls. It also says tool annotations are untrusted unless provided by trusted servers. A tool describing itself as safe does not replace your own classification of the operation. MCP tools specification.

Bind approval to an exact proposal

Create an immutable proposal version before requesting review. Store the consequential fields in a stable representation and associate the decision with that version. If the agent changes the target, values or execution scope, create a new version.

This original example describes an application-level approval record, not a vendor API payload:

{
  "proposal_id": "budget-proposal-042",
  "proposal_version": 3,
  "workspace_id": "workspace-example",
  "operation": "set_campaign_daily_budget",
  "target_ids": ["campaign-17"],
  "expected_budget_usd": 100,
  "proposed_budget_usd": 120,
  "maximum_additional_daily_usd": 20,
  "valid_for_minutes": 30,
  "allow_partial_execution": false,
  "reviewer_role": "paid_media_owner",
  "execution_key": "budget-proposal-042-v3"
}

Store the authenticated reviewer's identity, decision timestamp, permitted role and the reviewed version separately from model-generated text. The application must calculate expiration from its trusted timestamp. The model should not be able to extend approval by rewriting a field.

A content digest can help detect a changed proposal, but a hash alone does not establish who approved it or whether the approval is still valid. Protect the approval store and verify the user's authority. Treat those as application responsibilities.

The distinction from account connection is important. MCP authorization defines access to restricted servers at the transport level. Completing that connection is not evidence that a manager approved a particular campaign change. MCP authorization specification.

Recheck business conditions immediately before the write

Approval may wait while the business changes. A sales representative can take ownership of a lead. A customer can unsubscribe. A campaign can become paused. These changes should affect execution even when the proposed payload itself is unchanged.

For the budget example, reread the current amount before executing. If it is now USD140 because another manager changed it, the original expected value of USD100 is no longer true. Applying the approved USD120 value could reduce a budget when the reviewer intended an increase.

Where the downstream system supports conditional updates or version checks, use them. Otherwise, minimize the interval between checking and writing, and define how conflicts are detected afterward. A separate read followed by an unconditional write still has a race window; do not call it an atomic guarantee.

For messaging, an approved recipient list still needs current suppression and eligibility checks. The approval authorizes a proposed audience subject to those rules. It should never turn a later opt-out into an exception the agent can override.

Open full diagram

This design lets authorized preparation continue while reserving attention for decisions that actually need it. The diagram's standing-permission branch still goes through the same final state and limit checks.

Enforce the decision where the side effect happens

An approval node in an orchestration graph is useful, but it should not be the only route protecting the write. A retry, a second agent or an administrative replay may reach the same connector through another path.

The operation adapter should require the valid approval or standing-policy decision before calling the downstream API. It should verify the target scope, proposal version, expiration and applicable limits. Reject mismatches with a specific reason so the caller can revise the proposal instead of repeatedly retrying it.

Framework behavior also matters. LangGraph documents that an interrupted node restarts from its beginning when resumed, so code before the interrupt can run again. Its guidance recommends idempotent side effects and separating them appropriately. A durable checkpointer and stable thread identifier support resumption, but neither replaces your business authorization checks. LangGraph interrupts.

Design retries around a stable business action key. If the campaign API succeeds but the response times out, the application should inspect the recorded or downstream result before repeating the change. A new random execution key for every attempt defeats that protection.

This does not imply that every API supports exactly-once execution. Where the destination lacks idempotency or reliable lookup, make the uncertainty visible and require reconciliation rather than silently pretending the action failed.

Prevent many small approvals from exceeding one large limit

Per-action limits can conceal aggregate exposure. Suppose an illustrative workflow may add at most USD100 in daily campaign allocation. It proposes eight changes of USD20 each. Every individual action is below the limit, but the combined additional allocation is USD160.

Reserve capacity against the shared allowance before execution. With no existing reservations, only five USD20 increases fit. Concurrent workers must not all read the same remaining USD100 and each claim it independently. The reservation needs an appropriate transaction or equivalent concurrency control in the system that owns the limit.

Record separate states for reserved, executed, released and unresolved capacity. A rejected proposal releases its reservation. A timed-out write with an unknown outcome should keep capacity reserved until reconciliation determines whether the change occurred.

Choose the limit's meaning carefully. An increase in daily allocation is different from actual spend, monthly committed spend or cumulative budget changes. Name the metric and period in the policy. Otherwise, two teams can agree on “USD100 maximum” while enforcing different things.

Batch approvals also need exact scope. Approving fifty specified records does not authorize replacing failed records with fifty new ones. If partial execution is permitted, show which records succeeded and why the others were skipped. Reviewers should not have to reconstruct that from a generic “completed with warnings” message.

Make rejection and expiration useful outcomes

A rejection should preserve the proposal and reason without performing the action. An expired approval should not become an automatic approval because the reviewer is unavailable. Route it back for a fresh decision or stop the task according to the agreed process.

Distinguish an edited proposal from an approved one. A reviewer might correct the amount but still expect to inspect the updated total. Define whether their edit also approves the resulting version, and make that interaction explicit in the interface.

Avoid approval fatigue by improving the proposal quality and policy boundaries. Measure the share of proposals rejected for missing evidence, wrong targets and stale state. Repeated missing-evidence rejections suggest a preparation defect, not a need to remove review.

For example, if forty proposals reach review and twelve lack current campaign status, fix the retrieval step before increasing agent autonomy. Faster approval clicks would only move the same defect closer to production.

What should you test before enabling the workflow?

Use realistic cases from your agent evaluation set, including deliberate attempts to bypass the happy path:

Trace the proposal, review and execution together using agent observability. The operational record should answer who authorized the exact change, what conditions were checked and what the destination confirmed.

Begin with one operation and a small explicit scope. Expand standing permission only when its boundaries, failure handling and review workload are understood. The aim is to let the agent complete useful authorized work while keeping consequential decisions attached to the people and policies responsible for them.