When should an AI agent ask for approval? A framework for B2B SaaS

For a B2B product, that decision shapes the workflow more than the chat box does. It determines what the agent is allowed to do, what a person must decide, what evidence is shown at the moment of decision and what happens when the system cannot proceed.

Start with the consequence, not the model

Do not set approval rules by asking whether the model is ‘confident’. A confidence score can be useful signal, but it is not a product policy. Start with the consequence if the action is wrong, premature or applied to the wrong record. Then consider whether it can be undone, who is affected and whether the user has enough context to take responsibility for it.

This is consistent with the NIST AI RMF Playbook’s guidance on human oversight, which recommends defining the context of use and human roles, documenting oversight requirements and testing them in scenarios similar to deployment. The Playbook is voluntary guidance, not a substitute for your legal, security or sector-specific obligations.

Use four levels of agent authority

Assign an authority level to each action, not to the entire agent. One assistant may safely organise a queue without approval, draft a reply for review, and require a manager’s approval before changing an account. The table is a starting point for agreeing those boundaries with product, engineering, security and the people who do the work.

Level 4 does not mean ‘fully autonomous’. It means the team has explicitly delegated a narrow action under known conditions. If the agent encounters a new condition, exceeds a limit or cannot validate required data, it should stop or move the action back to Level 3.

Put approval at the side-effect boundary

The important boundary is where the product changes the world: a message is sent, a payment is issued, access changes, data is deleted, a record is updated or a request is made in another system. An agent can investigate, summarise and prepare up to that point without pretending that preparation is execution.

OpenAI’s guide to guardrails and human review describes this pattern for tool calls: a run can pause until a person approves or rejects a sensitive action. The product-design implication is broader than any one SDK. The review screen should show the proposed side effect before it happens, rather than asking people to approve a vague instruction such as ‘continue’.

• Require approval for irreversible actions, or actions whose reversal causes more work than the action itself.
• Require approval when the action creates an external commitment, such as a customer message, contract change, refund or regulatory submission.
• Require approval when a person’s access, eligibility, account standing or personal data is affected.
• Require approval when the agent has to infer an important fact, resolve an ambiguity or choose between plausible policies.
• Consider automatic execution only when the action is bounded, observable, reversible where practical and has a clear owner for exceptions.

Make the review step worth using

An approval gate is weak if the reviewer has to reconstruct the decision from a chat transcript. A usable review step gives them the information needed to check the action quickly, and the controls needed to change course without starting over.

Proposed action

State the verb, object and scope in plain language: ‘Send this renewal notice to 18 customers’, not ‘Run workflow’.

Reason and inputs

Show the policy, source records and key assumptions that led to the proposal. Link to the records rather than claiming the agent is correct.

Affected people and systems

Name the recipients, accounts, permissions, integrations or queues that will change.

Material uncertainty

Surface missing fields, conflicting information, a low-quality source or an ambiguous instruction where it would change the decision.

Controls

Offer Approve, Edit, Reject and Escalate where each is meaningful. A reviewer should be able to fix a small issue without re-running the whole task.

Afterward

Confirm what happened, preserve a history of the decision and give a correction or undo path when the action allows one.

NIST’s Measure guidance specifically suggests maintaining histories and audit logs, documenting the degree of human oversight and tracking outcomes such as overrides, reported errors and escalations. Use that as a prompt to decide what your own product needs to retain, subject to its privacy and retention requirements.

Worked example: an agent preparing subscription changes

Imagine an operations platform where account managers request subscription changes. An agent reads the request, finds the account, checks the current plan and prepares the change. The team should not decide ‘the agent can manage subscriptions’ in the abstract. It should assign authority to each step.

The approval panel for the downgrade could show the account, current and proposed plan, effective date, calculated credit, source request, any missing information and the downstream systems that will update. The manager can approve, adjust the date, reject it with a reason or escalate an exception. If the billing API times out after approval, the product reports ‘not applied yet’ rather than implying success, and gives the manager a safe retry path.

Design the states around the approval, not just the happy path

The most important moments often happen when the agent cannot complete a proposal cleanly. Treat these as product states, with ownership and next steps, rather than as model errors hidden in a log.

• Needs information: say which field or source is missing and who can provide it. Do not ask for approval on an action the reviewer cannot assess.
• Ambiguous match: show the plausible records and require a person to choose. Never silently choose the first close match for a consequential action.
• Policy conflict: explain which rule blocked the action and provide an escalation path, rather than encouraging people to work around it in a prompt.
• Approval expired or changed: refresh the proposal when the underlying record or price has changed. A stale approval should not apply a different action from the one reviewed.
• Execution failed: distinguish ‘not attempted’, ‘attempted but not confirmed’ and ‘completed’. Offer retry only when it will not create a duplicate action.
• Limit reached: state the relevant boundary, such as a maximum amount, number of recipients or permitted system, and route the exception to an accountable person.

A brief you can copy before you build

Use this to align product, engineering, security and operations before designing the interface. It will not replace implementation controls, but it exposes the decisions the workflow needs to make.

Workflow: [name the end-to-end task]

User and accountable owner
- User who asks for the work: [role]
- Person accountable for approval or exceptions: [role]

Proposed action
- What can the agent recommend, prepare or execute?
- Which systems, records and people can be affected?

Authority level
- Recommend / Prepare / Request approval / Execute within a boundary
- Why is this level appropriate for the consequence and reversibility?

Approval rule
- Which exact side effect needs approval?
- What change makes a prior approval stale?
- Who may approve, edit, reject or escalate it?

Reviewer context
- Source records and policy used:
- Assumptions or uncertainty to show:
- Expected downstream changes:

Boundaries and fallback
- Limits: [amount, count, role, system, time]
- What makes the agent stop or escalate?
- What can be undone, and how?

Evidence after action
- What will be logged?
- How will overrides, failures and complaints be reviewed?

Test authority rules in realistic workflows

Do not validate this only by checking whether the model returns an acceptable answer. Test whether people can identify what will happen, recognise when information is missing, correct a proposed action and recover from a failure. Include old or conflicting records, permission differences, partial success, stale approvals and integration timeouts. A focused SaaS UX audit can help identify where a review flow makes a task harder to understand, while a scoped workflow brief can turn the findings into buildable states and dependencies.

Approval is not a way to transfer every risk to a user. It is one control in a workflow with defined roles, clear boundaries, technical enforcement, monitoring and a way to learn from exceptions. When it is designed well, the agent moves routine work forward while people retain control over decisions that deserve judgement.