Ask first, act second: the case for an approval gate

Most arguments about agent autonomy are framed as a dial: more autonomy means more speed, more oversight means more friction. That framing hides the useful question. An agent does hundreds of small things in a run, and almost none of them need a person. A few do. The design work lies in telling those apart, and in making the pause, when it comes, cheap for the person who has to decide.

What goes wrong without a gate

The failures are rarely dramatic in the moment. They are ordinary actions taken at the wrong time, with the wrong scope or on the wrong instruction.

• A message goes to the wrong audience. The agent drafts a correct follow-up and sends it to the whole contact list instead of the three people on the thread.
• Something is deleted that should have been archived. "Clean up the duplicates" meets an ambiguous definition of duplicate.
• Data leaves through an export that included one folder more than anyone meant.
• A schedule outlives its purpose. A recurring job set up for one week keeps running, and spending, for months.
• The instructions change underneath you. An agent that can edit its own instructions, or is talked into it by text on a web page it read, is no longer running the policy you approved.
• Authority spreads quietly. One agent hands work to another, and the second turns out to have broader access than the first.

Each of these is reversible on paper and expensive in practice. In every case, the step just before the damage was a single, identifiable call that a person would have caught in seconds if they had seen it.

Gate the consequence, not the activity

The obvious overcorrection is to make the agent ask about everything. That fails just as reliably, in a different way: people approve a dozen harmless requests in a row and stop reading by the thirteenth. A gate that fires constantly trains people to click through it.

The workable rule is to pause on consequence. Reading, searching, drafting and analyzing inside an agreed scope should run freely within the limits that have been set. What pauses is the short list of actions whose effects leave the room or are hard to undo: sending things out, destroying data, exporting it, scheduling recurring work, acting inside a live session, rewriting the agent's own instructions and putting another agent to work. GoCux pauses on exactly these seven action classes. Your list may differ, but it should be short enough that every pause deserves attention.

What a good gate shows the approver

A gate is only as good as the decision it supports. If the approver sees "The agent wants to send an email. Approve?", the click is a formality. A useful approval request answers the following without any digging:

1. The exact call. Not a summary, but the action as it would run: recipients, subject and body; the files and destination of an export; the records a deletion would touch. It is quoted verbatim, so what gets approved is precisely what was requested.
2. Why it is happening. Which work order produced it, what the goal was, and the evidence that led here.
3. The scope. Everything within reach of the action, listed rather than implied. For an export, the files in scope; for a message, the full recipient list.
4. The options. Approve, reject and, where it makes sense, edit before approving, for example to tighten a recipient list.
5. What happens next. What runs after approval, and what a rejection means for the rest of the work.

Two properties matter as much as the content. First, a decision should apply only to the single attempt it was given for: approving one email does not approve the next, and the action is checked again when it actually runs, in case something changed in between. Second, a rejection is a result, not an error. It is recorded, and it does not quietly release the work through another path. A refusal is a result explains why that matters.

Why one click is enough

If the gate has done its job, the decision itself is small. The expensive part of oversight is gathering context: finding the draft, checking the recipient list, remembering why the work started. A good gate does that gathering before it asks. What remains for the person is a judgment, and a judgment is one click.

Making approval heavier does not make it safer. Mandatory comments, multi-step confirmations and approval forms mostly slow down the people who were going to approve anyway, and they push teams to widen the agent's standing permissions so that it stops asking. That is the opposite of the goal. If an approver regularly needs more than one click to feel confident, the request is missing information, and the fix belongs in what the gate shows, not in how many times the person has to confirm.

The click also does a second job: it becomes a record. In GoCux, decisions and their outcomes are kept as receipts at the moment they happen, on the same record as the work, so the question "who approved this, and what exactly did they see?" still has an answer later. That record is what turns a pause into accountability. What an agent audit trail should record covers what belongs in it.

Who should be asked

A gate also needs a clear answer to who may decide. The person who launched the work is often the right approver for sending a draft, while deleting production data or exporting a customer folder may need someone with authority over that system. Keep the rule simple enough that the agent never has to guess, and make sure an approval given inside one company carries no weight outside it. Who may approve agent work goes through the roles in more detail.

Putting a gate in place

Whatever tooling you use, a few checks tell you whether a gate will hold up:

• The list of actions that pause is written down and short enough that every pause gets read.
• The request shows the exact call, its scope and its reason, without clicking through to find them.
• Approve, reject and, where useful, edit are all available, and a rejection closes that path.
• Each approval covers one attempt and is checked again when the action runs.
• Decisions are recorded with the work, including who decided and what they saw.
• Everything outside the list runs without asking, inside limits on time, tool calls and spend.

If you are just starting out, run the agent read-only first and add consequential actions one class at a time, each behind its own gate. The governance page shows how GoCux fits these pieces together.