Approval Is a Product Feature

Part 4 of my series on AI in production. Part 3 borrowed idempotency, audit trails and reconciliation from payments to make agents safe to leave running. This part is about the people who still need to be in the loop.

Most teams add human approval to an agent the same way: as a safety net, bolted on at the end. Every action waits for someone to click "approve."

It feels responsible. In practice, it fails in one of two ways.

In the first, approvals pile up. The agent drafts follow-ups in seconds, and they sit in a queue for a day because the account manager is in meetings. The agent is fast; the workflow is as slow as before.

In the second, people approve without reading. When someone sees forty requests a day and the first thirty-nine were fine, the fortieth gets the same click. The approval step still exists on the process diagram, but it has stopped protecting anything.

Payments solved a version of this long ago. Card networks don't ask every customer to confirm every purchase with an extra step. Most payments go through without friction; only the risky ones trigger step-up authentication. The checks are placed where the risk is, so customers aren't trained to ignore them.

Agents need the same thinking. Approval isn't a safety net you add at the end. It's a product feature you design: where it appears, what it shows, who it goes to, and when it's no longer needed.

Decide approval per action, not per agent

"Does this agent need human approval?" is the wrong question. An agent does many different things, and they don't carry the same risk. Logging call notes and emailing a customer a discount are not the same decision.

I ask two questions about each action the agent can take: how bad is it if this is wrong, and how hard is it to undo?

Only the top-right corner needs a person to say yes before anything happens. Everything else can run, with a different kind of human attention: a quick review after the fact, a notification to the owner, or a daily check that what the agent did matches what actually happened.

The same action can sit in different corners for different customers. A follow-up email to a long-standing account might be routine; the same email to a prospect in a live negotiation is not. Let the rules take that context into account rather than drawing one line for everyone.

Where humans actually belong

Once you sort actions by risk, a pattern appears. People add the most value at a few specific points in a workflow, and almost none in between.

• Before anything reaches a customer. Emails, proposals, quotes and messages carry the company's name. A person should own what is said.
• Before money or commitments move. Refunds, discounts, credits, contract terms and anything a customer could later hold you to.
• When the agent is unsure. Low confidence, conflicting sources, or a request that doesn't match anything it has seen before. The agent should know when to ask, and say why it's asking.
• When the situation is new. A first-time customer type, a new product line, an unusual request. Novel cases are where agents fail in ways nobody predicted.
• At the plan, not every step. For multi-step work, a person approving the plan once ("draft follow-ups for these twelve accounts using this message") is worth more than approving twelve separate emails.

And there are places humans don't belong: confirming routine, reversible steps that have been right hundreds of times. Every unnecessary approval spends the attention you need for the ones that matter.

Design the approval moment itself

A bare "Approve / Reject" button asks the reviewer to redo the agent's work in their head. That's slow, so they either take too long or don't do it at all. A good approval screen makes the right decision fast.

• Show what will change. The exact email, the field before and after, the amount. Never a summary of the action instead of the action.
• Show why. The sources the agent used, the customer context it relied on, and the rule it applied, each one a click away.
• Flag what's unusual. Highlight the one part that differs from the usual pattern: a discount above the normal range, a recipient outside the account, a claim with no source. That's where attention should go.
• Make editing as easy as approving. Often the right answer is "yes, but change this line." If editing means rejecting and starting again, people will approve things they should have fixed.
• Decide what happens on silence. If nobody responds within an agreed time, does the action expire, escalate, or go ahead? Choose deliberately; for anything in the approve-first corner, it should never go ahead by default.

This is ordinary product design: understand the reviewer's job and remove the friction from it. It's also the part most agent projects skip.

Keep approval from becoming the bottleneck

Even with good design, approvals slow things down if nobody manages them as a flow. A few habits help:

