Every agent deployment eventually hits the case it cannot handle. The question is not whether that happens, it is what the customer experiences when it does. Teams treat the handoff as an edge case and build it last, which is backwards. The handoff is where trust is won or lost, and it is the part your customers will describe to other people.
Five things worth getting right before you write a single agent instruction.
1. Decide what triggers escalation, explicitly
"The agent escalates when it cannot help" is not a specification. It is a hope. Write the triggers down as conditions the agent can actually evaluate: confidence below a threshold, a named topic on a deny list, a monetary value above a limit, a customer tier, a second failed resolution attempt in the same conversation, any request to reverse a prior action.
The trigger you will forget is the emotional one. A customer who writes "this is the third time I have asked" should reach a human regardless of whether the agent technically knows the answer. That rule is easy to implement and disproportionately valuable.
2. Pass the whole conversation, not a summary
The fastest way to make a customer hate your agent is to have them explain everything twice. When the handoff fires, the human should open the case with the full transcript, the records the agent retrieved, the actions it took or proposed, and the reason it escalated.
In Salesforce this means writing the transcript to the case before routing, not after. In practice a surprising number of deployments route first and attach the context asynchronously, which produces exactly the "start over" experience you were trying to avoid.
3. Make the exit obvious and never punish it
Customers should be able to reach a person without guessing a magic word. Put it in the opening message, keep it available every turn, and honor it on the first request. Agents that require three attempts to escape generate worse sentiment than having no agent at all, because now the customer is annoyed about the agent on top of the original problem.
There is a commercial temptation to make the exit costly so deflection numbers look better. It works on the dashboard and fails in the review your customers write.
4. Tell the human what the agent already tried
The human picking up an escalation needs to know what has been ruled out. Otherwise they repeat the agent's steps, the customer watches them repeat the agent's steps, and the handoff has made things slower rather than faster.
A short structured block on the case does the job: what the customer asked, what the agent retrieved, what it tried, why it stopped. This is also the raw material for your eval set, since every escalation is a labeled example of a case the agent could not close.
5. Instrument the handoff as a metric, not a failure
Escalation rate is not a number to minimize. It is a number to understand. A rate that falls while customer satisfaction also falls means the agent is trapping people, which is worse than the baseline you started from.
Track escalation rate alongside post-escalation resolution time and post-escalation satisfaction. The combination tells you whether the agent is genuinely absorbing volume or just adding a step before the human does the work anyway. That distinction is the entire ROI question, and it is invisible if you only watch deflection.
The short version
Build the escalation path first, with real context transfer and an exit the customer can find. Then build the agent inside it. Teams that work in that order ship agents customers tolerate. Teams that work in the other order ship agents customers route around, and then wonder why the deflection number never converts into headcount savings.
What to do next
Read the Architecture Guide