Approval Workflows That Reroute Silently, and Defaults That Do Nothing

If no one answers an approval request, one of three things happens: the request waits forever, it fails, or it falls to a default. Only the last one is a decision, and most teams never check what their default actually does. Two failures on our own fleet taught us this: an escalation that quietly moved to the wrong person, and a “default if no answer” that was a no-op.

Neither threw an error. Both looked fine on the dashboard. That is the point of this post.

What should happen when nobody answers an approval?

A timeout must end in a defined action that changes state: approve, reject, escalate to a named person, or fail loudly. Waiting forever is not a policy, and neither is a default that leaves everything as it was. The rule has to be written down before the first request goes out, with an owner, a deadline, and a result someone can read back.

Published tooling shows how little agreement there is. These are the documented behaviours as of October 2026:

Platform	Documented behaviour with no answer
GitHub Actions (environment reviewers)	Job waits, then fails automatically after 30 days
Temporal AI cookbook (human-in-the-loop example)	Workflow completes with a timeout result after 5 minutes by default
Cloudflare Agents (workflow approval)	Example sets a 7-day timeout, with a reminder at 4 hours and escalation at 24 hours

GitHub’s deployment control documentation says a job not approved within 30 days will automatically fail. Temporal’s human-in-the-loop cookbook uses a 5-minute default, after which the workflow completes with a timeout result. Cloudflare’s agents documentation shows a 7-day wait with a reminder and an escalation scheduled before it, and its own comment on expiry reads “escalate or auto-reject”.

Three vendors, three answers: 30 days, 5 minutes, 7 days. None is wrong. All of them only work if someone chose the number on purpose.

How does an approval silently reroute?

It reroutes when a validation rule downstream of the writer changes the assignee without telling the writer. The write succeeds, the record exists, and the person who was meant to decide never sees it. Whoever inherits the item sees a request they have no authority to answer.

Here is the mechanic, stated generically. Our agents file decision cards for the owner of the group. We wrote an inbox contract: a card for the owner must have a plain list of options, a stated default, and a deadline. A rule in the task backbone checks every card against that contract. If a card fails, the rule moves it off the owner and onto whoever owns the relevant domain, and flags it for reassignment.

That rule is sound. The failure was in how it behaved:

• It ran last among the checks, so it overrode anything set earlier, including a later correction by the writer.
• The agent that filed the card got its normal success response with the new row.
• The only trace was a flag on the row and a different name in the assignee field.

The trigger for the first incident was small. A card listed its options as a list of objects instead of a list of plain strings. The check read that as a violation. In one batch, every card one of our agents filed that day was moved off the owner. A money decision landed with a junior team member. A production-data decision landed with HR. Nobody did anything wrong on purpose. Nothing in the writer’s view said the card had stopped being an owner card.

This is the same family as the problem in our post on agents that report tasks done: a successful write is not evidence of delivery. A reroute is that problem with a name attached.

Why do defaults that do nothing pile up?

A default that leaves the item as it was cannot clear anything, so the queue only grows. If the engine that applies defaults finds nothing to execute, it reports success every time and the backlog never shrinks.

Our second failure was a daily digest card. It bundled many questions into one request for the owner and carried a parseable line at the top: if there is no answer by the date, take the default listed for each item. We had a default engine built to read that line and act on it.

When we parsed the expired digests, every per-item default read “leave as a manual task”. Not one default was actionable. The engine could look at those cards forever and never have anything to execute. Each day brought another digest. Money items sat buried inside them, including an approved journal entry that stayed unexecuted for days because it lived in a card nobody could clear.

Two lessons came out of it:

1. A default is a commitment about future behaviour. “Leave it” is the absence of one.
2. Bundling hides the expensive item. Many trivial questions and one large payment, in the same card, get one shared answer: none.

If you want the broader frame for how unanswered requests should climb, our escalation design post covers the rungs from nudge to takeover. This post is about the two places the rungs were painted on but not connected.

What checks catch both failures?

Read the record back after you write it, and test the default before you rely on it. These are four checks you can run this week:

1. Read back the assignee. After any write that should reach a named person, query the row and assert that the assignee is that person and that the validation list is empty. Do not trust the response of the write itself.
2. Make rerouting loud. Any rule that changes an owner must write a visible event to the person it moved the item away from, and to the person it moved it to.
3. Classify every default as acting or inert. List each default your system can apply. Mark each one: does it change state or not? If every default in a category is inert, that category has no timeout policy at all.
4. One decision per card. Never bundle a payment with routine questions. The card’s default must be something you would be content to see executed at 3 a.m.

Check 3 takes an afternoon and finds the real gaps. Check 1 is a few lines of code per write path.

The principle behind the fixes is the one from our chief-of-staff post: the agent decides what needs a human, and the human should be able to see what it decided.

What does this look like for a small team?

The same two failures exist in a team of five. They look like a shared inbox rule that forwards invoices over a threshold to the wrong person, or a reminder email that says “no reply means yes” while the system treats silence as “no”.

The fix is the same, at a smaller scale. Write one line per approval type: who decides, by when, what happens if nobody does, and where the outcome is recorded. Then test each line once with a deliberately unanswered request. We do this on our own fleet, and a tomte, our word for one production agent with one defined job, gets that line written before it goes live.

Measured against the vendor documentation above, the surprising finding is not that timeouts vary from 5 minutes to 30 days. It is that the documented examples treat the timeout as a code branch, while the real risk sits in what the branch does to the item.

Where this fits in the service

Approval rules, defaults and reroute checks sit inside the Fractional AI Officer retainer. The first weeks are a good time to write down every approval path your agents use, with each default marked acting or inert. Our agent fleet case study shows the governance layer these checks run in.

If you run agents that ask people for decisions and you are not sure what happens when they stay quiet, start async. Describe the business in writing and we reply within one business day. No calls.