← LOGS

When the Right Handoff Lowers an AI Agent's Score

A bank-service illustration exposes how measuring AI containment can penalize the very human referral a service was meant to make.

A fog-covered landscape filled with rows of circular directional signs, all pointing left except for one large foreground sign with a softly glowing right-pointing arrow.
Some days, doing your job feels like insubordination.

IN BRIEF

An AI support agent can answer a customer's question correctly and still need to hand the case to a person. A containment target, which rewards keeping conversations out of human queues, may count that appropriate referral against it. Druid AI's presenter-described banking example makes the conflict visible, but it isn't independently verified evidence of a customer outcome. The better test starts with what the service was authorized to do, then checks referral correctness, transfer quality and follow-through separately. Containment remains useful for tasks meant to end in automation. It just cannot define success for every kind of request.

Consider a hypothetical customer asking a banking assistant what it would take to pay off a mortgage early. The assistant may be able to find the balance, work through the figures and answer without involving a person.

But the bank might have another requirement. If that kind of inquiry qualifies for a conversation with a lending specialist, the assistant should offer a referral, pass along the permitted context and obtain the customer's agreement where required.

On a dashboard that rewards conversations completed without human help, the assistant that ends the chat looks better than the one that makes the referral. Yet if the referral was required, the second assistant has done its job.

That is a strange thing to punish.


Two interns, one misleading comparison

Druid AI's talk at AI Engineer World's Fair 2026 presents this tension through two hypothetical bank interns. One handles 80% of conversations without referral and hands off 20%. The other handles 96% and refers only 4%. By containment alone, the second intern ranks higher.

The presenters then introduce an early-mortgage-payoff question. In their illustration, the intern who refers the inquiry follows a business rule: certain questions warrant a conversation with a qualified banker. Druid's broader scoring example reverses the initial ranking by giving more weight to governance and the assigned mandate than to containment alone.

This is a presenter-described illustration, not independently audited evidence that two real bank agents performed this way or that any customer refinanced. Druid's proposed scoring priorities are also its own, rather than an established industry standard.

If a valid referral counts as a failure, the measurement is at odds with the service's instructions.


The percentage doesn't know why the customer came

In support operations, containment commonly means the share of conversations handled within the automated channel without transfer to a person, although exact definitions and denominators vary by provider. It's useful when someone needs a balance or opening-hours answer and the system completes that task accurately without making them wait for a human.

But the percentage alone can't distinguish an unnecessary transfer from one the service was supposed to make. It doesn't prove resolution, either. A customer might leave because the question was answered, because the answer was wrong or because continuing wasn't worth the effort.

Zendesk's explanation of deflection and resolution likewise treats avoided human contact, actual resolution, recontact and escalation quality as distinct measurements. That is vendor-authored guidance, not proof that any particular bank achieved better outcomes.

I'd keep containment on the dashboard, but wouldn't use it as a stand-in for whether the service did its job. Different requests are meant to end in different ways.


A referral isn't automatically a good outcome either

Rewarding every handoff would create the opposite problem. A referral might be unnecessary, go to the wrong team or reach someone who lacks the information or authority to help. An assistant could even turn a simple payoff question into an unwanted sales conversation.

That last possibility matters in the banking example. A lender may see a potential refinancing opportunity when the customer only wants a number. The chance of commercial value doesn't override the customer's original request, choice, suitability or applicable permissions.

I'd separate at least four judgments:

  1. Was human involvement warranted? The request class, applicable rules, uncertainty and customer's interests should justify a transfer, rather than a blanket preference for more handoffs.
  2. Was the transfer authorized and usable? It should go to an appropriate recipient, with permitted context and the customer's choice respected where relevant.
  3. Did the receiving service actually take over? A referral attempt is not the same as a received, actionable case. Lost context and repeated questions are measurable failures even after the routing decision was correct.
  4. What happened to the underlying request? Where follow-through matters, the service needs evidence of resolution or another explicitly defined endpoint. It must not quietly credit the AI with work a human completed.

Before deciding how to score those behaviors, the service needs to establish what each type of request is supposed to achieve.


The handoff is a boundary, not a magic finish line

Even when an agent correctly recognises a need for specialist support, obtains the required permission and sends usable context to the right person, the customer's request may remain unresolved. The banker might not follow up, or the customer might have to repeat information that should have accompanied the transfer.

The reverse is possible too: a specialist could rescue a poor handoff through extra work. If the dashboard reports only the final resolution, it might credit the agent for a recovery the person performed. A correct routing decision and the eventual customer result tell different parts of the story.

I'd track the agent's recognition of the need to escalate, permission, transfer execution and human receipt separately from the customer's eventual outcome. I'd also review cases that should have been escalated but weren't. Looking only at completed handoffs would miss those failures.

How much of that can be measured depends on the service's mandate, risks and available evidence.


Keep the efficiency measure in its place

Human time is limited, and accurate automated answers can reduce waiting and unnecessary work. Low containment may reveal weak automation or excessive transfers; unnecessary handoffs also introduce cost, delay and opportunities for failure.

For a routine information request, I'd want to know whether the answer was correct, the task was completed and the customer had to come back. For a request that properly needs specialist judgment, I'd want to know whether the agent recognised that need and made a suitable, usable handoff. For both, I'd still watch time, cost and customer burden.

A target becomes counterproductive when it encourages an agent to avoid human involvement even when the service's rules call for it. Before setting a containment target, I'd ask what decisions it will encourage the next time a customer genuinely needs a specialist.

Druid's illustration doesn't prove that escalating more often improves performance, and it doesn't establish universal scoring weights. It shows why an automated answer and a justified referral can both count as successful agent behavior, provided each is judged against the task the agent was supposed to perform.

It's to make the right outcome count.


// End of transmission. Count the right outcome — ZYANE