Glossary
Agent handoff
An agent handoff is the point where work passes to a person or to something else, and it is where the arrangement most often loses what it knew.
In plain terms
The moment the work changes hands. Something has been going along on its own, then a person picks it up, or another part of the system does. It sounds like plumbing. It is where the customer repeats themselves, and where whoever receives the job cannot tell what was already tried.
Why it matters
Because the receiving side almost never gets what the sending side had. What crosses is a result and perhaps a summary; what stays behind is everything considered and rejected on the way. That gap is invisible from either end, and it is the reason handovers feel worse to the person on the receiving end than to anyone who designed them.
How it works
Two directions and they are not symmetrical. Passing to a person means somebody has to reconstruct enough to continue, and their time is the expensive resource. Passing to another part of the system means a summary is written by something with no view of what the next part will need. Both lose material and only the first one complains.
The trigger is a design decision that is usually a default. Handing over on failure is the obvious rule and it is the worst one, because by then the work is already in a poor state. The better triggers are earlier and less dramatic: a threshold of uncertainty, a category of request, an action that is about to become irreversible.
What travels decides whether the handover works. A result alone forces the receiver to start again. What was attempted, what was ruled out and why, and what the original request actually said are the things that make continuation possible, and none of them crosses by default because nothing produced them as an artefact.
Products treat this as a headline feature, which is a good sign about how much it matters. Support tools describe handing to a live person when the limit is reached, and enterprise platforms describe agents resolving conversations end to end rather than deflecting them. Both framings are claims about the same moment: whether the handover is a continuation or a restart.
What the sending side had, and what arrives
Seen in the wild
A support tool that answers from help content and hands to live chat when it reaches its limit, which makes the boundary an explicit product feature.
Tidio LyroAn enterprise platform describing conversations resolved end to end rather than deflected, which is a claim about how rarely this moment arrives.
SierraA platform where work runs on triggers and the rules it must follow are set when the job is described, which is where the trigger for stopping gets decided.
Lindy
Common misconceptions
People assume
It is a fallback for when things go wrong.
In fact
That is one trigger and the least useful one. Handing over only on failure means the receiver inherits a mess, having spent the budget getting there. Triggers that fire earlier, on uncertainty or on a category of request or before something irreversible, pass on work that is still in good order.
People assume
The receiver can see what happened.
In fact
They see a result and possibly a summary. What was tried and abandoned, and why, is not recorded anywhere unless somebody built that, so the receiving side frequently repeats work that was already done and discarded. Nothing in the handover signals that this is happening.
Telling them apart
Agent handoff vs Human in the loop
Agent handoff
The moment work changes hands, in either direction.
The standing arrangement that puts a person at a decision point.
The loop is the design; the handover is the seam in it. Seams are where things are dropped.
Questions
- What makes one work?
- What crosses with it. A result alone forces a restart; the request as originally stated, what was attempted and what was ruled out make continuation possible. None of that is produced automatically, so it exists only if somebody decided it should.
- When should it happen?
- Earlier than failure. Uncertainty above a threshold, a category of request known to be unsuitable, or an action about to become irreversible are all triggers that pass on work in a recoverable state. Waiting for something to go wrong hands over the worst version of the job.
- Is passing to another part of the system easier?
- It is quieter, which is not the same. A person who receives too little says so; a downstream component receives a summary written without any view of what it needs and continues regardless. The loss is identical and only one of the two directions generates a complaint.
Key takeaways
- Two directions, and only the one involving a person complains.
- Handing over on failure is the obvious trigger and the worst one.
- A result crosses; what was tried and rejected does not, unless somebody built that.
- The receiving side usually repeats work, and nothing signals that it is happening.
Tools that use this
- Tidio Lyro
Hands to live chat at the bot's limit, making the boundary explicit.
- Sierra
Conversations resolved end to end rather than deflected to a person.
- Lindy
Trigger-run work where the rules for stopping are set up front.
Last checked July 2026