Approval
Keep the approval queue meaningful
The value of approval comes entirely from the possibility of saying no. If that never happens, the queue is friction without a benefit.
- Approvals
- 4 min read
Signals the queue has stopped working
- A request type is approved every time, without anyone reading the input.
- Requests expire unreviewed on a regular basis.
- Nobody can say who is responsible for reviewing.
- The queue is cleared in a batch at the end of the week.
- People describe the queue as “the thing that blocks the agent”.
What to change
Every one of these has the same shape of fix — move the decision to where it belongs:
- Always approved? Move the Ability to allow, after answering the four questions. Record the decision once instead of performing it weekly.
- Always rejected? Move it to block.
- Expiring unreviewed? Either assign an owner, or accept that the control is not being exercised and decide properly.
- Too many requests? Narrow what the agent asks for, or narrow its connection user, so fewer requests reach the queue at all.
What should stay in the queue
The requests where a person genuinely might say no: irreversible actions, public-facing changes, bulk operations, anything touching commerce, and anything whose input varies enough that reviewing it tells you something.
Two requests a week that someone actually reads is a working control. Forty a week that someone clears in a batch is not.
Give it an owner
Approval is accountability, and accountability needs a name. Decide who reviews for each agent, and make sure that person understands the agent’s purpose well enough to notice when a request does not match it.
Approvals
Keep the boundary while you fix the problem.
A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.