Approval fatigue is a workflow design problem

Approval fatigue is usually blamed on the reviewer. They were distracted. They stopped reading. They approved something they should have challenged.

That diagnosis is convenient and mostly wrong. If a workflow asks a person to approve routine, low-consequence steps all day, it is teaching them that the approval button is part of operating the agent. The same button later appears for a production migration or a public message, but the reviewer has already learned the gesture: click so the work can continue.

The problem is not that people need more discipline. The workflow has failed to separate ordinary execution from consequential judgment.

An approval is not a remote-control button

Imagine a coding agent that asks before reading a log, installing an existing dependency, running a test, formatting a file, and opening a pull request. Each request is technically honest. Together they make the person act as a slow subprocess scheduler.

Then the agent asks to change an authorization rule. That request deserves a different kind of attention, but it arrives in the same shape as the formatting request. The interface has flattened unlike risks into identical prompts.

A useful approval should mark a boundary. It should tell the reviewer why this step needs authority the agent does not have. It should also contain enough context to make a decision without reconstructing the whole run.

“Allow command?” is not enough. A decision-ready request explains:

• what will change and what will remain untouched;
• which evidence supports the change;
• who or what could be affected;
• whether the action can be reversed, and how;
• what the agent will do if approval is denied or expires.

If the workflow cannot provide that information, it is asking for permission, not informed approval.

Reduce approvals without hiding risk

The answer is not to make the agent autonomous everywhere. It is to spend human attention where judgment changes the outcome.

Start by classifying actions according to consequence and reversibility. Reading a repository and running a protected test suite may be allowed within a bounded workspace. Editing files can remain private until the proposed patch is ready for review. Deploying, spending money, changing identity or access, and sending external communication can retain stronger gates.

The exact boundary depends on the system. A healthcare workflow and an internal prototype should not share an approval policy. What matters is that the policy is explicit and tied to risk, rather than inherited from whichever tool happens to be called.

Batching can help, but only when the grouped actions belong to one coherent decision. Approving “apply this patch, run these checks, and open a draft pull request” may be reasonable because the work stays reviewable. Bundling a data migration with an unrelated public announcement saves clicks by concealing two different consequences. That is worse than fatigue.

Good workflows also remember bounded decisions. If a reviewer has approved a specific test command for a named repository and branch, the agent should not ask again five minutes later unless the scope changed. Approval should not silently become permanent access, but it should survive long enough to complete the decision that was actually made.

Some friction is doing real work

There are cases where repeated approval is appropriate. A regulated process may require a fresh signer at each controlled transition. An incident responder may want every destructive command held while the system is unstable. A novel task may be too poorly understood for a broad permission grant.

Keep that friction. Make its purpose visible. A reviewer is more likely to pay attention when the request says which policy requires the approval and what evidence will be recorded.

The test is not whether the workflow has fewer prompts. The test is whether a person can still recognize the prompt that needs thought.

Fix one approval queue

Review the last twenty approval requests from one recurring agent workflow. For each request, write down the consequence, reversibility, and information the reviewer received. Remove repeated prompts for bounded low-risk actions. Split requests that hide separate decisions. Rewrite the remaining prompts as small decision packets with evidence and an undo path.

Then watch the next run. If the reviewer still has to reconstruct context or approve the same boundary twice, the workflow is not finished.