Every autonomous remediation demo follows the same script: an alert fires, the agent correlates it against forty signals, proposes a fix, applies it, and the incident closes in under a minute. What the demo edits out is the two minutes before the fix — the part where a human being decides whether to let it happen. That gap is not a rounding error. For most teams it is where the entire value of AIOps is won or lost.
The agent is no longer the hard part
Proposing a remediation has become cheap. A competent agent watching a service's metrics, deploy history, and dependency graph can name the likely fault and a plausible action within seconds. And for most services the action space is small: restart the workload, drain the node, roll back the deploy, raise the connection pool, scale the replica count, shed traffic from a region. Call it six to ten candidate actions per service across the dozen services that actually page someone. The unsolved problem is not generating the proposal. It is mapping each proposal to a person, a time window, and a level of evidence that makes saying yes take twenty seconds instead of four minutes.
Approval latency is arithmetic you can do on a napkin
Take a mid-size estate generating 40 remediation-eligible events a day — a number most on-call rotations will recognize. If each gate costs three and a half minutes of context loading plus a decision, that is 140 minutes of engineering time per day spent deciding, before anything has been fixed. Now add the queue. If the median wait-to-approve is eleven minutes because the approver is heads-down inside another incident, you have converted a forty-second fix into an eleven-minute outage extension. The gate did not make you safe first. It made you slow first, and safe second, and the customer experienced the slow part.
The teams that get this right treat approval latency as a service-level objective, not a side effect. They instrument time-to-approve the same way they instrument p99 request latency, and they page on it.
A gate is only as cheap as the context attached to it
What separates a twenty-second approval from a four-minute one is not the approver's expertise. It is what arrived in the notification. A proposal worth approving carries:
- The exact command or diff, verbatim, never a natural-language summary of it.
- Blast radius quantified: which services, what share of traffic, which regions, which customers.
- The evidence that drove the diagnosis, linked directly to the three charts that matter.
- The agent's confidence and the specific observation that would have falsified its theory.
- A pre-computed rollback, ready to fire, with the expected recovery time.
- An expiry: auto-decline in ten minutes and escalate, so the gate never becomes a silent backlog.
A gate that requires opening a dashboard to evaluate is a gate that gets rubber-stamped. The context packaging is the safety mechanism; the button is just where it terminates.
Not every action deserves the same gate
Uniform gating is the most common design mistake in approval-gated AIOps. It treats a read-only enrichment and a cross-region failover as the same class of decision, then wonders why approvers stop reading. Tier by reversibility and blast radius instead:
| Tier | Example action | Gate |
|---|---|---|
| 0 | Enrich alert with dependency data | None — log only |
| 1 | Restart single pod, <2% capacity impact | Auto-apply, post-hoc notify |
| 2 | Scale replicas, shift traffic weight | One-click approve, 5-min timeout |
| 3 | Roll back deploy, drain node, failover | Two-person approve, explicit |
A healthy distribution lands near 70% of actions at Tier 0–1, 20% at Tier 2, and 10% at Tier 3. If your Tier 3 bucket is half your volume, you have not tiered — you have relabeled.
An approval gate earns its keep only when saying yes is faster than routing around it.
Rubber-stamping is what over-gating looks like
Approval fatigue is measurable, and it is the failure mode that quietly converts a safety control into a latency tax. Two ratios tell you everything: the share of proposals approved without any edit, and the share that were edited before approval.
Sustained approve-without-edit above 90% for a given action class means the humans have become a confirmation dialog. That class should be promoted down a tier — with a revert criterion written down before you do it. Edit rates above roughly 20% mean the opposite: the proposals are under-specified or the diagnosis is wrong, and the gate is doing real work that should be fed back into the agent's retrieval and prompt context rather than absorbed by the approver.
The button is a label factory, and it is going to move
The direction of travel is not toward removing gates. It is toward gates that expire. Every approval and every edit is a supervised label on a specific action class in a specific service, and those labels accumulate into a trust curve you can actually defend in a change review: this action class, this service, four months, zero rollbacks, 96% approve-without-edit — promote it and start auto-applying with notification. Policy-as-code delegation with an expiry date beats a permanent yes or a permanent no, because it forces the reassessment instead of letting the gate become furniture. The teams that win at this will be the ones whose gates are numbered, tiered, instrumented, and scheduled to disappear one class at a time.