AI Agent Approval Workflow: What to Gate, What to Let Run Unattended

My blog routines publish to five live sites every weekday without asking me first. The same machine is not allowed to send a single LinkedIn message.

That looks inconsistent until you see the rule underneath it. Publishing a blog post is something I can undo in about ninety seconds. Sending a message to a person who knows my name is something I cannot undo at all.

Almost every write-up on this subject draws the line in a different place, at the boundary between reading and writing. Read freely, gate every write. It sounds responsible and it survives about a week of real use, because the moment your agents do anything worth doing they write constantly, and you end up either approving fifty things a day or quietly turning the gates off.

So here is the approval workflow I actually run across roughly fourteen launched products. The four questions I ask before an action is allowed to happen unattended, the two ways I have gotten it wrong, and where the gate has to physically live if you want it to survive contact with a busy week.

Why read versus write is the wrong line for an AI agent approval workflow

The read and write split is a permissions concept borrowed from databases. It maps badly onto agents, because it sorts actions by mechanism instead of by consequence.

Consider two actions that are both writes. One publishes a 1,600 word article to a blog. The other posts a comment on a stranger's social post. The first touches a production website and sounds serious. The second is a single sentence and sounds trivial. In practice the first one is the safe one. If a published post is wrong I edit it or unpublish it, and almost nobody saw the intermediate state. If the comment is wrong it is sitting in someone's notifications, attached to my face and my name, and deleting it does not unsee it.

Now consider two actions that are both reads. Fetching a public pricing page is a read. So is pulling a client's customer list out of a database to build a report. One of those I let run unattended forever. The other I do not, because the read itself moves private data into a place where the agent's next mistake can leak it.

The useful question is never whether the action writes. It is what the action costs when it is wrong, and who pays.

Which AI agent actions actually need a human approval gate

Here are the four questions I run through. An action needs a human gate if the answer to any single one of them is yes. If all four are no, the agent gets to finish the job and tell me afterwards.

Can I undo it in under five minutes?

This is the first filter and it removes most of the noise. A blog post, a draft pull request, a generated image saved to a folder, a row written to a table I own, a scheduled run that produced a report. All reversible, all cheap to fix, all ungated.

Five minutes is not an arbitrary number. It is roughly the point where undoing something stops being a nuisance and becomes an incident that eats the rest of my morning. Set your own threshold, but set one, because "reversible" with no time attached quietly expands to include things that technically can be reversed over two days.

Does it spend money?

Anything that spends gets a gate, at any amount. Not because a small charge matters, but because spend is the one category where a loop can compound while you sleep. An agent that buys one domain by mistake is a shrug. An agent that retries a failing purchase every ten minutes for six hours is a different conversation with your card issuer.

The cleaner version of this rule is not a gate at all. Where I can, I simply do not give the agent a payment method. An action that is impossible does not need an approval step, which is the whole idea behind minimizing what an agent can reach in the first place.

Does it speak as me to someone who knows me?

This is the rule that surprises people, and it is why my social routines draft but never send. A published article is addressed to the internet. A message, a comment, a connection request, or a reply is addressed to a person, and that person will read it as me having decided to contact them.

An agent that is 95% good at that is not 95% as valuable. It is a liability, because the other 5% lands in the inbox of exactly the people whose opinion I care about most. So the routines capture, research, and draft into a queue. I read the queue and I press send myself. It costs me about ten minutes a day and it is the best trade in the whole system.

Does it touch credentials or someone else's data?

Keys, tokens, encryption material, customer records, anything belonging to a client. These get a gate not because the agent is likely to misuse them, but because the blast radius is set by the credential and not by the task. The same reasoning runs through the OWASP guidance on excessive agency in LLM applications, which treats over-broad permissions and over-broad autonomy as two halves of one vulnerability. An agent holding a read only connection cannot delete your table no matter how badly a prompt goes wrong. That is a better control than any approval step, because it does not depend on me being awake.

If you want the security side of this in more depth, I wrote up the checks I run before real users touch an app, and the same instincts apply here.

What happens when you put the approval gate in the wrong place

Both failure directions are real, and the one everybody warns you about is the less common one.

Too many gates, and approval becomes a rubber stamp

The failure mode nobody plans for is not the agent doing something reckless. It is me approving forty items in ninety seconds, because I have forty items and eleven minutes.

This is a documented human tendency rather than a personal weakness. The systematic review of automation bias published in the Journal of the American Medical Informatics Association pooled four clinical studies and found that erroneous automated advice was followed 26% more often by people using decision support than by people working without it, a risk ratio of 1.26. The same review found that reliance on the automated recommendation rises under higher workload. The busier the reviewer, the more the review becomes a formality. Exactly when you need it most, it works least.

I hit this within a month of building my first approval queue. The queue was long, every item looked like the last one, and I noticed I had stopped reading past the first line. A gate you always approve is not a gate. It is a delay you are paying for and getting nothing back.