• Route to the person who can decide. The account owner for a follow-up, finance for a credit above a limit. A shared queue that "someone" watches is a queue nobody watches.
• Batch similar decisions. Twenty routine follow-ups reviewed together, side by side, take far less time than twenty interruptions.
• Set rules people can approve once. "Discounts up to 5% on renewals are fine" is a policy, not a decision. Approving the policy removes hundreds of individual approvals.
• Measure the queue. Track time waiting for approval, approvals per person per day, and how often people edit or reject. These numbers show where the process is stuck.
• Watch for rubber-stamping. Approvals made in a second or two, on every item, mean the step has stopped working. Either the action is safe enough to automate, or the screen isn't showing what matters.

The most important habit is to let autonomy be earned. Every action type starts with more oversight than it will eventually need. When a type of action has been approved without edits many times in a row, and the daily checks find no problems, move it to a lighter form of oversight: from approve-first to review-after, or from review-after to automatic. If problems reappear, move it back. Autonomy becomes something the agent earns with evidence, not a setting someone guessed on launch day.

Every approval is an eval label

In part 2, I argued that evals are a product job. The hardest part of that job is knowing what "good" looks like, and approvals answer that question every day, for free.

Each time someone approves, edits or rejects an agent's action, they are labelling an output. An approval without changes says this was good. A rejection says this was wrong. An edit is the most valuable of all: it shows exactly what good looked like, side by side with what the agent produced.

So store them properly. Keep the agent's version, the final version, who decided and why, and link them to the run's audit trail. Review the edits every week. Recurring corrections point to a missing rule, an outdated document or a gap in the prompt. The clearest ones join the eval set, so the next version of the agent is tested against the mistakes people actually caught.

Designed this way, approval stops being a cost you pay for safety. It becomes the feedback loop that makes the agent better, and the evidence that tells you when it no longer needs to ask.

Governance: someone has to own the rules

The chart, the approval rules and the decisions to grant more autonomy are policies. If nobody owns them, they drift: an engineer widens a limit to unblock a demo, a rule written for one market quietly applies to all of them, and six months later nobody can say why the agent is allowed to do what it does.

Treat approval policies like any other part of the product that carries risk:

• Give each action type an owner. Sales operations owns follow-up rules, finance owns discounts and credits, compliance owns anything regulated. The owner decides which corner an action sits in and signs off on any move.
• Version every change. Limits, thresholds and auto-approval rules live in configuration with a history of who changed what, when and why, reviewed before release like code.
• Review on a schedule. A monthly look at approval rates, edits, incidents and requests for more autonomy, with the owners in the room.
• Keep an off switch. Any owner can move an action back to approve-first, or pause the agent entirely, without waiting for a release.

In regulated work, this is what an auditor will ask to see. Everywhere else, it's what lets you answer "who decided the agent could do that?" in one sentence.

Agree the rules before you build

The fastest way to align sales, finance, legal and engineering on an agent is to put them in one room with the chart and a list of every action the agent will take. Ask them to place each action together.

The disagreements come out quickly. Sales wants follow-ups sent automatically; legal wants to read every one that mentions pricing. That conversation is far cheaper before launch than after an incident. Usually it ends in a split both sides accept: routine follow-ups go out after a quick review, anything that mentions pricing or contract terms waits for approval.

Write the result down, name the owners, and agree what evidence would justify moving an action to a lighter level of oversight. Then the approval data does the rest. When an owner asks for more autonomy, or less, the decision is based on what reviewers actually approved and corrected, not on who argues hardest.

The goal is fewer approvals, not more

It's tempting to measure an agent's safety by how many approval steps it has. I think that's the wrong measure. An agent with approvals everywhere is either slow or quietly unsafe, because people stop reading.

The better measure is whether each approval that remains is one a person genuinely needs to make, and whether they have what they need to make it well. Put people where the risk is, give them a screen that makes the decision easy, learn from every choice they make, and let the agent earn its way out of the queue.

That's not a safety feature added at the end. It's the product.

Next in the series: choosing what to build. How to pick the AI use cases worth funding, and say no to the rest.