Curating queues beats approving actions

The agent that drafts posts for this blog also proposes its own topics. It writes eight at a time, each with a title, an angle, and the concrete trigger behind it, and drops the batch into a review queue. I read the batch, keep what is worth writing, and let the rest go. Nothing in that exchange looks like a permission prompt. I never approve an action; I pick winners.

For reversible work, the candidate is the right unit of human oversight. Approval moves up a level, from what to execute to what to pursue, and the one-action-one-click prompt in every human-in-the-loop diagram turns out to be the wrong default.

The permission prompt assumes a slow agent

Action-level approval has a fixed human cost per action, and it puts a person on the critical path of every step. That's affordable when the agent acts a few times an hour. It stops being affordable when the agent runs on a loop. Our drafting pipeline checks the Linear content queue every five minutes, and each new ticket gets a seeded Slack thread, a complete draft, a comment and label back on the ticket, and a row in the Notion queue marked either "Needs assignment" or "Needs fixes". If every one of those steps waited on a click, throughput would be capped by how often I check Slack.

The clicking also degrades. WorkOS's own guidance on agent access control makes the point bluntly:

Avoid a binary of "autonomous" versus "always asks." The former inevitably expands until something bad happens, and the latter trains users to click approve reflexively until the confirmation step is security theater.

An oversight mechanism people learn to dismiss is worse than no mechanism, because it produces a paper trail claiming someone was paying attention.

Surplus is cheap and selection is scarce

Generating eight topic proposals costs less than the meeting where three people brainstorm two. The proposals arrive already argued: each states what the post would claim, why a reader would click today, and the launch or discussion that triggered it. Rejection is free. The ideas I drop cost nothing beyond the minutes I spent reading them.

That flips which half of the work is expensive. Producing candidates used to be the constraint, so oversight got built around protecting production capacity. Now candidates are abundant and judgment is the bottleneck, so the interface should optimize for judgment. Choosing which of eight topics deserves a reader's attention is the part of my job that doesn't delegate, and a batch of eight is a good way to spend it.

Review is asynchronous and batched. I drain the queue when I sit down to it, not when the agent is ready. The queue page lists what still needs a human, newest first, with status, reviewer notes, editor links, and a publish button behind a confirmation. The agent never waits on me, and I never sit in its critical path.

A queue of rejects beats a log of approvals

An approval log tells you what got through. It says nothing about what the agent wanted to do and didn't, which is the part you need when judging whether the thing has taste or is drifting. A queue keeps both halves: the ideas that became posts and the ones that died in the batch. The system remembers, too. Submit a new batch and any title already sitting in the queue gets dropped and reported back as a duplicate. Every batch is posted as a digest to our drafts channel, so the proposals are visible to the team rather than only to whoever drains the queue.

Read a few weeks of that and you learn things a permission log can't tell you. Which themes the agent keeps reaching for. Which ones a human keeps killing. Whether the hit rate is going up.

Where curation is not a control

Curation is an editorial mechanism. It has no authorization power, and the two get conflated fast.

A blog draft is reversible and has a blast radius of roughly zero until someone publishes it. Money, customer data, and production don't have that property. WorkOS's access-control guidance puts sending the message, deploying the build, wiring the funds, deleting the records, and granting another principal access in the class where human approval is a primary control rather than a courtesy, and it requires that approval to be out of band from the agent's own context, on a channel the agent can't forge. The same guidance says an agent's effective authority should never exceed the intersection of what the agent and the requesting user are each permitted to do. A queue does none of that. It has no notion of scope, and it can't stop an action it never sees.

So the pattern is layered. Classify actions by reversibility, blast radius, and the sensitivity of the data they touch, and attach the level of oversight each class earns. In our own loop, publishing keeps action-level gating: it posts Approve and Reject buttons in the Slack thread, and editing the draft invalidates a pending approval so the human approves what actually ships. The deterministic checks stay machine-run: voice scan, citation check, link check, secret scan, competitor guard. Machines catch the mechanical failures, and the human pass is left for judgment.

Two ways this fails

Rubber-stamping. If I keep all eight proposals, I've automated the appearance of oversight and added a step. Pre-argued proposals make that easy to slide into, because every item arrives with a rationale that sounds reasonable. The fix is cheap: track the rejection rate. A queue running near a hundred percent acceptance is a formality, and the honest response is to raise the bar or stop calling the step a control.

Drain rate. An agent that fills the queue faster than anyone empties it has moved the bottleneck rather than removed it. A backlog of stale candidates is its own kind of debt: the triggers go cold, the angles stop being timely, and someone eventually declares queue bankruptcy. Watch the age of the oldest item, and cut generation volume to the rate a human can actually review.

Both failures show up in the same two numbers, which is a good argument for putting those numbers on the queue page next to the drafts.

The interface that matters is the review surface

The human job on an agent-heavy team drifts toward setting direction, choosing among options, and owning the result. That's an editor's job, not an author's, and editors don't work through a chat box. They work through a queue with a status column.

If your agent produces reversible output continuously, build the review surface before you add another confirmation dialog.