Approval fatigue: keeping a human in the loop without a queue nobody reads
Approval fatigue is what happens when people are asked to approve so much that they stop reading and click yes, and human in the loop, a person’s yes before an agent acts, becomes a rubber stamp. The answer isn’t fewer checks. It’s the right check for each action: reading data waits for no one, a rule you can write down goes in code, and a person’s attention is kept for the calls that need judgment. Gate on what the action can do, not on how sure the model says it is, and show the reviewer exactly what the call would change.
Why does human in the loop turn into a rubber stamp?
Because most of what reaches the queue never needed a person. When reviewers see lookups and routine updates all day, they learn that the answer is always yes, and the one risky call gets the same quick look as the rest. The next step is worse: someone turns the checks off to get work done. A queue nobody reads gives you the delay of a review without the review.
People skip checking AI’s work well beyond approvals. A 2025 study of more than 48,000 people in 47 countries, led by the University of Melbourne with KPMG, found that at work, 66% “rely on AI output without evaluating accuracy”.
Which agent actions should wait for a person?
The ones that change something hard to take back, where the right answer takes judgment. Sort what an agent can do into three groups:
- Reads. A lookup, a search, a calculation. They change nothing, so they run without asking.
- Rules you can write down. “Refunds up to $100 are fine” is a rule, not a judgment, so it belongs in code. The everyday refund tool caps the amount itself, and a bigger refund goes through a separate tool that always waits for a person. When approvals are set per tool, two tools are the simplest way to express a limit.
- Judgment. An update on the public status page, a goodwill exception, a reply to an angry customer. This is what a reviewer’s attention is for.
For example: say that on a busy day, Acme’s order-desk agent looks up 150 orders, makes 40 small refunds and is asked for 3 refunds over $100. If every action waits, the support lead approves 193 times and stops reading. Sorted this way, the lookups and small refunds run on their own, and the support lead sees the 3 that need a decision.
If judgment calls are only a small part of your queue, the rest is work a rule or the code should take over. We answered a shorter version of this question in Questions our customers ask.
Should the model’s confidence decide what gets approved?
No. Gate on the action’s risk, not on the model’s own score of how sure it is. A model can be confidently wrong, and its confidence is a claim about itself, not a check. A $5,000 refund is as risky when the model says it’s 99% sure. The risk belongs to the action, so the check belongs there too. More on why a model’s answers vary in AI agents give different answers each time.
Does it matter who started the run?
Yes. The same refund can be routine when a staff member asks for it in a chat, and risky when an incoming webhook sets it off with no one watching. A run no person started is a good reason to ask first, even for a tool that runs freely when someone is there.
What should the reviewer see?
Exactly what the agent’s call would do: which tool, with which arguments, for which customer, from which run. Not a summary the model wrote about itself. “Approve refund?” invites a rubber stamp. “Refund $480 on order 1042 for Acme” invites a decision. The decision belongs on record too: who said yes or no, when, and why.
Can a person review an agent’s action after it runs instead?
Only if the action can be undone. An email sent, money paid out or a post published stays done, whatever a reviewer decides later. For those, the yes goes before the call. Looking back afterwards is still worth doing, but it’s an audit, not a check.
Where Kindgi fits
Kindgi is an agent framework for production: your coding agent writes the tools, agents and flows in your own code, and Kindgi runs them and keeps every step on record. You choose which tools wait for a person, tool by tool. A tool marked read-only runs without asking. The approval names the tool and the exact arguments the model chose, and the reviewer approves, rejects, or escalates it to a more senior reviewer. Who decided, and why, stays on the run’s record. A tool that moves money can say it needs a person’s yes whenever no person started the run, so the refund a staff member asks for in chat runs, and the one a webhook asks for waits. Company-wide rules can make a tool always ask, for every agent, and they can only make an agent stricter.
The guides: ask before a tool runs, mark a tool read-only, decide an approval and set approval rules for every agent.
How this was written: a coding agent drafted it from our docs and our code. We checked every claim, edited it and said yes. We publish articles like this partly because we want you to find us, including through AI assistants. More in How we write our posts.