Customer-facing AI gets risky when it keeps talking after it has run out of approved ground. We define the handoff before we tune the personality, because a polished answer is still the wrong answer when the agent lacks the authority or information to give it.
Start with authority
An agent can sound certain about almost anything, but that doesn't mean it should answer everything.
Before a build starts, we map what the agent may explain, what it may do, and what must go to a person. A support agent might explain a published return policy and collect the order number. It should not invent an exception for an angry customer or promise a refund it cannot issue.
The same rule applies to lead follow-up. An agent can ask approved qualification questions and book an available time. Pricing exceptions, unusual contracts, and sensitive customer details need an owner.
Four reasons to hand off
The source material does not support an answer
If the approved docs do not cover the question, the agent should say so and route it. Guessing creates a second problem for the team to clean up.
The customer asks for an exception
Policies describe the normal path. Exceptions require someone with the authority to weigh cost, context, and the relationship.
The conversation carries real risk
Threats, safety concerns, legal questions, payment disputes, and sensitive personal information should move to a trained person under rules agreed before launch.
The customer asks for a person
Do not make someone fight the agent to reach the team. A direct request for human help is enough.
Send context with the conversation
A handoff that forces the customer to repeat everything is unfinished work. The agent should pass the useful context it already collected:
- The customer's request in their own words
- The account, order, or lead details the customer approved for use
- The source material the agent checked
- Any action already completed
- The reason the agent stopped
That record gives the next person a clean starting point. It also gives the team something concrete to review when the same gap keeps appearing.
Build the queue before the prompt
The handoff destination matters as much as the wording. Each route needs an owner, an expected response path, and a fallback if that owner is unavailable. Otherwise the agent produces a tidy summary that sits untouched in the wrong inbox.
We test those routes against common and awkward cases: after-hours messages, missing order numbers, sudden subject changes, and connected-system outages. We write the response into the operating rules so the team is not relying on one developer's memory.
Review what the agent could not finish
Handoffs show where the source material, workflow, or authority model is weak. Review them after launch, since some will stay human work. Others will expose a missing policy, a broken integration, or a repeatable request the agent can safely handle once the rules are clear.
That review is how the system improves without quietly expanding the agent's authority.
