The first AI assistants answered questions. Agents now take actions: they update records, send reminders, create purchase requests, reschedule deliveries and propose credits. That changes the governance question. It is no longer only whether an answer is right, but whether something should happen at all. An agent that drafts a reminder is helpful; one that sends it to the wrong customer is an incident.

Requiring approval for everything makes an agent slow and turns approvers into rubber stamps. Requiring approval for nothing makes it a risk nobody signed up for. The answer is a deliberate design: which actions an agent takes alone, which need a person, and how that line moves as the agent proves itself.

Sort actions by consequence, not by technology

Classify each action by what happens if it is wrong: whether it can be undone, who is affected, how much money is involved and whether it leaves the organization. Three tiers cover most cases.

  • Act alone. Reversible, internal and low in value: drafting, tagging, filing, updating a status, creating a task. The agent acts and logs it, and a sample is reviewed.
  • Act with approval. Anything that reaches customers or suppliers, moves money or changes a record others rely on: an external message, a changed order, a credit note. The agent prepares; a person decides.
  • Recommend only. Irreversible or high-stakes actions: payments, contract terms, employee matters, regulated decisions. The agent assembles the case; a person acts in the system of record.

Write the tiers down for each action, with the limits that apply, and have the business owner sign them. Enforce the limits in the agent’s permissions and in the systems it uses, not only in its instructions. Keep approval separate from configuration: the people who approve an agent’s actions should not be the ones who can change its limits.

Start conservatively. When an agent is new, place more actions in the approval tier than seems necessary. Moving an action to a lighter tier later is easy; recovering from an early mistake in front of customers is not.

Make approval requests easy to decide

An approval request is a short decision brief, not a notification. It states what the agent proposes and why, with the evidence and the source of each figure; the impact in money, customers or dates; and the rule that requires a person to decide. It also says what the agent is unsure of.

Deliver it where the approver already works, in Teams, email or the business application, with one action each to approve, edit or reject. If approvers have to open several systems to check the facts, they will either approve without looking or not decide at all. Group small, similar requests so they can be reviewed together, and never ask anyone to approve what they cannot reasonably check.

Exhibit: an approval request from a billing agent, with the proposal, the evidence and the rule that calls for a decision.

Plan for silence: escalation and timeouts

Approvers take vacations, and requests arrive late in the day. Every approval needs a time limit and a default. For most actions the safe default is to do nothing and escalate to a deputy or the next level. For time-critical actions, such as protecting a delivery promised to a customer, the escalation path must be faster and named in advance. Escalations should reach a person with the authority to decide, not a shared mailbox.

Never let a timeout become an approval. Watch the approval queue as an operational measure, too: requests that wait too long, or that are approved in seconds without being opened, are signs that the design needs adjusting.

Keep an audit trail that answers every question

For each action, record what the agent saw, what it proposed, who approved or changed it, when, and what happened next. Record the agent’s instructions and permissions at the time, because both change. The trail should let anyone explain, months later, why a credit note was issued or a delivery moved, without reconstructing events from chat messages. Every week, review a sample of the actions the agent took alone, and treat a wrong action like any other incident: find the cause, fix it and record what changed.

Give each agent its own identity with the least access it needs, so that its actions can be told apart from people’s in every log and its permissions can be reviewed like anyone else’s.

Earn autonomy with evidence

The audit trail is also how an agent earns more responsibility. For each type of action, track how often requests are approved without changes, how often they are edited and why, and what went wrong after approval. When an action type is approved unchanged, consistently and over a meaningful period, its owner can move it to the act-alone tier, with sampling to keep watch. Move one action type at a time, tell the people affected, and keep the approval step for exceptions above the agreed limits.

Autonomy can move both ways. If edits or errors rise, for example after a policy change or a new data source, the action returns to approval until its record improves. Leaders do not have to trust the agent on faith; they can read the record.

Exhibit: approval requests accepted without changes, by type of action, against the bar for removing the approval step.

The bottom line

Approval steps are not a brake on AI agents; they are how agents earn the right to do more. Sort actions by consequence, make each request a decision a person can take quickly, plan for silence and keep the record. Agents designed this way take on more work over time, and leaders can show why that is safe.