Skip to content
Rubatt

Why autonomous agents need approval gates

The argument for gating every irreversible action, and why the usual objection about speed does not survive contact with a team that has to verify the output anyway.

Rubatt engineering6 min read

The objection to approval gates is always the same. If a person has to approve every write, what exactly did the automation buy you? It is a fair question and it has a specific answer, but the answer only makes sense once you look at what teams actually do with unverified automation.

Unverified output gets verified anyway

When a system writes to a ledger without review, nobody relaxes. Somebody spot checks. Somebody runs a reconciliation at the end of the month to see whether it behaved. Somebody investigates when a number looks strange. That work is real, it is slower than reviewing a diff, and it happens after the write rather than before it, which means it produces corrections rather than preventions.

Gating moves the same verification earlier and makes it cheaper. Reviewing a proposed change with its evidence attached takes seconds. Reconstructing why a change happened three weeks ago takes an afternoon.

The failure mode is what changes

This is the part that matters. An ungated agent that gets something wrong produces a bad write that somebody has to find. A gated agent that gets the same thing wrong produces a suggestion somebody declines. The error rate has not changed. The consequence has changed completely, and consequence is what determines whether a team will let a system near their systems at all.

The point is not that the agent is right more often. It is that being wrong stops costing you anything.

What a gate has to show

A gate that says the agent would like to update an invoice is theatre. Nobody can evaluate that, so everybody approves it, and within a week the gate is a click people perform without reading. A useful gate shows the concrete change: which record, which field, from what to what, and the evidence behind it. It should read like a pull request.

  • The exact records and fields that will change
  • Before and after values, not a description of them
  • The evidence the agent used
  • What it rejected, when the alternatives were close

Where gates should come off

Not never. After a team has watched a few hundred correct proposals for one narrow action type, relaxing that specific gate is a reasonable decision. What matters is that it is a decision, made deliberately, scoped to one action, and reversible in a single deploy. The failure we see repeatedly is not teams relaxing gates. It is systems that never had them, shipped by people who assumed the model would be careful.

If you are evaluating an agent vendor, ask what happens on the write path. The answer tells you more than any benchmark.

Rubatt engineering

We build agent systems for operations, sales, research and support teams. Everything here comes from something that broke in production first. Reach us at hello@rubatt.com.

Building something like this?

We are happy to talk architecture before there is any commercial conversation.