Customer service agents that are allowed to do things

The shape of the problem

A large service operation handles millions of contacts a year across voice, chat and app, with tier one usually outsourced. Earlier chatbot programmes reach modest deflection and a satisfaction score well below the human baseline — the familiar pattern where the bot handles easy cases badly and everyone learns to type "agent" immediately.

The reason is structural. The bot can read a knowledge base. It cannot do anything. Every request requiring an action — a plan change, a credit, a SIM swap, a fault ticket — ends in a handover, and the customer repeats themselves to a human who starts cold.

Why the obvious fix does not work

Deflection gets measured as conversations that did not reach a human. That metric rewards a bot that frustrates people into giving up, and it will report success while satisfaction falls.

The honest unit is resolution: the customer's problem is in the state they wanted, and they did not have to ask twice. Measured that way, most deflection numbers are a fraction of what is reported.

The design

Agents with tool access to the systems of record

The agent calls the billing platform, the provisioning system, the fault database, the CRM and the order pipeline directly — each tool with a typed contract and its own permission scope.

An agent that can change a customer's plan is a different product from one that can describe how to change a plan. It is also a different risk, which is what the next two pieces are for.

Approval gates written against real policy, not vibes

Every tool carries a policy written by whoever owns the risk. Applying a small account credit is autonomous. Above a threshold, the agent assembles the case and routes it to a supervisor queue, and the customer is told that is happening. Cancelling a service is never autonomous. Neither is anything touching a vulnerable-customer flag.

Build exactly what the regulatory team writes, including the parts that look over-cautious. Relaxing a gate later, on the evidence of the traces, is a conversation with a foundation under it.

A hard handover rule

The agent hands to a human on three triggers: the customer asks, confidence on the assembled evidence drops below the lane threshold, or the conversation crosses a distress signal. On handover the human receives the full transcript, the retrieved account context and the agent's own summary of what it tried. Nobody starts cold.

What to measure afterwards

• Resolution rate on the honest definition, not the avoidance one.
• Satisfaction on agent-handled cases against the tier-one human baseline. A well-built agent can beat it, because it holds the whole account in context, never puts anyone on hold, and has no handle-time target.
• Escalation rate — and treat it as a floor to protect rather than a number to drive down. Driving it down makes the agent reluctant to hand over, which moves failures from "escalated unnecessarily" to "resolved incorrectly with confidence".
• Fully loaded cost per resolution.

Where it runs

The operator's own cloud tenancy, in-region, with the agent runtime and every tool call traced: what was retrieved, which tools were called with which arguments, which policy gate applied, and what the customer was told.

That trace store is what answers a regulator asking about automated customer handling, and it is the reason to build it before you need it rather than after.