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.