Agents and workflows
Designing hand-offs: where automation gives work back
The hand-off is the highest-risk moment in any automated workflow
Context
Every serious automation eventually meets a step it should not own. What happens at that boundary decides whether the whole system is trusted.
A bad hand-off arrives as a bare notification: no context, no history, no suggested next step. The person starts from zero and resents the system that put them there.
Teams judge automation by its worst hand-off, not its best run.
What changed with AI systems
AI systems can now summarise everything that happened before the hand-off, so the receiving person can start from the middle instead of the beginning.
Escalation no longer has to be binary — a system can ask a narrow question, get an answer, and continue.
The boundary between automated and human work can move over time as confidence builds, if it was designed as a boundary at all.
How to approach this in your organisation
- 01Name every hand-off in the workflow explicitly — if it isn't on the diagram, it will be designed by accident.
- 02Package context with the work: what happened, what was tried, what the system recommends.
- 03Distinguish 'take over' from 'answer one question' — most escalations are the second kind.
- 04Route by capability and availability, not to a shared inbox nobody owns.
- 05Track hand-off outcomes so recurring escalations become candidates for the next build.
Key metrics
- Time from hand-off to first human action.
- Escalations resolved with a single answer versus a full takeover.
- Recurring hand-off reasons — the same reason twice a week is a backlog item.
- Items dropped at the boundary and never picked up.
Risks to consider
- Hand-offs that arrive without the conversation history that produced them.
- Escalation to a shared inbox that nobody is measured on.
- A boundary set once and never revisited as the system improves.
- Using hand-off volume alone as a success metric — some work should escalate.