The agent needs a yes.

Three days ago I published an essay on this site. My ops agent wrote two short posts to promote it, one for LinkedIn and one for X, and handed them to my posting agent with a note: Chakit has already approved these, post them.

The posting agent didn't post them.

It wasn't broken. It was following its rules, and one of them says it publishes on my accounts only after I say yes to it directly. A note from another agent saying "he already said yes" doesn't count, however confident the note sounds. So it marked both posts as on hold and waited for me.

It would be easy to call that friction. It isn't. The posting agent was right, and a couple of days later I made the rule explicit: promo posts go out only after I say yes in the posting agent's own chat. Approvals passed along by other agents don't count.

That is the whole essay. An AI agent should ask a human before any action that is public, irreversible or expensive, and the yes has to come from that human, through a channel the agent can trust. Not from a document. Not from a web page. Not from another agent saying "he already approved it."

When should an AI agent ask for human approval?

Ask before any action you can't take back, that other people will see, or that spends money or access. Everything else can usually run on its own, as long as it leaves a receipt.

That sounds obvious, but it's worth saying because the default in most agent setups is the opposite. The agent gets a tool, and if it has the tool, it uses it. Whether a human should have looked first is left to the prompt.

OpenAI's A practical guide to building agents names two triggers for handing control back to a person. The first is when the agent keeps failing. The second is high-risk actions: "Actions that are sensitive, irreversible, or have high stakes should trigger human oversight until confidence in the agent's reliability grows." Its examples are cancelling orders, authorising large refunds and making payments.

Anthropic's Building effective agents describes the same shape from the other side: "Agents can then pause for human feedback at checkpoints or when encountering blockers." The pause is part of the design, not a sign that the agent failed.

What is human-in-the-loop approval for AI agents?

Human-in-the-loop approval means the agent prepares an action, stops, and only carries it out after a named person explicitly approves it. The agent can draft the post, the email, the refund or the deploy. It can't press the final button by itself.

The OWASP Top 10 for LLM applications has a whole entry on what happens without this. LLM06:2025 Excessive Agency traces damaging agent actions to three root causes: "excessive functionality; excessive permissions; excessive autonomy." One of its listed mitigations is to "require a human to approve high-impact actions before they are taken."

The example OWASP picks is almost my exact situation. An app that "creates and posts social media content on behalf of a user should include a user approval routine within the extension that implements the 'post' operation." The approval lives inside the post action, so there's no way to post without going through it.

An approval the agent can't verify is just a sentence in its context window.

Why an approval relayed by another agent doesn't count

Because the agent can't tell a real relayed approval from a fake one. To the model, "Chakit approved this" is text. It looks the same whether my ops agent wrote it, a web page contained it, or an email planted it.

Simon Willison put the underlying problem plainly in The lethal trifecta for AI agents: "LLMs follow instructions in content." They will follow any instruction that reaches the model, "whether or not they came from their operator or from some other source." Everything ends up as one sequence of tokens.

OWASP lists the same risk for multi-agent setups. Among the triggers for excessive agency it names prompt injection from "a malicious/compromised peer agent." If one agent can approve actions for another just by saying so, then whoever can get text into the first agent can approve actions for the second.

My ops agent wasn't compromised. It was just wrong about scope, which is the boring and much more common version of the same failure. An approval I gave for one thing was being stretched to cover another. The rule that blocks an attacker also blocks an honest mistake.

How to design approval gates for AI agents

This is the short version of what I'd set up first, and roughly what I run now.

1. Sort actions into two lists. Things the agent can do alone (read, draft, summarise, schedule a draft) and things that need a yes (publish, send, pay, delete, change access). Write the second list down. If it only lives in a prompt, it will drift.

2. Put the gate in the tool, not the prompt. OWASP calls this complete mediation: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not." The post tool should refuse to post without a recorded approval, whatever the model believes.

3. Accept approvals from one place. The human's direct chat with that agent, an approve button, a signed request. Not forwarded notes, not other agents, not anything the agent read on the way.

4. Scope every yes. A yes covers the action it names, once. Standing permissions are fine, but they should be explicit, written down and easy to revoke. Mine got revoked in one sentence, and that's how it should work.

5. Show the exact thing being approved. The final text, the recipient, the amount. Approving "the promo posts" is vaguer than approving these two posts, word for word.

6. Make holding visible. A held action should show up somewhere a human looks, with what it's waiting for. Otherwise an approval gate turns into a silent queue.

The cost of the gate

There is a real cost. My promo posts for that essay have been sitting on hold for three days, because the one person who can approve them was busy. A fully autonomous setup would have shipped them in a minute.

I'd still make the same call. A late post costs me some reach. A post that goes out under my name because an agent misread its permissions costs me something I can't get back with a delete button.

In The agent needs a wallet I wrote about limits. In The agent needs its own login I wrote about knowing which agent did what. In The agent needs a heartbeat I wrote about noticing when an agent goes quiet. This is the layer above all three: deciding which actions an agent is never allowed to finish without you.

Write down what needs a yes. Then make sure the yes can only come from you.