The Handover Problem: Agents, Sick Leave and Half Finished Work

Your agents drafted eleven things on Monday. The one person who approves them called in sick on Tuesday. By Thursday nothing has shipped and nobody noticed, because a queue that is not moving looks the same as a queue that is empty.

The fix is a named fallback approver with a clear trigger, not a rule that says anyone can approve. Fallback to everyone is fallback to nobody. It also needs the work in progress to be visible, because pending approvals are only half the problem: the other half is work an agent started against records that changed while the approver was away.

What actually breaks

Three separate things go wrong, and teams usually only plan for the first.

Pending approvals stall. Obvious, and the easiest to fix.

Work goes stale. A draft written on Monday against Monday's records may be wrong by Thursday, which is the argument for an agent reading the project board before it answers anyone. The client moved the date, the task got reassigned, the figure changed. When the approver comes back and clears the queue quickly, they are approving yesterday's answers to today's questions.

And nobody is watching the queue itself. The absent person was the alarm as well as the approver. With them away, there is no one whose job it is to notice that eleven items are waiting.

Why "anyone can approve" is not a fallback

The instinct is to widen permission when someone is away. It feels safe because more people can act.

In practice a shared responsibility with no owner produces slower action, not faster. Everyone assumes someone closer to the work will handle it. The items that get picked up are the easy ones, and the item that actually needed judgement sits longest, because it is the one nobody wants to own.

There is a second problem. A wide approval pool weakens the record. When you look back at why something shipped, "approved by whoever was around" is a much worse answer than a name with a reason.

Designing a fallback that holds

A fallback works when four things are decided in advance.

• One named person, not a group. A second name is acceptable if the first is also away, but it is still a name.
• A trigger with a number in it. After one working day unattended, or immediately on a leave record starting, but decided rather than judged in the moment.
• A narrowed scope. The fallback approver may not need the same authority. A sensible pattern is that they can approve routine items and can only defer anything above a threshold you set.
• A note requirement. The fallback approver writes one line saying why they approved. It takes ten seconds and it is the thing that makes the record readable later.

The trigger is the part most often left vague. "If they are away for a while" is not a rule. A system cannot act on it, and neither can a nervous junior colleague.

This is where it helps for leave records and approval routing to sit on the same set of records, which is how SicherOne is built. If the system already knows a person is on leave, the handover does not depend on somebody remembering to switch a setting on their way to the doctor.

Half finished work is the harder half

Pending approvals are visible. Work an agent started and cannot finish is not.

Before approving anything that has been sitting, the fallback approver should check the thing the draft was based on rather than the draft. The agent will not flag the gap itself, which is what managers get wrong about agent memory. Has the record changed since. Is the person it was addressed to still the right person. Is the date still the date.

A practical rule: anything older than the absence itself gets regenerated rather than approved. It sounds wasteful. It is far cheaper than sending a confident, out of date message to a client.

For long absences, the better move is often to stop the agent producing more of that work type until someone can review it properly. A growing queue of unreviewed drafts is not progress being stored up.

Test it before you need it

Handovers that were designed but never used tend to fail on the small things: the fallback approver does not have access, does not know the trigger fired, or does not know what threshold applies to them.

Run it deliberately once. Pick a quiet week, have the usual approver step back for two days, and see what happens. What you learn is not whether the design is sound. It is which three practical details nobody wrote down.

The goal is not that work continues at full speed while someone is off. It is that the queue is visible, the person covering it is named, and nothing stale gets approved because it was easier than checking. All three get simpler when project boards, leave calendars and agents share one set of records.