Designing approval gates that keep agents fast and auditors happy

The ticketing queue failure mode

The most common way an agent deployment dies is not hallucination and it is not a security incident. It is death by approval. A compliance stakeholder, quite reasonably, asks for human review before the agent does anything consequential. The engineering team, quite reasonably, implements exactly that. Six weeks later the agent is producing forty review requests a day, the designated approver is skimming them in batches at 4pm, and the end-to-end cycle time is worse than the manual process the agent replaced.

We have walked into three separate finance ops deployments that had reached exactly this state before Stewdio was engaged. In every case the reviewers had stopped reading. One client had a 99.7 percent approval rate across four months of gated actions. That number should terrify you. It means the gate was catching nothing, costing hours per day, and creating a paper trail that proved humans were approving things they never actually evaluated. An auditor who pulls that log does not see a control. They see evidence of a control that does not function.

The lesson we took from those engagements is that approval gates fail in production for one reason: they are designed as a blanket property of the workflow instead of a targeted property of individual actions.

Gate the action, not the workflow

During the audit phase of every Stewdio engagement we map the client's workflow into discrete actions before we write a line of agent code. For an accounts payable workflow that might be: fetch the invoice, extract line items, match against the purchase order, resolve a mismatch, schedule the payment, release the payment. These actions do not carry equal risk, and treating them as if they do is the root design error.

We score every action on three axes. Reversibility: can the action be undone within the same business day at near-zero cost? Blast radius: what is the worst-case dollar or relationship damage if the action is wrong? Regulatory surface: does the action touch something a framework like SOX, SOC 2, or the client's own delegation-of-authority matrix explicitly names? Reading an invoice scores near zero on all three. Releasing a 200,000 dollar wire scores high on all three. Those two actions should never share an approval policy, yet in a workflow-level gate design they always do.

The output of this exercise is an action risk register, and it becomes a load-bearing artifact. It is the document we design gates from, the document auditors ask for first, and the document that turns every future argument about oversight from a matter of opinion into a matter of scoring.

The three-tier gate pattern

Every gated agent system we now build uses three tiers, and the discipline is in refusing to invent a fourth.

Tier one is autonomous with logging. The agent acts, records its full reasoning trace and input evidence, and nobody is interrupted. This tier is for reversible, low-blast-radius actions: data retrieval, classification, drafting, matching within tolerance. In a mature deployment this should cover 85 to 95 percent of all agent actions. If it covers less, your risk scoring is dishonest or your workflow decomposition is too coarse.

Tier two is asynchronous review. The agent acts immediately, and the action lands in a review queue that a human samples within a defined window, typically 24 hours. The critical property is that review happens after execution, so the agent is never blocked, but a reversal path exists inside the review window. This tier fits actions that are individually low-stakes but aggregate into risk: applying credit memos under a threshold, adjusting delivery windows, updating CRM ownership.

Tier three is synchronous approval. The agent halts, packages a decision brief, and waits. This is the only tier where a human sits in the critical path, and it is reserved for actions that are irreversible, high blast radius, or explicitly named in a regulatory control. In our deployments tier three typically covers 2 to 5 percent of actions. When we see a design where it covers 30 percent, we know the team has used approval as a substitute for confidence, and we send them back to their evals.

Make the approval decision take ninety seconds

A tier three gate is only fast if the approver can decide quickly, and they can only decide quickly if the agent does the preparation work. We hold agent-generated decision briefs to a hard standard: a competent approver should reach a defensible decision in ninety seconds without opening another system.

That means the brief contains the proposed action stated in one sentence with the exact amounts, parties, and system records involved. It contains the evidence the agent relied on, linked directly to the source records in the client's ERP or CRM, not screenshots and not summaries of summaries. It contains the specific reason this action tripped the gate, because 'needs approval' is not a reason and trains approvers to stop reading. And it contains the agent's own uncertainty: what it could not verify, which assumption is doing the most work, and what the cheapest way to check that assumption would be.

The uncertainty section is the one teams skip and the one that matters most. An approver reviewing a confident-sounding brief with hidden gaps is worse off than an approver doing the task manually. When the agent says 'I matched this invoice to PO-4471 but the vendor name differs by one legal suffix and I could not confirm the entity relationship,' the human is doing exactly the judgment work the gate exists for, and nothing else.

An approval gate that fires on every action is not a control. It is a rubber stamp with latency.

What auditors actually want

We have now sat through enough control walkthroughs on behalf of clients to say this plainly: auditors do not want more approvals. They want demonstrable, consistently operating controls. Those are different things, and conflating them is what produces the ticketing queue.

What holds up in an audit is a written policy that maps action types to tiers, evidence that the mapping is enforced in code rather than in convention, immutable logs showing every action with its tier, its evidence, and its outcome, and proof that the review tiers are actually operating: sampled tier two actions with recorded review outcomes, tier three approvals with timestamps and named approvers, and a periodic report on override and rejection rates.

That last metric deserves attention. A tier three rejection rate of zero over a quarter is an audit finding waiting to happen, because it suggests the control is ceremonial. A rejection rate between 2 and 8 percent, with documented reasons, is what a functioning gate looks like. We put that number on the monthly operating review for every deployment we run, and we have had auditors tell us it is the first agent oversight metric they have seen that they actually believe.

Let evals move the thresholds

Tier assignments should not be permanent. The correct threshold for autonomy is a function of demonstrated accuracy, and demonstrated accuracy is what your eval suite and your tier two review data measure continuously.

Our standard rollout runs month by month. In month one, actions that will eventually be tier one run as tier two, so every early action gets sampled review while the evals accumulate real production graded examples. In month two, action types that clear an agreed accuracy bar, typically 98 percent or better on the graded sample with no high-severity misses, are promoted to tier one, and the promotion itself is logged as a change-controlled event with the eval evidence attached. Month three does the same for the tier two population, tightening sampling on anything that has drifted and loosening it where performance holds.

Promotion must also run in reverse, automatically. If the rolling accuracy for an action type drops below its bar, the system demotes it one tier without waiting for a human to notice. Demotion events page the operating team. This is the piece that converts approval gates from a static compliance artifact into an actual control loop, and it is the piece we have never once seen in a system built with workflow-level gates.

The short version

Score every action for reversibility, blast radius, and regulatory surface before you design a single gate. Use three tiers and defend the boundaries: autonomous with logging for the overwhelming majority, asynchronous sampled review for aggregate risk, synchronous approval only where a wrong action cannot be walked back. Make every synchronous approval decidable in ninety seconds with the agent's evidence and its stated uncertainty in front of the approver. Track rejection rates and treat a rate near zero as a defect, not a success. And wire your evals to the tier assignments so autonomy is earned, measured, and revocable.

Do this and the compliance conversation changes shape. You are no longer asking auditors to trust an agent. You are showing them a control system with better evidence, tighter feedback, and more honest metrics than the manual process ever had. In our experience, that is the point in the engagement where the compliance team stops being the blocker and starts asking which workflow the agent can take on next.