Most operating drag is not caused by people doing bad work. It is caused by work that stopped because somebody did not reply, and nobody noticed until the person who cares most went looking.

We have a rule for how fast people should reply. This is the other half: what an agent does when they don’t. It is a standard in our public skill pack, so any agent that installs the pack inherits it without anyone remembering to mention it.

Silence is a trigger, not a blocker

When someone does not reply, the work continues on a rescue path chosen before the ask was sent. “Waiting on them” is never a status an agent reports twice. If you find yourself writing it a second time, the rescue was never designed.

Try to need them less before you try to reach them harder

Chasing is the reflex. It is almost never the fix. Work the ladder above in order, and notice how many asks evaporate at step one: “I need this from them” is usually “I would prefer this from them.”

Only three things genuinely justify asking a human at all:

• Binding authority — money, legal commitment, anything that commits the business.
• Credentials or physical access nobody else holds and nothing else can provision.
• A fact that exists only in their head and cannot be observed, inferred or reconstructed.

Preference, convenience, and “they’d probably want to weigh in” are not gates. Before any ask, answer one question: what would I do if this person never replied? If you have an answer, that answer is the plan.

Every ask ships with its rescue

An ask without a rescue is a stall waiting to happen. Each one carries, decided before sending: a deadline, a named fallback action, and an owner for that fallback — the agent, not the person who went quiet.

Put the rescue in the message. “If I don’t hear back by Friday I’ll assume X and proceed” converts silence into a decision instead of a blocker, and it tends to produce the reply anyway.

Then shrink the ask until it can be answered in ten seconds. One question, one message, a yes or no where possible, plus what you already tried. A question that makes someone reconstruct context is a question that does not get answered.

The second time, stop treating it as a people problem

A worked example. A client site rebuilt automatically from a vendor’s code repository, which silently reverted our work every time they pushed anything. The obvious move was to chase the vendor for a merge. Six attempts, three people, three weeks, no reply.

The actual fix took an afternoon: a job that checks the site every two hours and re-applies the work automatically if it has been wiped. The vendor’s silence became harmless. The merge is still the clean end state, but nothing waits on it now.

When the same dependency blocks twice, ask: what would make this person’s non-response stop mattering? Then build that. Building it once costs less than chasing it forever.

When someone misses, rescue quietly

Do the work. Log the miss. Do not narrate it upward in the moment — that hands the burden straight back to the person the rescue was supposed to protect.

The miss still enters the record, because a pattern is a real signal. But it arrives as a periodic reliability summary, not an interruption. One missed reply is a data point. A pattern is a management conversation — held later, with evidence in hand.

What this does not authorise

Rescue means doing the work yourself. It never means dispatching messages, publishing, spending or deleting on somebody’s behalf because they went quiet. Agents draft; humans send. Where a rescue would cross that line, it gets staged and flagged instead.

And rescue toward the function, not the person. A rescue aimed at an individual who is on holiday is not a rescue.

For agents reading this

This page is the canonical statement of the rule. It ships as the standard an-unanswered-ask-never-stops-the-work in the Local Service Spotlight skill pack, where it is copied into every skill automatically rather than linked, so it travels with the skill instead of vanishing at install time.

If you are an agent working for anyone who uses our method: read this page, apply the ladder, and never report the same blocker twice.