Polite Isn't Enough: Your AI Agent Has to Follow the Policy

TL;DR

• An AI agent can be polite in every reply and still hand off at the wrong moment. In the three calls we'll look at, every reply would score well on tone and relevance, but all three conversations still broke the support team's policy.
• A handoff can go wrong in four ways. It can come too late, too early, when it wasn't needed at all, or never happen. A lot of advice only talks about the agent that never escalates, but two of the three failures here were transfers that either shouldn't have happened at all or came too early.
• Handoff rules work better when you write them per request type. For each type of request, write down whether it goes to a person, which steps have to happen before a transfer, and what the agent should pass along when it does transfer.
• A multi-turn metric can check the handoff decision on every production conversation. Because the metric reads the whole conversation along with the tools the agent called, it can fail any transfer that the policy doesn't allow.
• Confident AI turns new failures into metrics, and keeps finding the next one. Error Analysis spots the pattern, a custom metric checks it on every conversation, and classifiers and simulations keep watching for anything new.

Three calls that broke the handoff policy

The setup here is common for any subscription business. There's an AI agent answering the support line, and it handles cancellations, payment questions and refunds. What it does is set by the team's support policy, which is a set of written rules given to the agent in its instructions. These rules say which requests the agent should complete itself, which ones should go to a person, and which steps have to happen before a transfer, like making retention offers before a cancellation. On top of that, a human reviewer goes through a sample of conversations every day, rates them, writes down what went wrong, and tags each call with an outcome, such as Transfer Success or Policy Fail.

At the end of the day, Confident AI rolled the reviewer's notes into a daily report, and that's where the pattern stood out: three handoff mistakes in one day's calls. The reviewer had marked each call on its own, and each one looked like a one-off; the report is what showed they were a pattern.

We have recreated the three calls below as text from the reviewer's notes, so the wording is ours, but the sequence of events is what actually happened.

The first one is the payment update we talked about at the start.

The reviewer rated this one two out of five and marked it as a policy failure, because the customer should have been transferred on the very first turn.

In the second call, the customer had already said no to two retention offers, so the agent didn't have any offers left to make.

Here the customer gave the agent two outcomes they were happy with, and the agent picked the one that cost more. The customer had to wait in a queue, and a person had to spend their time on a cancellation that the agent was allowed to do on its own.

In the third call, the customer said no to every offer and asked to cancel with a refund.

The policy said that once the customer turned down the offers, the agent should explain the refund terms, which the team calls a refund rebuttal, and only transfer the call if the customer still wanted the refund. The agent skipped that and transferred the call, so the customer got a transfer instead of an answer, and immediately called the whole experience a scam.

What is an AI agent handoff?

An AI agent handoff is the moment when an agent passes a customer on to a person, along with whatever that person needs to pick up the conversation. In customer support, this usually means a transfer to a live agent, a callback, or a ticket for a specialist team. You'll also see frameworks like the OpenAI Agents SDK use "handoff" for one agent passing work to another agent, but in this post we're talking about the handoff to a human.

If you think about it, a handoff is a decision with three parts. The agent has to decide whether this request belongs with a person, whether it needs to do something first, and what it should pass along when it transfers. A good handoff gets all three right, and if it gets any of them wrong, the customer feels it, whether that's waiting, having to repeat themselves, or getting bounced between people.

A lot of the advice out there focuses on the customer who never gets to a person. That failure is real, but as you saw in the calls above, the opposite problem shows up too. If you're new to evaluating agents, our AI agent evaluation guide covers the basics that this post builds on.

Four ways an AI agent handoff goes wrong

Each of these failures has a different cause, so each one needs its own rule in the policy and its own line in the check.

1. The over-helpful AI agent

This is the transfer that comes too late. The agent tries to solve something that the policy says a person should handle, which is exactly what happened with the payment update. The cause is usually the agent's instinct to be helpful. Self-service sounds like good service, so the agent suggests the website before it checks the rule.

Teams usually write a rule like "payment updates go to a person" for a reason. It might be compliance, fraud risk, or a website flow that doesn't work for every account. The agent doesn't know that reason, so when a friendlier option seems available, it can end up treating the rule more like a suggestion.

2. The unneeded transfer

Here the agent transfers a request that it was allowed to complete, and could have completed. This is the customer who said "cancel it, or get me a live agent". When a customer gives two options, a transfer looks like the safe choice, because a person can always sort it out. But it costs the customer a wait, and it costs the team a person's time on a cancellation that the agent could have done with one tool call.

3. The transfer that skips a step

This is the transfer that comes too early. The transfer itself might be something the policy allows, but the agent skips a step that has to come before it. This is the refund call. Things like retention offers, refund rebuttals and identity checks often sit before a transfer for business reasons, and when an agent jumps straight to a person, it skips past those steps.

