A retry that never sends twice

Something will interrupt it

Automation that runs for weeks without anybody watching it will be interrupted. A machine restarts. A release goes out at two in the afternoon. A call to another service hangs long enough that something gives up waiting. None of this means anything is wrong; it is simply what running continuously looks like over a long enough period.

So the interesting question is not how to avoid interruption. It is what the work does on the way back, in the seconds after it resumes and has to work out what it had already done.

The duplicates that actually cost something

Three of them matter, and a recruiter meets all three from the wrong end.

• A second email to the same candidate. Two copies of the same follow-up in one afternoon does not read as enthusiasm. It reads as a machine that is not being watched, and it is the one piece of evidence a candidate needs to stop replying to your address.
• A duplicate interview booking. Two holds on a calendar for one conversation, or a candidate asked to choose a slot they have already chosen. Both make the candidate do your reconciliation for you.
• A second charge. Some steps in a search cost money. Paying twice for one piece of work is the version of this that shows up in a budget rather than in an inbox.

They are not equal in cost, but they say the same thing to whoever receives them: nobody is home.

Claimed before it runs, recorded once it has

Every piece of outbound work on EmployLabs is claimed before it is carried out, and recorded once it has been.

The claim is the part that does the real work. Once a piece of work has been claimed it cannot be picked up a second time, so a process coming back after a restart is reading a ledger of what is already in hand rather than a list of intentions it has to run again from the top.

The record closes it. When the email has gone, the booking is made or the paid step is done, that outcome is written down as a fact rather than inferred later from whatever state the system happens to be in.

The order of those two is the whole point. The dangerous window in any unattended system is the gap between deciding to act and knowing that you did, and claiming first is what keeps anything from entering that gap twice.

A resumed sequence should look, from the candidate’s side, exactly like one that was never interrupted.

Why this cannot be a retry setting

The usual answer to unreliable work is to retry it, and retrying is genuinely necessary. A step that failed because something was briefly unavailable should be tried again.

But a retry count is a guess, and the failure that produces duplicates is exactly the one where you cannot tell whether the first attempt worked. Send it once more to be safe, and somebody gets two emails. Hold it back in case it already went, and somebody gets none. Both instructions are wrong, because the question they are answering is a question about the past and neither of them looks at the record.

Claiming and recording remove the guess rather than tuning it. A stuck send is re-sent only while the email provider can still recognise it as a duplicate. After that window it goes to a person rather than being re-sent blind.

What this changes for your week

• You do not audit outreach after a release. Nothing needs checking for double sends, because the resumed work is reading what already happened.
• Candidates never see the machinery. The experience of a sequence that was interrupted is the same as the experience of one that was not.
• An interruption does not spend twice. Work that costs money is claimed before it is paid for, so coming back does not re-buy it.

There is nothing to switch on

This is a property of how work is carried out rather than a feature with a setting, which means the only evidence you will ever have of it is an absence. No candidate writing back to ask why they received the same message twice. No second hold to cancel on a hiring manager’s calendar. No line in the spend you cannot account for.

That is an unsatisfying thing to demonstrate and a very good thing to have. Unattended automation is judged on its worst day rather than its ordinary one, and its worst day is almost always the one where something stopped halfway through.