By KYN AI Advisory Team — AI implementation specialists, Singapore
Retry logic is built for machine failures: a timeout, a 500 error, a dropped connection. A manager who is in meetings for six hours is not a failed endpoint. When an operations agent treats a slow approver like a crashed API, it does one of three bad things: it pings them repeatedly, drops the ticket, or proceeds without sign-off. For anything involving money, contracts or client documents, the fix is an explicit "waiting on a person" state, a capped escalation path and a lightweight confirmation step.
We have no measured dataset of approver response times, so treat every threshold below as a starting point. Set real thresholds from your own ticket logs.
Why do operations agents abandon tickets?
Because the system has no state for "waiting on a person" that differs from "resolved" or "abandoned." Without it, three things happen.
- Redundant pings. The agent re-sends the request every N minutes. The approver mutes it.
- Silent drops. After the retry limit, the ticket closes or falls off the queue. The requester believes it is in hand.
- Proceeding without sign-off. A "timeout means approved" default pushes the item through. This is the worst case, because the error only appears later.
Reconciliation queues show the same disease. A refund and its charge that are never recognised as a pair stay in a queue meant for undecided items, until the queue is a dumping ground. A ticket waiting on an approver and a ticket nobody is handling need different states, or they merge into one backlog.
Why does a single timeout fail multi-step approval?
One fixed wait and one automatic action cannot tell apart three situations: a ticket that needs a nudge, one that needs a backup approver, and one that needs escalation past the first approver. A multi-step chain needs a capped sequence, with a defined exit at each step.
We reject two other designs in our own agents. An unbounded loop never ends if the reviewer never signs off. A single one-shot pass with no recovery ships whatever comes out. The workable shape is a bounded number of rounds with a conditional step back, and a hand-off to a person when the cap is reached.
What does timeout-driven abandonment cost?
We have no measured figure, so this is reasoning from the failure modes. The work does not vanish. It reappears elsewhere.
- A dropped ticket is resubmitted and restarts the clock with no memory of the first attempt.
- An approver pinged three times often gets bypassed informally by chat or a word in the corridor. That approval never reaches the system of record.
- Someone on the operations team pushes the ticket through by hand, outside the tool.
Each is a symptom of the missing state. Fix the state first.
What design rules prevent it?
1. Separate delivery from decisions. A watchdog retries technical failures: a notification that did not send, a webhook that errored. It owns delivery. It must not own the question of how long to wait for a human. Once delivery is confirmed, the clock belongs to the escalation path.
2. Ask over assume. When a sign-off is overdue or ambiguous, the agent has two ways to be wrong.
| Default | Failure | |---|---| | Assume approved and proceed | Fast, and wrong when it matters: a missed objection, a stale price, a compliance flag | | Ask again or escalate | Slower; the cost is a delay |
A false yes costs more than a delay. Default to ask.
3. Widen only with a second signal. In reconciliation we widen matching tolerance only on a second pass, and only when an independent signal corroborates it. For approvals: reroute to a backup approver, or accept a lower-authority sign-off on a small item, only when a defined condition is met, not as a general fallback.
4. Give stalled tickets an explicit state. Waiting, nudged, escalated, expired. Each has an owner and a next action.
5. Cap retries and name the exit. After the last step the ticket goes to a named person, never back into the void.
6. Log every step. Who was asked, when, what they answered, who overrode whom. This is also your audit trail.
How do you make the confirmation step lighter?
The more a sign-off demands, the more likely it times out. A "does this look right" check, with the document and the key figures on one screen, clears in seconds. A step that asks the approver to rebuild and verify every field invites delay.
In our quotation-drafting agent a person always confirms before a document goes to a client, and the confirmation is a review, not data entry. In a system we build, outbound messages, money, filings and deletions wait for a named person, so the quality of that checkpoint decides how fast work moves. Lighter checkpoints mean fewer tickets reach the point where a timeout has to make a hard call.
What must be right before you tune timeouts?
The escalation graph. Who is the approver, who is the backup, who is notified after that, and what happens when someone is on leave. A retry policy on top of a stale approver directory will fail for reasons unrelated to timing. This mirrors integration work with external systems: reference data has to be correct before transactions that depend on it are accepted.
Check:
- every approver has a named backup;
- delegations are recorded with start and end dates;
- the approval limit for each role is written down;
- leavers are removed the day they leave.
How do you set timeout thresholds without data?
Measure first.
- Export 90 days of approval requests with request time, response time, approver and outcome.
- Compute the median and 90th-percentile response time by approver and by request type.
- Set the first nudge a little above the median. Set the escalation near the 90th percentile.
- Review monthly, and change one threshold at a time.
Test against the real history in a safe copy, not against assumed behaviour. A policy that passes every case the designer imagined can still fail on how approvers actually behave in a heavy week.
What does the waiting state look like in practice?
The timeline below is illustrative. It follows one purchase approval through a capped chain. Thresholds are placeholders, set from your own logs as described later.
| Time | State | What the agent does | Who is responsible | |---|---|---|---| | 09:00 | Requested | Sends the approval card to the first approver; confirms delivery | Approver 1 | | 09:00 | Waiting | Starts the clock; no retries of the card itself | Approver 1 | | 13:00 | Nudged | Sends one short reminder with the key figures | Approver 1 | | 16:00 | Escalated | Routes to the named backup; tells the requester | Approver 2 | | Next day 10:00 | Escalated, second level | Notifies the named owner of the process | Process owner | | Next day 15:00 | Expired | Closes the request as "not approved", records why, tells the requester to resubmit with a reason | Requester |
Three things are different from a plain retry loop. The delivery of the card is checked once, then left alone. Each step has a named person, not "the queue". And the final state is "not approved", never "approved by default".
Which states does the ticket need?
Give each state a definition, an owner and a next action. Without that table, the states drift into meaning the same thing.
| State | Meaning | Owner | Next action | |---|---|---|---| | Requested | Sent, delivery not yet confirmed | System | Retry delivery on failure only | | Waiting | Delivered, no answer yet | Approver | Clock runs | | Nudged | One reminder sent | Approver | Clock continues | | Escalated | Moved to a backup or owner | Backup or owner | Same checks, shorter clock | | Approved or Rejected | Decision recorded with actor and time | None | Work proceeds or stops | | Expired | No decision within the cap | Requester | Resubmit, or process owner decides |
A dashboard that counts tickets by state shows where work stalls. If 40 tickets sit in "Waiting" with the same approver, the problem is a person's calendar, not the system.
What edge cases break approval chains?
- Approver on leave. Delegations need start and end dates. When no delegation exists, the system routes to the backup at once and does not start the first clock.
- Request changed while waiting. A quote revised after the first approval request makes the earlier answer stale. A change to an amount, a supplier or a date should cancel the open request and send a new one, with both versions in the log.
- Approver is the requester. Block it. The chain needs a second person.
- Parallel approvals. Two approvers sign independently. Decide in advance whether both must agree, or whether the first answer wins, and what happens if they disagree.
- Public holidays. Pause the clock on non-working days for the approver's region, or the weekend will expire every Friday afternoon request.
- Approval by chat reply. If the approver answers in a message thread, a human or a strict parser must record it in the system. A "yes" in a chat that nobody logs is a gap in the audit trail.
- Approval fatigue. An approver who sees 60 requests a day starts approving without reading. Batch small items, route low-value ones to a lower authority and keep the full process for items that matter.
How should you size the approval limits?
Limits decide how many tickets reach a senior person. Set them from your own approval history.
- List the last 90 days of requests by amount band.
- Count how many each band produced and how many were rejected or changed.
- Move a band to a lower authority if it was almost never rejected and the sums are small.
- Keep any band where a rejection or a change was common, even if the amounts are small.
A band that is rarely rejected is a candidate to approve in a weekly batch rather than one by one. A band that is often changed needs a better request form, not a faster approver.
How do you test the chain before it goes live?
Run these four tests in a safe copy of the environment.
- The silent approver. Send a request and say nothing. Confirm that each state change fires at the right time and the ticket ends in "Expired", not "Approved".
- The absent approver. Mark the first approver as on leave. Confirm that the request goes to the backup without waiting.
- The changed request. Edit the amount mid-wait. Confirm that the open request is cancelled and a new one starts.
- The delivery failure. Make the notification fail. Confirm that the watchdog retries delivery and that the approval clock does not start until delivery is confirmed.
Record the result of each test. Run them again after any change to approver lists or limits.
Which numbers show that the chain works?
Review five numbers monthly.
- Median and 90th-percentile time to decision, by approver and by request type.
- Share of tickets that reach "Escalated", which should fall as the approver directory improves.
- Share of tickets that reach "Expired", which should be small, and each one should be explained.
- Number of approvals recorded outside the system, found by comparing chat records against tickets in a sample.
- Requests changed after the first send, which points to weak request forms.
A rising "Expired" share means approvers are not seeing requests, or the cap is too short. A rising "outside the system" count means people find the tool harder than chat, and the fix is a lighter confirmation step.
What does a worked threshold calculation look like?
The data below is invented to show the arithmetic. Use your own export.
Suppose 90 days of purchase approvals show these response times for one approver, in hours, across 10 requests: 1, 1, 2, 2, 3, 3, 4, 6, 9, 26.
- The median is 3 hours. Half the requests were answered within 3 hours.
- The 90th percentile is about 9 hours. Nine of ten were answered within that time.
- The single 26-hour answer fell over a weekend.
A first nudge a little above the median, say at 4 hours, catches the slow half without bothering the fast answers. An escalation near the 90th percentile, say at 9 working hours, fires on the real outliers. The 26-hour case is handled by the holiday and weekend rule, not by a longer timer.
Set separate thresholds by request type when the data supports it. A routine reorder and a contract change do not deserve the same clock, and a long clock for contracts hides delays in reorders if you use one number for both.
What should the requester see while they wait?
The requester is the person most likely to create duplicates. Show them the state, the name of the current owner, and the time of the next step, in plain words. For example: "Waiting on the purchasing manager since 09:00. If there is no answer by 13:00, a reminder goes out. If there is none by 16:00, it moves to the backup." This single line removes most resubmissions, because the requester no longer needs to ask.
When a ticket expires, tell the requester why and what to do next. A message that says only "closed" sends them back to the start with no information, and recreates the problem you were fixing.
How is this different from a normal retry policy?
| Aspect | Retry policy for machines | Escalation policy for people | |---|---|---| | What fails | A call, a connection or a service | A person is busy, absent or unsure | | Wait pattern | Short and growing, often in seconds | Hours, tied to working time | | Repeat the same request? | Yes | No: nudge once, then change the route | | Final fallback | Alert an engineer | Named owner decides or the item expires | | What is logged | Error code and attempt count | Actor, time, answer and any override | | Risk of the wrong default | A duplicate call | A wrong approval on money or a contract |
Keep both policies in the system, applied to the correct layer. Retries cover the delivery of the request. Escalation covers the decision.
Where KYN fits
KYN builds operations agents in your own cloud account with explicit states for waiting, nudged and escalated tickets, capped paths and a log of every action with the actor. Money, filings and deletions wait for a named person. A live example is a manufacturer's morning reports at 06:30 to each department on WhatsApp, with overdue approvals listed by name. See operations systems and our guide to setting approval gates for high-risk agent actions.
The first 14 days are a review of your approval flows and logs. A full build ships in under 90 days.
Frequently asked questions
What should an agent do when an approver does not respond?
Send a reminder, then route to a named backup, then escalate to a named owner. Each step has a wait time and a record. It should never treat silence as approval.
Should a watchdog retry approval requests?
Only to make sure it is delivered. Once the request is delivered, waiting on a human is an escalation question, not a retry question.
How do you choose the wait time before escalation?
Use your own history. Set the first nudge slightly above the median response time and the escalation near the 90th percentile, then adjust monthly.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
