Handoff

All steps

Normal run

1. Request arrives. Triage reads the message. It resolves nothing itself; its only job is selecting a specialist.
2. Classify. Triage classifies the request as a returns case.
3. Transfer ownership. Control passes to Returns entirely. Triage leaves the loop: whoever holds the task owns it.
4. Specialist executes. Returns has the tools and instructions for exactly this case type.
5. Respond. Refund approved. One handoff and no coordinator in the path, so latency and cost stay low.

Outcome: correct answer. The request mapped cleanly to one specialist, so a single transfer resolved it without a central bottleneck.

Failure mode

1. Request arrives. Identical start to the normal run.
2. Transfer to Billing. The word “refund” reads as a payment matter, so Triage transfers the task to Billing.
3. Billing transfers on. Billing sees “damaged” and classifies it as a shipping issue.
4. Shipping returns it. The parcel was delivered on time, so Shipping rejects ownership and sends it back to Triage.
5. Cycle repeats. Triage makes the same decision again. Nothing in its context records the previous attempt.
6. Cycle repeats. Each hop carries a longer history, so every transfer costs more than the previous one.
7. Cycle repeats. The customer is still waiting.
8. Budget exhausted. Six transfers and no response. No agent was wrong in isolation; the system had no owner and no hop limit.

Failure: handoff cycle. A → B → C → A is the most common failure of handoff systems. Mitigation: cap transfers, carry the hop history with the task, and escalate to a human at the limit.