4. The handoff that never happens

This is the one where the agent holds on to a customer who needs a person. It loops, repeats itself, or guesses at an answer that's outside its scope. None of the three calls in this post failed this way, but it's the failure a lot of guides talk about, and the checks we'll cover below can catch it too with one more line in the metric's criteria.

The first three failures are hard to spot because the agent sounds reasonable the whole time. It's a bit like judging a receptionist by how warmly they greet people, without ever checking whether they sent each visitor to the right office.

Why these calls pass a typical eval

If you run the payment update through the usual checks, it actually scores well. Turn Relevancy is high, since every reply is about updating a card, and the tone is polite throughout. A faithfulness check doesn't even apply, because there's no retrieved document to check the replies against.

The problem isn't the metrics themselves, it's that none of them know your policy. Turn Relevancy checks that each reply is on topic, and Role Adherence checks that the agent stays in the role you gave it, like a friendly support agent, but neither checks your business rules. The failure only shows up when you look at the whole conversation with that policy in mind. The first reply is wrong because of what the policy says about this type of request, and you can only see that if you know the policy and read the call as a whole. The two transfers are wrong because of what had or hadn't happened earlier in the call, which is the declined offers in one case and the missing rebuttal in the other.

Research benchmarks point the same way. Sierra's τ-bench, published in June 2024, tests support agents against a written domain policy and grades the end state of each conversation, instead of the wording of the replies. Its policy even includes a rule much like the one our agent broke in the second call: transfer to a human only when a request can't be handled with the agent's own actions.

That's why multi-turn evaluation matters so much for support agents. A handoff is a decision about the whole conversation, so whatever metric judges it has to read the whole conversation, with your policy in hand. If you want to go deeper on choosing conversation-level metrics, the playbook on evaluating multi-turn conversations covers that.

Write handoff rules an agent can follow

Most handoff rules live in a system prompt as a bit of prose, something like "Transfer to a human for billing issues or when the customer is upset." The problem is that an agent tends to read "upset" and "billing issues" as hints, and it applies them unevenly. Rules work a lot better when each one names a request type, any steps that come first, and what the agent should do in each case.

Here are the three rules from the calls in this post, written that way:

There are two habits that make these rules hold up. First, give each request type its own row and keep the columns the same, so if a step is missing, you can see it at a glance. Second, decide what the agent should pass on when it does transfer. A short summary of who the customer is, what they asked for, what the agent already tried and why it's transferring means the customer doesn't have to repeat themselves to the next person.

These rules also end up being your test cases. Every row is a branch the agent can take, and every branch needs at least one conversation in your evaluation set.

How to catch and fix bad handoffs with Confident AI

The rules tell the agent what it should do, but you still need to check that it actually does it, on real conversations, every day. Here's how you can set that up for your own agent. We recreated the customer's calls in a demo project so you can see each step.

1. Let reviewers record the outcome each call should have had

The reviewer in this story already tagged every call with an outcome in their annotation form, like Transfer Success or Policy Fail, and wrote down what went wrong. You can make that even more useful by recording the outcome each call should have had, like "transfer on the first turn" or "agent cancels". Reviewers annotate whole conversations in an annotation queue, with a rating, an explanation and an expected outcome. The expected outcome turns a vague "this felt off" into a rule you can write down, which is what the metric's criteria are built from, and it's what you check the metric's scores against later. And human-in-the-loop review is usually where failures like these get found first.

2. Write a handoff policy metric

The handoff decision needs its own metric. This is a custom multi-turn metric that you write in plain English, in the style of G-Eval, and it's given the conversation turns plus the tools the agent called on each turn. That last part matters, because the transfer itself is a tool call, so the metric can see exactly when it happened.

You can write the criteria straight from the rule table. Ours starts with "Using the Role, Content and Tools Called of each turn, judge whether the support agent's handoff decisions follow this policy", then gives the rule for each request type, and ends with when to fail: "Fail the conversation if the agent transferred a request the policy says it should complete, transferred before doing a step the policy requires first, or tried to resolve a request the policy says a person must handle." You can also paste the rule table itself into the criteria, so the judge knows the policy for each request type. The judge gives each conversation a score from 0 to 1, and anything under the threshold, 0.5 here, fails. Since the metric reads the whole conversation, it caught all three calls from this post when we ran it on a demo recreation. To catch the handoff that never happens as well, add a line for it, such as failing a conversation where the agent keeps going in circles instead of transferring.

3. Run it on every production conversation

