How to let an AI agent hand a chat to a person in your live chat tool

Grant the agent four permissions in the chat tool and no more: read the conversation, read queue availability, write an internal note, and transfer the chat to a queue. Do not let it pick an individual, close a chat a person owns, or take a chat back. Once a chat is handed over, the agent's write access to that conversation ends.

What does the handover involve, and who owns it?

Handover is the moment the customer stops talking to the agent and starts talking to a member of staff in the same window. Done well, the person arrives already knowing who the customer is, what they want and what has been tried. Done badly, the customer types everything again and judges the whole service on that.

The support operations lead owns the chat tool configuration and the queues. The team leaders own their queues' staffing. Name both before you grant anything. The design of the conversation side, what the agent says and when, is covered in how a support agent should hand a conversation to a person. This piece is about the system: what the agent may do inside the chat tool. For the full set of support limits, see the AI support agent that knows when to say no.

Which permissions should you grant, and at what depth?

Most live chat tools expose a dozen or more actions through their integration interface. Grant them one by one.

The pattern is simple. The agent may route work into a queue, but people decide who in the queue takes it. That keeps team leaders in control of workload and stops the agent learning to send hard chats to the most patient colleague.

How do you set it up, step by step?

1. Person, support operations lead: lists the queues the agent may use. Each with its purpose, its hours and its fallback when nobody is online.
2. Person: creates a dedicated integration account for the agent. Not a shared staff login. Its permissions in the chat tool match the table above.
3. Agent, depth 1: reads availability before offering a person. If the queue is closed or the wait is long, it says so plainly and offers the fallback, such as a callback or an email reply.
4. Agent, depth 3: writes the handover note. Customer identity status, the request in one line, what the agent checked, what it could not do and why. The note goes in before the transfer, so the person sees it on arrival.
5. Agent, depth 3: transfers to the queue. The verdict records the queue, the reason and the bound that triggered the handover.
6. Platform: removes the agent's write access to that conversation. From this point the agent can read the chat for summarising later, but cannot post.
7. Person: takes the chat from the queue and owns it to the end. Including closing it.

What stays with a person?

Everything after the transfer. The agent does not whisper suggestions into the chat, re-enter when the person goes quiet, or close the conversation when the customer leaves. Two owners in one conversation produce contradictory answers, and the customer cannot tell who promised what.

Picking an individual also stays with people. So does creating or changing queues and opening hours. If the same customer contacts you again by email or phone, the agent may pick up the new contact, but the rules for carrying context across are their own subject; see whether one support agent can work across email, chat and phone.

What is recorded for each handover?

Every action the agent takes in the chat tool is filed as a verdict in an append-only record. For handovers the useful fields are:

• the conversation, the queue chosen and the reason for handover;
• whether the customer asked for a person or the agent's bounds required it;
• the internal note as written;
• the wait the agent quoted and the actual wait;
• the moment the agent's write access ended;
• any attempt by the agent to post after that moment, which should be refused.

The disclosure at the start of the chat also belongs in the record. Customers must know they were talking to an AI system and when a person joined; see Article 50 disclosure in chat, voice and email agents.

How do you revoke the access?

Revocation works at three levels. Per conversation, the platform removes write access at handover. Per capability, you can withdraw the transfer grant alone, for example if a queue is being restructured, and the agent then holds every handover for a team leader to route. For the whole agent, disabling its integration account in the chat tool stops everything at once. Test all three before go-live. The connection itself is set up as described in connecting an AI agent to your live chat platform.

What should you measure?

• Customers who repeat their request after handover. The best single test of the note.
• Quoted wait against actual wait.
• Handovers by reason: customer asked, bound reached, vulnerability signal, out of scope.
• Chats transferred to the wrong queue and moved again by staff.
• Refused posts after handover. Should be zero; any at all means a configuration problem.

Where does it usually go wrong?

The agent transfers to a queue with nobody in it. The customer waits in silence until the chat times out. Check availability first and offer the fallback.

The note is a transcript. Staff skip it. Keep it to five lines.

The integration account has staff-level rights. Someone reused an admin account during testing. Audit the account's actual permissions in the chat tool, not the intended ones.

Where Pryme fits

In Pryme, the transfer to a queue and the internal note are separate capabilities, and the platform removes the agent's right to post in a conversation once it is handed over. Any later attempt to post is refused and filed, so you can show that a person owned every message after the handover.