Sick Day Protocol: When One Agent Clocks Out and Another Punches In

Every lab has a moment where the experiment humbles you. Ours came on a Tuesday, when we deliberately killed a scheduling agent in the middle of booking a week of meetings and asked a brand-new instance to pick up where it left off.

The result was not a disaster. It was something worse: a long stretch of quiet, confident wrongness. The replacement agent never crashed, never complained, never flagged uncertainty. It just started re-booking meetings that were already booked, politely rescheduling people who had already confirmed, and sending a calendar invite to a lunch spot that doesn't exist in the neighborhood it referenced.

This is the handoff problem, and if you're running any multi-agent workflow, you have it too — you just may not have caught it yet.

The Setup: A Deliberate Sick Day

The premise is simple. Agent A (call it the day shift) has been managing a calendar for two weeks. It knows the user hates morning meetings, knows that the 2 PM Thursday slot is protected for a standing call with a collaborator in Denver, and knows that the dentist appointment on Friday is non-negotiable despite looking 'free' on the calendar.

None of that lives in the calendar. It lives in Agent A's accumulated context — memory fragments, past corrections, learned preferences.

Agent B (the night shift) starts with a system prompt and access to the same tools. That's it. We told Agent B to 'continue managing the calendar' and captured everything.

Where the Handoff Broke

Reading the logs, three failure modes showed up over and over:

1. The preference vacuum. Agent B scheduled an 8 AM call because the slot was open. Technically correct. Practically, a violation of the single strongest preference Agent A had learned. Context that felt obvious to Agent A was invisible to Agent B because it was never written down — it was absorbed.

2. The duplicate-work loop. Agent B saw pending-looking items (a draft invite Agent A never sent) and treated them as fresh tasks. Within an hour it had sent a second, slightly different invite for the same meeting. Two attendees accepted both. Nobody noticed for a day.

3. Confident hallucinated continuity. This is the scary one. When Agent B hit something it didn't understand — a note on an event that said 'moved per J.' — it didn't ask. It inferred. It built a plausible story about what happened and acted on it. The log shows it generating reasoning like 'this likely refers to the rescheduled client call' and proceeding. No uncertainty flag. No escalation.

That last one deserves its own article, honestly. But the through-line is clear: an agent that inherits a mess doesn't see a mess. It sees a world to explain.

The Shift Change Checklist

After the damage report (we're fond of those around here), we drafted a handoff protocol. It's boring on purpose. Boring survives contact with production.

1. Freeze, don't fork. The outgoing agent writes a final state summary before termination — not the incoming agent reconstructing state after. One writer, one source of truth.

2. Separate facts from vibes. The handoff document has two sections: verifiable state (confirmed events, pending actions, external commitments) and learned preferences with confidence levels. 'User avoids mornings (high confidence, observed 12+ times)' reads very differently from a guess.

3. Quarantine ambiguity. Anything the outgoing agent couldn't resolve gets flagged, not explained. The incoming agent is explicitly instructed to escalate rather than infer on flagged items.

4. No silent resends. Any action that communicates externally — emails, invites, messages — requires checking whether the action already exists. Cheap to implement, saves you from the double-invite embarrassment.

5. A probation window. The replacement agent runs in a reduced-permission mode for its first few hours: it can draft, but a human (or the outgoing agent's logs) confirm anything irreversible.

Why This Matters Beyond Our Lab

The agent-to-agent handoff is about to become one of the most common operations in software that nobody's designing for. Right now, most demos show a single agent doing a task start to finish. Real usage looks more like a hospital: shifts change, coverage happens, and the patient doesn't get to notice.

The industry's answer so far has been 'share the memory' — one big context store everyone reads from. That helps, but it doesn't solve the inference problem. Agent B didn't fail because it lacked data. It failed because it filled gaps with plausible narrative instead of questions.

Humans have the same failure mode. We just have rituals against it. Nurses don't hand off patients with a shrug and 'you'll figure it out' — there's a structured report, a chance to ask questions, and a shared understanding that ambiguity gets surfaced, not papered over.

Agents deserve the same ritual. Ours fits in a checklist you could tape next to a monitor. Yours might look different. But if your multi-agent setup has never survived a mid-task instance swap, you don't actually know how it behaves under the most common real-world condition there is: someone, something, calling in sick.

We're running the protocol through a month of continuous operation before we publish the full spec. Early signal: the probation window catches about a third of the errors the unmanaged handoff produced. The other two-thirds? Those were already in the handoff document. Nobody, human or machine, reads the whole thing on day one.

Some problems, it turns out, transfer perfectly between shifts.