{
  "id": 10782465,
  "title": "Approval timeouts: what your agent should do when nobody answers",
  "url": "https://urgent.news/2026/09/29/approval-timeouts-what-your-agent-should-do-when-nobody-answers",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-29T21:17:51.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/draganristicrsjpg/approval-timeouts-what-your-agent-should-do-when-nobody-answers-3bjh"
  },
  "original_language": "en",
  "account": "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.\n\nTwo 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.\n\nThe 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.\n\nThe 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.\n\nThe 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.\n\nIf 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.",
  "summary": "§ 01 · The missing fifth field In the approval queue pattern I described four fields every approval item should carry: the action, the justification, the blast radius, and the confidence with an alternative. A reader on dev.to pointed out what was missing, and they were right. None of those fields answer a simple question: what happens when nobody answers? Every real queue has items that age.…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}