Designing approval gates: which AI actions need a human signature

Approval is a design decision, not a safety net

Most teams add human approval late, as reassurance, and apply it evenly: either everything needs a signature or nothing does.

Both are wrong in the same way. Approval is not a blanket safety measure — it is a deliberate placement of latency and human attention at the specific points where the cost of being wrong justifies both. Put a gate everywhere and people approve without reading, which is worse than no gate because it manufactures the appearance of oversight. Put a gate nowhere and you have an autonomous system whether or not you intended one.

The design question is not whether to require approval. It is which actions, on what threshold, approved by whom.

Three questions that place the gate

For any action a system can take, ask:

1. Is it reversible?

The governing principle:

The autonomy an action may be given is bounded by how easily it can be undone.

A draft that a person will read before sending is trivially reversible. A database update is reversible with effort. An email to a customer, a payment, a deletion, or anything that leaves your systems is not reversible at all.

Irreversibility is the single strongest argument for a gate, and it outranks every efficiency consideration.

2. What is the blast radius?

One record, or ten thousand? A single customer, or a segment?

Actions that scale need gates at a lower threshold than actions that do not, because the same error rate produces a very different outcome. A 1% error rate across four hundred records is four problems. Across four hundred thousand it is an incident.

3. Who would answer for it?

If this action turns out to be wrong, who explains it? That person is the approver. Not their manager, not a shared inbox, not a rota — the individual with the standing to say yes and the accountability that comes with it.

If no such person exists, the gap is organisational, and adding a gate will not close it.

A threshold model that works

Even placement fails. Graduated placement works. A practical shape:

Two properties matter more than the exact boundaries:

• Most actions should land in Auto or Notify. If the majority need approval, the thresholds are set too tight and the gates will be rubber-stamped within a fortnight.
• The Escalate tier must exist. Systems that only distinguish "allowed" and "needs approval" have nowhere to put the genuinely unexpected case, and it falls into whichever adjacent tier is closest — usually the wrong one.

What an approval request must contain

A gate is only real if the approver can make an informed decision. That requires the request to carry:

1. What is proposed, in concrete terms. Not "update customer records" but the specific change to the specific records.
2. Why, in the system's own reasoning. The approver needs to be able to disagree with the logic, not just the outcome.
3. What it is based on. The inputs and context as they were at decision time.
4. Which policies were evaluated, and their results. Including passes.
5. What happens if declined. Does it retry, escalate, or stop? An approver who does not know the consequence of "no" is being asked a leading question.
6. How long it will wait. A request with no expiry silently becomes a blocked queue.

The failure mode here is a notification that says "Agent wants to perform action X. Approve / Deny." That is not an approval gate, it is a confirmation dialog, and people click through those without reading.

The timeout problem

Every gate needs a defined behaviour when nobody responds, and there are only three honest options:

• Expire and drop. The action does not happen. Correct for anything where inaction is safe.
• Expire and escalate. It moves to a second named person. Correct where the work genuinely must happen.
• Wait indefinitely. Correct only where a stale queue is harmless, which is rarer than people assume.

What is never correct is expire and proceed. If an action can execute without approval when the approver is at lunch, it did not require approval; it required a delay. Pretending otherwise is the most dangerous pattern in this whole area, because the system reads as gated and behaves as autonomous.

Building it, in order

1. Enumerate every action the system can take. Not categories — actual actions.
2. Score each on reversibility and blast radius. Two columns, no sophistication needed.
3. Assign a tier from the table above.
4. Name the approver per tier, as a person or a defined on-call role, and confirm they know.
5. Define the timeout behaviour per tier, choosing from the three options above.
6. Design the request payload so it carries all six elements listed earlier.
7. Instrument approval rates. If a gate is approved 100% of the time it is either unnecessary or unread, and both are worth knowing.
8. Review quarterly. Thresholds that were right at launch volumes are usually wrong at ten times the volume.

How this appears in practice

PSX Invest sits at one extreme of this model, and deliberately so. It publishes a call with an entry range, a target and a stop — and then stops. There is no execution tier at all, because placing an order is irreversible, its blast radius is the user's own capital, and the person who answers for it is the trader.

That is not a limitation that was worked around. It is the boundary that made the rest of the control layer tractable, and it is stated plainly on the product rather than softened.

Barion Agents, which is not yet available, is being specified around the full tier model, because operational work genuinely does need actions to execute rather than merely be proposed.

Related

The gate is one control among several. It depends on enforced rather than requested constraints to decide what reaches a gate at all, and on a complete audit record to make the approval mean anything after the fact. An approval nobody can later reconstruct is a formality rather than an accountability.