When a company first lets an agent act on its systems, the instinct is to put a person in front of everything. Every email the agent drafts, every record it changes, every field it fills must be approved before it takes effect. It feels safe, and for a week it is.
Then the approvals pile up. The person at the gate has forty a day, then eighty. They stop reading the details and start clicking. A year later the company has a human in the loop on paper and a rubber stamp in practice, and an agent whose mistakes pass through a gate that was never really looking.
The fix is not more oversight. It is oversight in the right place.
Attention is a fixed amount. A gate that asks for a decision forty times a day spends it on forty small matters and leaves nothing for the one that mattered. Worse, the approver learns from experience that the answer is nearly always yes, and a person who expects yes reads for confirmation instead of for error.
This is the same mechanism that makes a long terms-of-service page worthless as consent. The gate exists, the click happens and the protection is gone. If the approval rate is close to one hundred percent and the median time per approval is a few seconds, the gate is decoration.
Sort what an agent can do into three classes by how reversible the action is and how far its effect reaches.
Class one: reads and drafts. The agent reads a record, summarizes it, proposes a category, drafts a reply that has not been sent. Nothing outside the agent's workspace has changed. These need no gate. They need a log, so that a person can see afterward what was read and proposed, and a sample review, so that someone looks at a fraction each week and says whether the quality holds.
Class two: writes inside your systems. The agent updates a field, moves a deal to a stage, creates a task, tags a ticket. The change is real and visible to colleagues, but it can be reversed, and the system keeps a history of what it was before. These need an audit trail, a way to undo in one step, and a limit on volume, so that an agent that goes wrong goes wrong ten times and not ten thousand. A gate is usually not needed, and where it is, it should be a batch review of the previous day, not an approval per item.
Class three: anything that cannot be taken back. A message sent to a customer, a payment, a refund, a deletion, a change to a price, a post that goes public, a contract term. The effect leaves your control the moment it happens. These need a gate before the action, every time, with a named approver.
The line between two and three is the one to argue about, and it is worth arguing about once, in writing. We keep our own list short and stable, and we described how it works in our marketing system in why nobody should let an agent near a budget.
A gate on a class-three action earns its place only if the person can decide in under a minute and be right. That depends on four things.
The evidence is on the same screen. The approver sees what the agent proposes, the record it acts on, the reason, and what changes if they say yes. They do not have to open three systems to check.
The default is no. If nobody answers, nothing happens, and the request expires after a stated time rather than waiting forever.
One person decides. Two approvers each assume the other is reading.
The approval is recorded with the evidence it was given. Later, anyone can see what the approver saw.
A gate with these properties asks for few decisions, and each one is a real decision.
Measure two numbers per gate each month: the share of requests approved, and the median time to approve. A gate that approves ninety-nine percent in under ten seconds is not reviewing. It does not mean the agent is perfect. It means the gate is in the wrong place or asks about the wrong thing.
The remedy is almost never to add a second approver. Move the gate to the real class-three step, shrink the number of requests, and put the detail the approver needs where they can see it. If the rate then drops to a more plausible figure, perhaps one request in ten refused or sent back, the gate is working.
Imagine an agent that handles customer refund requests for a company of 120 people. In the first design every action needs approval: reading the order, drafting the reply, issuing the refund, closing the ticket. The support lead approves about sixty items a day and, after a month, approves all but two a week, each in a few seconds.
In the redesign, reading and drafting are class one and run freely, with a weekly sample of ten drafts read by the lead. Updating the ticket and the order note are class two, logged and undoable. Only the refund itself and the message to the customer are class three. The lead now sees about fifteen requests a day, each with the order, the policy line the agent relied on and the amount, and refuses or amends about one in eight.
The number of decisions fell by three quarters, and the number of mistakes caught went up, because the lead is reading again.
An action can move from class three toward class two as evidence builds. A refund under a small limit, issued for a reason on a short approved list, may become an action the agent takes alone after months of clean approvals. The move should be a decision someone signs, with the evidence attached, and it should come with a ceiling that keeps the exposure small.
The reverse move needs no ceremony. A single incident that reaches a customer, or an approval rate that suddenly falls, sends the action back behind its gate until someone understands why. Loosening is slow and deliberate. Tightening is immediate. That asymmetry is what lets the business trust the loosening.
List everything an agent in your business can do on one page, and mark each action one, two or three. Count how many of your current approvals sit on class one and two. Those are the ones to remove or turn into a sample, and removing them is what makes the remaining gates mean something. If you are not yet running agents, write the list before you do, because the design is easier than the repair. Our wider argument for deciding this before the agent is built is in what yours can reach, and who decided.
We design the gates with you during a no-risk discovery: we map the actions your agents could take, sort them into the three classes and show where the approvals belong, and you pay for the discovery only if you go on. A build comes with a guaranteed estimate, so if we estimate low, we absorb the difference. After go-live, Managed Technical Operations reads the approval rate and the time to approve each month and tells you when a gate has drifted.
A human in the loop is only a safeguard if the human is still reading.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
