An agent that never hands a case over is not a sign of a good agent. It usually means the agent is guessing. The opposite also happens: an agent that hands over everything saves nobody any time. The skill is in the middle, and for a small company it is a management decision, not a technical detail.
This article is for the owner or manager of a company that runs or plans an AI agent. It explains when the agent should stop, who should take the case, and how you can tell from the records that it worked. It builds on preparing your team for an AI agent, which describes roles and the first outline of a handover, and on what to tell customers about an AI agent.
Why the agent needs written rules for stopping
A person who is unsure usually asks a colleague. An agent is built to produce an answer, so without a rule it will often produce a confident one even when it should not. That is why human oversight is treated as a design requirement and not an extra: the EU AI Act, for high-risk systems, expects that people can understand a system's limits, interpret its output and decide not to use it or to override it (EU AI Act, Article 14: Human oversight). Your agent may not fall under that category, but the principle is a sound one for any business.
The NIST AI Risk Management Framework makes a similar point: define who is responsible for oversight and what happens when the system does not behave as expected (NIST: AI Risk Management Framework). In a small company this comes down to a short list that everybody can read.
Three groups of triggers
1. The agent is not sure
The agent should hand over when it cannot support its answer. Typical signs:
- The information it needs is missing, outdated or contradictory (see preparing company documents for an agent).
- The request is outside the list of tasks the agent was given.
- The customer asks for something the agent cannot find in approved sources, such as an exception, a special price or a legal interpretation.
- The customer is clearly upset, confused or asks for a person.
The last point deserves a firm rule: when somebody asks for a human, the agent hands over. It does not argue and it does not ask the person to try once more.
2. The action is sensitive or hard to undo
Some actions should not be left to the agent alone, however sure it is:
- Payments, refunds and changes to prices or contracts above a limit you set.
- Deleting or overwriting records, and sending messages to many people at once.
- Anything involving health, finances, employment or other personal matters of a customer or employee.
- Decisions that significantly affect a person, such as refusing a service. The UK data protection regulator explains why people affected by automated decisions need a real way to have a person review them (ICO: Guidance on AI and data protection).
- A request that would need wider access than the agent has (see giving an agent only the access it needs).
For these, the agent may prepare a draft and the recommended action, but a named person approves it. The limits can be loosened later, once the records show the agent handles a class of cases well.
3. Repeated errors
An agent can get stuck in a loop: the same question again and again, the same failing step, the same correction that does not take. Set a simple limit, for example:
- Two failed attempts at the same step, then stop.
- The same customer returns about the same case a third time, then hand over.
- A tool or system the agent depends on does not answer, then hand over instead of waiting without end.
The exact numbers matter less than having them. Start strict and relax them with evidence.
Who takes the case
"A person" is not an answer. For each type of case write down:
- Who: a named person or a shared queue, such as the sales inbox or the support lead.
- A deputy for holidays and sick days. A handover to an empty mailbox is worse than no handover, because the customer believes someone is dealing with it.
- How fast: a time for the first human reply, such as the same working day for ordinary cases and one hour for urgent ones.
- What the customer is told while they wait. The agent should say plainly that a person will take over and roughly when, not pretend that it is still working on it.
The person who takes over also needs the authority to decide. If they can only forward the case to somebody else, the chain is too long.
What to pass along
The main complaint about bad handovers is that the customer has to start from the beginning. A good handover is a short note the agent writes, containing:
- Who the customer is and how to reach them.
- What they asked in one or two sentences.
- What the agent already did, and what it found.
- Why it stopped: which trigger applied.
- What it suggests, if it has a suggestion, marked as a suggestion.
Keep the note short and do not copy the whole conversation or any secret data into it. The person can open the full thread when needed.
How to see it in the records
A handover that is not recorded did not happen, as far as you can prove. In the activity log (see what to record about an agent's actions) each handover should show:
- the time, the case and the trigger,
- who it was sent to,
- when a person picked it up,
- how it ended.
Then use these entries for a weekly look of ten to twenty minutes:
- Open handovers: any case nobody picked up within the agreed time is a failure of the process, and you should fix it first.
- Number of handovers: if it is very low, ask whether the agent is guessing. Read a few of its answers in sensitive areas. If it is very high, the instructions or documents may be unclear, or the triggers too broad.
- Reasons: if most handovers have the same reason, that is the cheapest improvement you can make, whether it is a missing document, a new rule or a task the agent should simply not do.
- Returns: cases the person sends back to the agent, or customers who come back about the same case, show where the note or the decision was poor.
Changes to the triggers are changes to the agent, so handle them like any other change, with a test and a way back (see changing an AI agent after launch). If a handover goes badly wrong, for example a sensitive action went through without approval, treat it as an incident and follow your incident response routine.
A short checklist
- The triggers are written down: uncertainty, sensitive or irreversible actions, repeated errors, and a customer asking for a person.
- Every type of case has a named person or queue, a deputy and a time limit.
- The customer is told honestly that a person is taking over.
- The agent passes a short note with the request, what it did, why it stopped and a suggestion.
- Each handover appears in the log, with pick-up time and outcome.
- Someone looks weekly at open handovers, their number and their reasons.
If you have nothing in place yet, begin with the simplest version: the agent hands over whenever it is unsure or a person is requested, one shared inbox receives the notes, and one person checks it every working day. You can tighten and extend the rules as soon as you see the first real cases.
