Approvals that keep up with your agents

Picture a bank running an agent pilot on trade-finance paperwork. The agents are good. They read the documents, resolve who the counterparties are, run the sanctions checks and put together draft evidence packs faster than any associate team could. Every draft then goes into a shared queue for three senior analysts. Two weeks in, the queue holds four hundred items and it’s growing by the hour.

That’s a composite, but the shape is real, and it turns up in most kinds of agent work, software included. The analysts weren’t slow. The agents had succeeded, and success turned the people into the bottleneck. You build a production line that runs at machine speed, wire it to an approval step designed for a human-paced process, and you end up with a very expensive inbox.

The opposite mistake is just as easy. Take the approvals out, let agents move money or change records or ship code unchecked, and wait for the first serious error. Your risk function will close the programme, and in high-risk areas the EU AI Act expects meaningful human oversight anyway (Article 14). “We watched the logs” won’t satisfy anyone.

So the interesting design space sits in between. I think most teams get there by asking the wrong question.

Where to put people

“Where should we add a human?” leads to approvals scattered everywhere out of anxiety. A better question is: when does a wrong automated decision cost more than the delay of having a person look at it?

That’s partly a risk judgement. A miscategorised internal transaction that’s easy to reverse is cheap to fix. A payment to a sanctioned party isn’t. A typo fix in documentation is not the same as a change to how a service handles authentication. Approval should follow consequence.

It’s also arithmetic, which people skip surprisingly often. If a reviewer takes twenty minutes per item and your agents raise fifty items an hour, you need a thousand reviewer-minutes every hour. That number is either absurd, which tells you approvals trigger far too often, or achievable, which tells you you’re roughly calibrated. Hoping for the best is how you end up with four hundred items in a queue.

And the approval only makes sense inside firm limits on what agents can touch in the first place. If agents can only read and change what they’re meant to, the approval is the last check on a system that’s already constrained. Without those limits, the approval is carrying the whole weight of safety, and it will buckle.

In practice I’d expect the large majority of agent work to need no individual approval at all. It’s recorded, it can be reviewed afterwards, and some patterns get looked at in aggregate. A small share of genuinely risky or ambiguous decisions goes to a named person. A tiny share goes to two people. If a large slice of your volume is landing on someone’s desk, the limits are too loose or the thresholds are wrong.

The real bottleneck is context

What surprised me when I first looked at stuck approval queues is how little of the reviewers’ time goes on deciding. Most of it goes on reconstructing.

Watch someone clear an approval queue and you’ll see them open the item, then go and find the background in another system, then work out what the agent actually did, then check the rule it was applying. Five or ten minutes of archaeology, then a few seconds of judgement. By late morning they’ve cleared eight items and a hundred more have arrived.

So aim for a faster decision rather than a shorter list. When an item reaches a person it should already carry what they need. What’s being proposed. The evidence behind it. The rule it falls under. What happens if they approve and what happens if they don’t. The full detail should be there if they want it, but they shouldn’t need it to make a standard call. For a software change that might mean the diff, what checked it and how, what it touches, and why it was flagged for a human.

Assembling that context is cheap for the system and expensive for a person. Move it to the system.

It also helps to route to a named person rather than a pool. A pool hands work to whoever’s free, which sounds efficient and destroys familiarity. Someone who regularly reviews the same kind of change gets quick at spotting what’s off. You still need a named backup for when they’re away, written down in advance rather than improvised.

Every decision is a signal

Each approval, rejection or edit tells you something. The agent proposed this. The person agreed, refused, or changed it, and ideally said why.

The cheap use of that is tuning. If a category of decision is approved untouched almost every time and nothing goes wrong afterwards, it probably doesn’t need a person any more. You can move it down a level, carefully, and give the reviewer’s attention back to things that need it. If the same kind of edit keeps happening in the same direction, that usually points to an ambiguous rule or an agent that has learned something slightly wrong. Both are worth fixing at the source.

None of this works unless the decision is recorded in the same place as the agent’s work. If the approval lives in a chat tool and the agent’s actions live somewhere else, you’ll have two accounts that disagree at the worst moment. The person’s decision, their reason and what they saw should sit in the same record as everything else.

The numbers worth watching

Three, tracked over time and broken down by type of decision.

How often reviewers approve without changes. Too low suggests the agents aren’t good enough or you’re escalating things that don’t need it. Close to everything suggests the approval is adding friction without adding safety. Edits are especially telling, separate from rejections.

How long decisions take, against what you said they’d take. Track it per reviewer as well as overall. A consistent outlier often means the context they’re given doesn’t suit their area.

How often approved items later need fixing. This is the honest measure. An approval with a high pass rate and a high downstream error rate is a rubber stamp.

The aim is a policy that gets sharper as the agents improve, adjusted on purpose from evidence rather than in a panic after an incident.

Trying it

You don’t need to bet a programme on this. Pick one workflow where reviewing every item is already painful and individual errors matter without being catastrophic. Start with cautious thresholds, so more goes to people than strictly needs to. Measure those three numbers from the first day. After a month, look at where thresholds can safely move. By three months you should have a calibrated policy for that workflow and evidence for whether to extend it.

This is one of the things we’re building into Kizuna, where AI agents build software under your rules: people approve the changes that matter, with the context in front of them, and the decision lands in the same record as the agent’s work. We’re in development, but the principles above don’t depend on any particular tool.

If you’re wrestling with approval queues of your own, we’d like to hear from you. For what the record should look like from a regulator’s side, see EU AI Act Article 12: what to keep when AI agents change your systems.