Approval timeouts: what your agent should do when nobody answers

In the approval queue system, four fields are essential: the action, justification, blast radius, and confidence with an alternative. However, there is one crucial field missing that answers the question of what happens when nobody answers. Real queues have items that age, and if the system does not decide what an expired item becomes, the default decision is often detrimental.

Two common issues arise without a timeout policy. In the graveyard scenario, items pile up and the agent stalls, leading to requests being ignored and the opposite of the intended outcome. The global auto-approve approach, where items older than a certain time get approved, might seem practical but can lead to approving high-risk items automatically. This defeats the purpose and creates a rubber stamp system with a delay.

The source suggests giving each action type its own timeout and default action, choosing the default based on the question of how expensive it is to undo the action if the default proves incorrect. Four default actions cover most scenarios: approve for reversible and low-impact internal actions, hold and escalate for actions leaving the system or transferring money, cancel for time-sensitive actions whose value expires, and re-plan for actions based on potentially stale data.

The timeout policy is implemented by per-type defaults, not a global SLA, as different actions require different levels of patience. Rough values per action type, such as 30 minutes for customer replies, 4 hours for refunds, and 24 hours for internal changes, can be fine-tuned using real data. The useful numbers are the median and 90th percentile of approval times for each type. If the 90th percentile exceeds the timeout, the timeout will trigger on normal days, prompting more attention from reviewers.

The implementation is minimal and can live alongside routing rules. A data class called TimeoutPolicy defines the after delay, timeout action, escalation target, and escalation person. A dictionary maps action types to their respective TimeoutPolicy instances. The resolve_expired function checks the item's age against the policy and returns the appropriate action and escalation target.

If an action type is not in the table, it should default to ESCALATE rather than APPROVE. Every timeout decision must be logged, distinguishing between a person approving an action and the system automatically approving it due to inactivity. When this approach is implemented, a fifth column should be added to the table in APPROVALS.md, listing the timeout and default for each action type. This simple addition can save many arguments and improve the queue's efficiency.