When there is nobody there

When there is nobody there

Plenty of agents run without a human in front of them. Overnight batches, queue consumers, scheduled jobs. The approval step has no one to ask, and this is where otherwise careful designs quietly fail.

The tempting answers are both bad. Approving automatically outside working hours deletes the control at precisely the times an attacker would choose. Blocking until morning turns a security mechanism into a queue that someone will eventually be asked to clear in bulk, which is approval fatigue with a worse interface.

The workable answer is to change what the agent is allowed to attempt rather than who approves it.

An unattended agent gets a narrower capability set: the irreversible operations are simply not in it. Chapter 8's issuer already takes the task as input, so it can take the context too. The overnight job can read, classify, draft and stage. It cannot send, refund or delete. Work that needs those operations is prepared and left for a person, as work rather than as an alert.

This is better than it sounds, because a queue of drafted actions reviewed as a batch in the morning is a task someone can do attentively, while a queue of approval dialogs is a task they will clear without reading. Same items, different framing, very different outcome.

Where an unattended agent genuinely must perform an irreversible action, the honest options are a second independent system verifying the precondition, or a tightly bounded allowance with a hard cap. Not a human who is asleep.

Who should be asked

The reviewer has to be someone who can actually tell.

A support agent can answer whether a refund amount taken from a customer document should be trusted, because they know what an invoice looks like and what the customer claimed. They cannot answer whether a Kubernetes manifest the agent generated is safe to apply, and asking them produces a rubber stamp with extra steps.

Route by who has the context, not by who has the permission. Those are different people more often than org charts suggest, and where no available reviewer has the context, the approval step is theatre and the action should not be available to the agent at all.

Budgeting attention

Treat reviewer attention as a finite resource with a number attached, because it is.

Pick a target: no reviewer sees more than a handful of prompts per shift. Then measure. If the real rate is ten times that, the answer is not training the reviewers. It is that too many actions are marked irreversible, or the agent is attempting things it should not be attempting, and both are fixable in the design.

A rising approval rate is a leading indicator that something has drifted. A team that watches it catches a misconfigured capability weeks before an incident. A team that does not watch it learns about the drift from the incident.

What this costs

Someone's attention, which is the scarcest budget in this book and the one nobody accounts for.

It also costs latency at exactly the moment the user is waiting, and it puts a human in the path of a system sold on autonomy. That tension is real and the resolution is to make the prompts rare enough that they read as significant rather than as friction.

The failure to design against is the one where an engineer under deadline widens the approval policy to unblock a release. It is a one-line change, it is never reviewed as a security change, and it silently removes the only control standing in front of your irreversible actions.

Chapter 15 makes all of this testable.

Sources for this chapter

The argument that irreversibility rather than write semantics is the correct axis for approval is the author's, and it is an explicit disagreement with the common guidance cited above. The claim that an approval step which is rubber-stamped is worse than no approval step is an argument, not a measured finding. The reviewer-attention budget, the ApprovalRequest shape and the advice to expire requests in minutes are the author's. The two GitHub issues were open at the time of drafting and should be re-checked before publication; their status does not affect the argument, since the chapter cites them as an illustration of how easily the failure mode occurs rather than as a defect claim against the framework.