Skip to content

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.

01

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.

02

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

What the sending side had, and what arrivesThis is the seam that makes delegated work feel worse to use than it looks on a diagram. From the outside a handover is a single arrow, and the arrow implies continuity. What actually crosses it is whatever somebody thought to pass, which is nearly always the outcome and nearly never the working. The receiving side therefore begins by reconstructing: a support agent asks the customer to explain again, a downstream component re-fetches something already fetched, a person picking up a half-finished job tries the approach that was tried and abandoned an hour ago. None of that shows up as a failure, because the work does eventually get done. It shows up as the arrangement being slower and more irritating than the version in the diagram, and as customers who say they had to repeat themselves, which is the most common complaint about automated support and is a description of exactly this seam.Held before the handoverThe request as originallystated.Everything attempted so far.What was ruled out, and why.How confident it was at eachstep.Arrives with itA result.Sometimes a short summary.Rarely the reasoning.Almost never the discardedattempts.The gap between these columns ispaid for by whoever receives thework, in time spentrediscovering what was alreadyknown and discarded. It is theleast visible cost in anydelegated arrangement.
This is the seam that makes delegated work feel worse to use than it looks on a diagram. From the outside a handover is a single arrow, and the arrow implies continuity. What actually crosses it is whatever somebody thought to pass, which is nearly always the outcome and nearly never the working. The receiving side therefore begins by reconstructing: a support agent asks the customer to explain again, a downstream component re-fetches something already fetched, a person picking up a half-finished job tries the approach that was tried and abandoned an hour ago. None of that shows up as a failure, because the work does eventually get done. It shows up as the arrangement being slower and more irritating than the version in the diagram, and as customers who say they had to repeat themselves, which is the most common complaint about automated support and is a description of exactly this seam.
03

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 Lyro
  • An enterprise platform describing conversations resolved end to end rather than deflected, which is a claim about how rarely this moment arrives.

    Sierra
  • A 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
04

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.

05

Telling them apart

Agent handoff vs Human in the loop

Agent handoff

The moment work changes hands, in either direction.

Human in the loop

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.

06

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.
07

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.
09

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

All glossary terms