Agent handoff: when an AI agent should call a person

An AI agent should hand a conversation to a person in five situations: the customer asks for one, the agent can't support its answer from a source, the stakes are high, the topic is sensitive, or the conversation is going in circles. Write those rules down outside the prompt. Then send the person a short packet so the customer never has to repeat themselves.

Why does the handoff matter so much?

Customers remember the conversation that went wrong, not the many that went right. An agent can answer routine questions well all day and still lose a customer on the one conversation it should not have handled alone.

When an agent fails quietly, by looping, guessing or refusing politely again and again, the customer escalates on their own. They call the branch, post a complaint, or leave. By the time a person gets involved, the customer is frustrated and the staff member is starting from nothing.

Design guidance has said this for years. Microsoft's guidelines for human-AI interaction include a whole group for the moments when the system is wrong. Google's People + AI Guidebook puts it plainly: when an AI system fails, "often the easiest path forward is to let the user take over." In customer service, taking over usually means a colleague, and the job is to make that switch easy.

When should an AI agent hand off to a human?

We give every agent explicit handoff triggers. Most fall into five groups:

• The customer asks for a person. Always honour this, with no "let me try once more first." It must work however it is phrased: "I want to talk to someone," "أبي أكلم موظف," "حوّلني على أحد," or a frustrated "?!!" after a failed answer.
• The agent can't ground its answer. If search finds nothing relevant, or no source actually supports the answer, the agent says so and offers a person instead of improvising.
• The stakes are high. Refunds above a set amount, account changes, contract terms, and anything hard to undo. The agent prepares the case and a person approves it.
• The topic is sensitive. Legal or medical questions, complaints about staff, anything involving minors, and requests that touch another person's data.
• The conversation is going in circles. The same question twice, two failed attempts in a row, or rising frustration in the customer's wording.

The exact limits differ by business. They should be written down, agreed with the operations team, and testable. A rule that lives only in someone's head can't be checked.

What should the person receive?

A handoff is only as good as what arrives on the other side. Google's guidebook says it is the product's responsibility to make it easy "to quickly pick up where the system leaves off." In practice, every escalation should come with a short packet:

• The reason, in one line, for example "Customer asked for a person" or "Refund above approval limit."
• A summary in the language the staff member works in, with the original messages kept word for word below it. Summaries can drift, especially between Arabic and English, so the original wording should always be one click away.
• What the agent already tried: answers given, sources cited, and actions prepared.
• What has been verified, such as the customer's identity or order number, and what has not.
• A suggested next step, clearly labelled as a suggestion. The person decides.

A simple test: if the staff member's first message is "How can I help you?", the handoff has failed, however smooth it looked from the agent's side.

What does a good handoff look like?

Take a customer writing in Saudi dialect about being charged twice for one order. This is an illustrative case, but its shape is common in billing support.

1. The agent recognizes a billing question and asks for the order number.
2. It finds two charges on the order, so the customer's account matches the records.
3. The refund is above the agent's approval limit, which triggers the high-stakes rule.
4. The agent tells the customer plainly that both charges were found and that a colleague must approve the refund.
5. It gives an honest wait time, and a case reference if the message arrives outside working hours.
6. The billing team receives the packet: the reason, a summary, the original messages, the verified order details and a suggested refund.
7. A staff member reviews the case, approves the refund and replies in the same conversation.

The customer never repeats a detail. The agent did most of the work, and the person did the part that needed a person.

What should you build in from the start?

Handoffs are easier to design in than to add later. These are the parts we put in place from the first version:

• Triggers in configuration, not in the prompt. Operations teams can read, change and test them without touching the model.
• "Talk to a person" works in every form. Arabic and English, dialect and formal Arabic, short and long. Test it with real phrasings from your own conversations.
• Honest waiting messages. Don't say "connecting you now" when no one is on shift. Out-of-hours requests get a clear promise and a case reference.
• Every handoff logged with its reason. Over time, the log shows where the agent struggles and which rules fire too often or too rarely.
• Packets and logs treated as personal data. They hold names, order details and the customer's own words, so the Personal Data Protection Law and its Implementing Regulation apply to them like any other record. Keep only what the staff member needs, and set a retention period.
• Handoffs feed the test set. Escalated conversations make some of the most useful test cases a team has. Review them regularly and add the instructive ones to the agent's tests.
• A few defined measures. Track how often conversations are handed off, how many of those are resolved without the customer re-explaining, and how often a customer asks for a person after an answer the agent judged confident. Publish a figure only with its definition, method, sample size and date.

What can a handoff not fix?

A good handoff is part of a good agent. It can't stand in for one.

• A weak agent. If most conversations end in a handoff, fix the agent, not the escalation screen.
• Guessing. A low handoff rate is not automatically good. An agent that never escalates may be guessing when it should stop.
• Rubber-stamping. If staff approve every suggestion without reading it, the human check exists only on paper. SDAIA's AI Ethics Principles list humanity, and accountability and responsibility, among their seven principles. A person who signs without reading meets neither.
• Sector rules. Regulated sectors may have their own requirements for human review and complaint handling. Those decisions sit with your compliance team and counsel.

What should you do next?

Start with one workflow. Pick the conversation type your team escalates most often, write down its triggers and its packet, and test ten real handoffs before adding more. Then read the handoff log after the first two weeks. It will tell you which rule to adjust first.