Guardrails and human-in-the-loop approval, 8 of 26
It stops before it
publishes anything.
Eight of the twenty-six agent posts ask how you keep an agent from doing something it should not. A gate that refuses is already running on the tool loop, where invented tools, duplicate writes and loops get turned down.
Refusing only works when you know in advance what is wrong. Usually you just know the action is public, or expensive, or hard to undo. Press the button. The agent tries to publish a note, and you get the note instead.
Reading the queue...
Four decisions
The run finishes. It does not sit there waiting.
The obvious build blocks the agent until somebody answers, and that agent times out at three in the morning holding the only copy of what it meant to do. So the tool returns straight away with the id it parked under, and the run ends normally. Approval happens later, on its own clock, against a record.
The intention goes in a row before anything comes back
Held in memory, an approval queue empties itself on every deploy, and "awaiting approval" quietly becomes "dropped". The tool name, the arguments and the reason it needs a person all go in a row before the tool returns anything to the model.
It expires, and expiry is computed when you read it
A queue with no expiry becomes a list nobody opens, and an item approved three weeks late runs against a world that moved on. The window is an hour. Nothing sweeps the table, because a row whose state depends on a background job that may not have run can be approved after it should have lapsed. The read decides.
Two people press approve, and the write runs once
Two people open the queue and both press approve. The second one is told what already happened instead of running the write again. A write that fails after approval stays approved with the failure recorded, rather than returning to the queue where somebody would approve it a second time.
What this page does not do
Anybody can approve here. There is no login, and the thing being approved is a note nobody minds about. In a real system this endpoint carries identity and the queue is scoped to the people allowed to decide, which is a session and a role check, not a redesign.
Saying that is more useful than putting a password box on a demo and implying the hard part is solved.
The endpoint returns the same queue as JSON. The tool loop is where the refusing gate lives. The whole list is 41 requirements from 114 job posts, with the gaps at the same size as the wins.