Your agent asks permission for the wrong things

The standard advice for writing an agent prompt contains a line that is both correct and, read from a different chair, alarming.

When the user's intent is clear, execute immediately without confirmation.
Only when intent is unclear, ask minimal questions to clarify.

I wrote about the first half in the previous post, and I stand by it. An agent that asks permission for everything is not an agent, it is a very slow form. And the pattern even supplies a safety net in that second line.

Look closely at what the safety net is measuring.

Ambiguity and consequence are different axes

The gate is clarity of intent. Is the request clear enough to act on?

That is a useful question. It is not the question a risk committee is asking, which is: how bad is it if this goes wrong, and can we undo it?

Those two axes come apart immediately.

Every row is unambiguous. The intent is perfectly clear in all six. So a gate on ambiguity lets all six straight through, including the three you would want a human to see.

Clarity and consequence are different questions. The usual gate only asks one.

Worse, the gate is anti-correlated with what you want. The most dangerous instructions tend to be the clearest. "Delete all my test accounts" is a crisp, well-formed, entirely unambiguous request. The model will be confident. The gate will be satisfied. The accounts will be gone.

Meanwhile, the vague request that trips the safety net is usually the harmless one, because vague requests tend to be exploratory.

This is not an argument against the pattern

I want to be exact about this, because it would be easy and wrong to read the previous section as "that is bad advice."

It is not. It is advice about agent quality, and for agent quality it is correct. The safety net exists to stop the agent guessing wrong about what you meant, and it does that job well.

The gap is that the same sentence gets copied into systems where the tools can move money, delete records and send messages to customers, and nothing in the sentence changes when the blast radius does. A prompt written to make an agent feel responsive is doing double duty as an authorisation model, and it was never designed for that.

Gate on the class of action

The fix is not to make the agent ask more. That takes you back to the useless assistant, and it has a second failure mode that is worse than it sounds: an agent that asks for confirmation twenty times an hour trains the person to click yes without reading. You have not added oversight. You have manufactured a rubber stamp and moved the liability onto a colleague.

The fix is to stop gating on how clear the request was, and start gating on what the action does.

# Not: "is the request clear?"  That is a quality question.
# Instead: "what does this action do?"  That is the control question.

AUTONOMOUS = {search_orders, read_ticket, summarise_document}   # reversible, no external effect

def dispatch(call):
    if call.name in AUTONOMOUS:
        return run(call)
    if call.name == "issue_refund" and call.args["amount"] <= REFUND_LIMIT:
        return run(call)
    return await_human_approval(call)        # everything else stops here

Three properties decide which bucket an action lands in, and none of them require an AI-specific framework.

Reversibility. Can you put it back? A read is free. A refund is awkward. A deletion is final.

External visibility. Does it leave your system? An email to a customer cannot be unsent, and it carries your name.

Value or volume. One refund is a transaction. Every refund from a supplier is an incident.

Bucket the tools once, at design time, and the agent stays fast on everything harmless while the expensive paths always stop. Notice the count too: the confirmations that survive are rare, which is what keeps them meaningful. Approval fatigue is a real bypass, and the cure for it is fewer, better prompts, not more of them.

Where this touches the rulebook

Every regulated firm already has a version of this control for humans. Payments above a threshold need a second pair of eyes. Certain actions require a named, authorised individual. These rules exist because someone worked out that the cost of an error scales with the action, not with how confidently it was requested.

An agent with a tool has the permission the tool implies. The obligation area does not change. What changes is that the thing holding the permission is not a person, and the mechanism the firm relied on, a human pausing before something significant, is exactly what the prompt line above removes.

I mean this as scope, not citation: this is the human-oversight and authorisation area, and which obligations actually bite depends on your regulator and your architecture. It is an advisory estimate until someone checks it against your setup.

For the frameworks, this sits on the MAESTRO Agent Frameworks layer and reads as T3 Privilege Compromise, with ASI03 Identity and Privilege Abuse in the Agentic Top 10. If you want the plainer label, the OWASP name for the failure where an agent has more reach than the task requires is excessive agency, and this is one of its cleanest forms.

The one line to take

"Execute immediately without confirmation" is a good default for an agent that reads things.

It is an authorisation decision for an agent that changes things, and it should be made where the action lives, not in a sentence at the top of a prompt.

Ask yourself which of your agent's tools you would be comfortable with it using at 3am, unsupervised, on a perfectly clear instruction from someone you have not met. That list is your autonomous set. Everything else needs a gate that does not depend on how well the request was phrased.