How do you set approval timeouts for an AI agent without creating rubber stamps?

## Timeouts are a policy decision, not a config default Every pending approval is a run holding open state and, usually, a user waiting. The window you give a human should come from the action, not from a framework default. A checkout-flow correction that is worthless after the customer leaves might get 90 seconds. A production index change that will be applied in tonight's maintenance window can wait eight hours. A treasury wire under a four-eyes rule might get 30 minutes during trading hours and roll to the next business day outside them. Sizing the window is where domain knowledge shows up. ## Deny by default when it matters The question interviewers actually want answered is what happens at expiry. Three options, and the choice is per action class: - **Deny and close.** The correct default for irreversible or externally visible actions. Nobody answered, so nobody assented; a fresh request must be raised, with preconditions revalidated, because the world moved. Record the expiry — an approval that timed out is a signal about staffing or scope, and you want it in the data. - **Continue without the action.** Sometimes the agent can complete a degraded but useful result: finish the analysis, skip the send, hand back a draft. Better than a dead end when the gated step was optional. - **Proceed on expiry.** Only for reversible, contained steps where blocking is the larger harm — and even then it needs an explicit policy entry and a louder audit trail, never an inherited default. Silent auto-approval on timeout is how gates become theatre. Escalation belongs alongside expiry: nudge the primary approver, escalate to a secondary after a fraction of the window, then expire. And a break-glass path — an authorized human forcing an action through with mandatory justification and heightened logging — is worth having, because the alternative is people disabling the gate wholesale during an incident. ## Fatigue is the real failure mode A gate is only a control while a human is genuinely deciding. Push enough requests at an approver and they will start clicking approve, exactly as people accept MFA prompts they did not initiate. The mechanism is well understood: high volume, low base rate of genuine problems, and evidence too thin to evaluate, so approving becomes the rational default. The measurable symptoms are the approval rate and the decision dwell time. If a gate is approved 99.8% of the time with a median decision of four seconds, one of two things is true: the policy is scoped too broadly and is catching routine traffic, or nobody is reading. Both are fixable, and both are invisible unless you instrument them. Rejection rate near zero over months is the same signal. ## Designing for attention rather than volume Attention is the scarce resource, so spend it deliberately: - **Narrow the policy.** Move the threshold until the gate fires on the tail that genuinely needs judgement. Under a tiering scheme where refunds at or under $200 run automatically, only the exceptional cases reach a person. - **Improve the evidence.** Show the resolved arguments, the diff or blast-radius estimate ("this DDL touches a table serving 4,100 requests per minute"), the agent's stated reason, and what it already checked. A reviewer who can judge in ten seconds *because the evidence is good* is not fatigued; one who clicks in ten seconds because there is nothing to read is. - **Batch and group.** Fifty similar low-risk requests reviewed as one set with per-item opt-out beats fifty notifications. - **Make rejection cheap and useful.** If saying no means the run dies and the requester starts over, people say yes. Let a rejection carry feedback or an edited payload so the loop can continue sensibly. - **Rotate the load.** An on-call rota with defined hours, coverage across timezones, and explicit handoff. Routing to one named owner guarantees that their week off becomes a queue of expiries. ## The throughput conversation At fleet scale this becomes a capacity question that a lead owns: how many gated actions per day can the organization actually adjudicate, and what is the latency budget for a human decision inside a product flow? If the answer is that approvals would need three full-time reviewers, the design is wrong — either narrow the gates, or invest in capability controls (scoped credentials, sandboxes, per-tenant limits) so fewer actions need a human at all, or accept a slower product. Pre-authorized envelopes are the middle path: a human approves a bounded budget or scope once — this quarter's refund allowance, this maintenance window's table list — and the agent operates inside it without per-call gates, with the envelope itself audited and expiring. The honest framing to give an interviewer is that there is no universally right timeout or approval rate. There is a per-action-class tradeoff between the cost of a wrong action and the cost of delay, plus a hard constraint on how much genuine human attention exists — and a design that ignores the second one degrades into rubber-stamping regardless of how good the first looks on paper.