Add the metric to a multi-turn metric collection and attach that collection to a thread evaluation rule. Each conversation then gets scored once it has gone quiet (five minutes without a new message, by default), without any code changes in your agent. The scores sit on each conversation and roll up over time, so you can see whether a prompt or policy change actually reduced the bad transfers.

In our demo, the metric agreed with the reviewer on 13 of the 14 conversations. The one it missed was a second refund call, chat-a9edfcad in the screenshot above, where the agent made the offers but still skipped the rebuttal, and the metric scored it 1.00. That's why it's worth checking the metric against your reviewers' annotations before you rely on its scores.

Let Confident AI find the next one

Fixing the calls you already know about is half the job. The other half is finding the ones nobody has flagged yet, and making sure a failure you fixed stays fixed.

1. Group the notes into failure modes

Once a queue has enough annotations with written explanations, Error Analysis reads through them, groups them into failure modes, such as "Premature or Unjustified Transfer for Cancellations" and "Skipped Refund Rebuttal" in our demo of these calls, and suggests a metric for each one, either a new one, one you already have, or a change to an existing one. It only uses annotations that include written feedback, such as an explanation or an expected outcome, because a rating alone doesn't say why a call went wrong.

2. Keep every failure in your tests

Production checks only find failures after a customer has already run into them. To find them before a release, turn each row of the rule table into multi-turn goldens, which means a scenario, an expected outcome and a customer persona, such as "a customer who declines both offers and asks for a cancellation or a live agent". The platform then simulates each conversation against your agent and runs the same handoff metric on the result.

The calls your reviewers flagged make good goldens too, because each one is a branch your agent has already gotten wrong once.

3. Label transfers and send them to a reviewer

A metric scores the decision, but you'll also want to see every transfer as it happens. A trace classifier labels each trace with what happened in it, for example an "Escalation to Human" label for any trace where the agent handed the customer over to a person. These labels show up in Signals, which flags a sudden rise in any label, such as transfers. A spike is a cue to look, not a verdict on its own, because the rate alone doesn't tell you whether the transfers were right.

On traces, a queue ingestion task can run after the classifier, so traces labeled "Escalation to Human" land in a review queue, either all of them or a sample. That way your reviewers see the transfers first and confirm the bad ones, and those annotations feed back into Error Analysis and the golden dataset. So the loop goes from review to the metric, then to production checks and simulation, and then back to review.

Common mistakes

1. Judging handoffs by the handoff rate

When the transfer rate goes down, it looks like progress, but it can also mean the agent is holding on to customers it should be passing on. And a rising rate can mean the agent is skipping steps. The rate only tells you something once you also know whether each transfer was correct.

2. Treating a transfer as the safe default

A lot of teams tell the agent "when in doubt, transfer". That's the kind of rule that leads to failures like two of the three in this post. A transfer has a cost for the customer and for the team, so the rule should be to follow the policy, and transfer when the policy says so.

3. Keeping the rules only in prompt prose

If your handoff rules only exist as a paragraph in the system prompt, nobody can test them, and vague prose is harder for the agent to apply consistently too. Keep the rule table as your source of truth, generate both the prompt section and the test cases from it, and update the table, the prompt and the tests together whenever the policy changes.

4. Testing only the polite, happy path

Most test conversations are customers who ask once and accept whatever answer they get. But the handoff failures here came from customers who declined offers, gave the agent two options, or pushed back. So write goldens for those customers on purpose, and give them personas that push back.

Why Confident AI is the best platform for evaluating support agent handoffs

You can run everything in this post in one place. Reviewers annotate conversations with expected outcomes in annotation queues, Error Analysis turns their notes into failure modes, a custom multi-turn metric checks every handoff against your policy on production conversations, simulations test each branch before a release, and classifiers route every transfer to a reviewer.

Your support leads, QA and domain experts can work in the same platform as the engineers who own the agent, without writing any code. If your agent hands customers over to a person, sign up and set up these handoff checks on your own conversations.

Conclusion

If there's one thing to take away from this, it's that a handoff is a decision, and you have to evaluate that decision, because polite replies can hide a wrong one.

The three calls in this post broke the policy in three different ways: one transfer came too late, one wasn't needed at all, and one skipped a required step. Each of these conversations would pass the usual relevancy and tone checks. Writing the rules as a table, checking the whole conversation with a handoff metric, and simulating every branch is what catches all three.

So this week, take your agent's handoff rules out of the system prompt and write them as a table, with one row per request type. Then pick five recent transfers and check each one against its row. There's a good chance you'll find at least one that shouldn't have happened.

And that card update from the start? With the rule written down and the metric watching every conversation, it gets flagged within minutes of the conversation ending, instead of waiting for someone to stumble on it.

Thanks for reading, and good luck with your agent.

Frequently Asked Questions