The fix was to remove gates, not to add discipline. Fewer items in the queue means each one actually gets read. If an action passes all four questions above, it should run unattended, and putting it in front of me anyway is not caution. It is dilution.

Too few gates, and the damage goes quiet

The other direction fails differently. It does not blow up. It drifts.

An ungated routine that is slightly wrong keeps being slightly wrong on schedule. A publishing routine with a broken link pattern will produce forty broken pages before anyone notices, because each individual run looks fine. I have shipped a post carrying dozens of dead links exactly this way, and the routine was working perfectly the entire time. It was doing precisely what I told it to.

So the second half of the workflow is not a gate at all. It is a report. Every unattended routine I run ends by telling me what it did, in enough detail that a wrong pattern is visible in one read. That is the trade for autonomy: you may act without asking, but you have to account for it afterwards. I go into how that plays out across a whole fleet of scheduled routines in what breaks when nobody is watching.

Where the approval gate should actually live

Getting the policy right and then implementing it badly gets you nothing, so this part matters as much as the four questions.

Put the queue somewhere you already open

Not a notification. Notifications get dismissed while you are doing something else, and dismissing one feels like handling it. My drafts land in a folder I open anyway, as plain files I can read and edit in place. Editing the draft is the approval. There is no separate approve button to click absent-mindedly.

Enforce underneath the agent, not inside the prompt

Writing "never send anything without asking" into an instruction file is a preference, not a control. It works most of the time, which is the problem, because most of the time was the standard you were trying to beat.

Real enforcement lives lower down. Claude Code exposes a permissions system in its settings with explicit allow and deny rules, so a tool call you never want made unattended can be denied outright rather than discouraged. Below that sit the credentials themselves: read only scopes, no payment method on file, separate accounts for anything that posts publicly. If you are building the daily marketing side of this, I walked through the full three repository setup and where the send step sits in the system I run every morning.

Make approving one keystroke and rejecting free

If approval is expensive you will start batch approving to clear the backlog. If rejection is expensive you will approve things you are unsure about. Both push you toward the rubber stamp. The cheapest good design I have found is a queue where doing nothing means nothing sends, so an item I never get to simply expires instead of shipping.

This is roughly the architecture I teach inside the Reinventing AI Accelerator, where members clone the same agents and routines I run and then set the gates to their own risk tolerance. The gates are the part people skip, and they are the reason my routines have been allowed to keep running.

How to audit an approval workflow you already have

Once a month, take the list of every automated action your agents can perform and sort it into two columns, gated and ungated. Then attack each column with the opposite question.

For everything gated, ask when you last actually rejected one. If the answer is never, that gate is theatre. Either delete it and let the action run, or work out why the drafts are always fine and gate a narrower slice instead.

For everything ungated, ask what the worst wrong version looks like repeated forty times on schedule. Not once. Forty times, because that is what unattended means.

The list will be shorter than you expect, and moving three or four items across the line is usually the whole month's work.

The build this came out of

I worked most of this out the hard way, by watching a marketing system run against real accounts and finding out which parts I could not sleep through. That build is the session where the sending question first forced itself on me, and the full replay is available instantly if you want the whole system rather than the policy layer sitting on top of it.

If you would rather start from something already assembled, the Accelerator includes the apps, agents, and automations I run, plus the weekly live sessions where we take them apart. It is 189 dollars and you can cancel any time. One small ask: if you build a gate that catches something mine would have missed, come tell me about it in a session.

Frequently asked questions

Should every AI agent action require human approval?

No, and trying is the most common way these systems die. Approving everything produces a queue too long to read carefully, and the research on automation bias says a reviewer under load starts accepting recommendations rather than evaluating them. Gate the actions that are irreversible, that spend, that speak as you to a person, or that touch credentials. Let the rest run and report back.

What is the difference between a human approval gate and a permission?

A gate pauses an action and asks you. A permission decides whether the action is possible at all. Permissions are stronger, because they hold even when you are asleep, distracted, or approving in bulk. The right order is to remove the capability first, then add a gate only for the things the agent genuinely needs to be able to do.

How do I stop approving things without reading them?

Shorten the queue rather than trying harder. Every item you remove by letting a safe action run unattended buys back attention for the items that remain. It also helps to make the approval step require a real edit, because reading is the point and a single approve button lets you skip it.

What should an unattended agent do when it is not sure?

Stop and report, rather than guess and continue. My routines are written so that an ambiguous state produces a description of what was found instead of an action taken on a guess. A run that ends with a clear account of the blocker is a successful run. A run that improvised and shipped something is the expensive kind of failure.

Do approval gates slow the whole system down?

Only the gated slice, and that slice should be small. My publishing runs finish start to finish with no human involvement at all. The parts I hold back are measured in a few minutes a day of reading drafts and pressing send myself. That is a rounding error against the time the unattended half saves, and it is the reason I am willing to let the unattended half exist.