An AI agent for customer service that resolves, instead of deflecting

Ask a support leader how their automation is doing and the first number you usually hear is a deflection rate — the share of incoming conversations that never reached a human agent. It is an appealing metric because it is cheap to measure and it maps directly to headcount. It is also a metric about the support organisation, not about the person who wrote in.

The customer who opens a ticket saying “I was charged twice for July” has no interest in whether a person read it. They want the second charge gone. Deflection counts that conversation as a win the moment the customer stops replying — whether they got their money back, gave up, or went to their bank to dispute the charge. Resolution counts it as a win only when the refund actually exists in the billing system.

That gap is where most AI customer support automation lives today. The industry got very good at producing plausible replies, and very comfortable calling that success. But the last mile of support is not a sentence. It is a state change in a system of record: a refund issued, a subscription downgraded, an access grant applied.

An answer is a description of the outcome. The completed action is the outcome.

The clearest way to explain what AI ticket resolution means is to walk one realistic request through the whole chain. The names and amounts below are illustrative — invoice INV-2231, €48.00 — but the shape of the flow is the design ai.NEST is built around.

1. The request arrives. A customer writes in plain language: they believe they were billed twice in July. No structured form, no category dropdown. Just a sentence and an expectation.

2. The agent establishes the facts. Before anything is proposed, the agent reads what it is connected to: your refund and billing policy in the knowledge layer, and the customer’s actual billing records in your data. It confirms there are two charges for the same period, and that only one invoice is legitimate. If the records do not support the claim, the correct proposal is no action plus an explanation — and that too is a resolution.

3. The agent proposes a concrete action. Not “you may be eligible for a refund”, but a specific, machine-readable proposal: refund €48.00 against invoice INV-2231, grounded in the duplicate charge it found and the policy clause that covers it. At this point nothing has run. A proposal is an intent, not an effect.

4. The Policy Engine checks it. The proposal is evaluated against your rules before it can touch anything: is the requesting role allowed to issue refunds? Is refund in the catalogue of actions this agent may take at all? Is €48.00 inside the automatic threshold, or above it? Rules are explicit, written by you, checked every single time — nothing is decided by the model’s confidence in itself.

5. A human approves — in one click, when the rules say so. Under your auto-approve limit, the action proceeds. Over it, the proposal waits in a queue with everything an approver needs already assembled: the request, the evidence, the exact action, the rule that routed it here. Approving is one button. Rejecting is one button, and the action never runs.

6. The Executor carries it out. The refund is issued through your billing API, with scoped credentials, as an idempotent call. The model never holds a key and never calls your systems directly; it only ever produced a proposal that your policy cleared.

7. Everything is written down. What was proposed, what evidence it was grounded in, which rule decided it, who approved it, what actually executed, and what the API returned. One row, one story, reconstructable months later.

8. The customer gets a confirmation, not a promise. “Your duplicate July charge of €48.00 has been refunded to your card” — sent after the money moved, not instead of it.

It is worth being precise about what is missing when a support AI stops at text. A fluent reply is not something a bigger model fixes — it is a scope problem. Most of the work in support was never linguistic:

• Retrieving the right facts about this customer, from live systems, at the moment of the request — not from a stale export.
• Deciding what should happen, and being specific enough that a machine could do it.
• Being allowed to do it — by role, by action type, by amount.
• Actually doing it, in the system where it counts.
• Leaving a record that survives the conversation.

Text-only support AI does the first step and then hands the remaining four back to a human — which is exactly the work that made the queue expensive in the first place. This is the reframe worth holding on to: what a support team needs is not a chatbot that deflects the conversation, but an agent that completes the action and can prove what it did.

Autonomy without a governed path to execution is a demo; execution without governance is a liability. The interesting engineering sits in the middle — the subject of our piece on human-in-the-loop AI.

If you change the metric, you change the system you end up building. That is not a slogan — it follows mechanically from what each metric rewards.

Optimise for deflection and you invest in topic coverage, tone, and the ability to keep a conversation going without escalation. The failure mode you are blind to is the customer who accepted an answer that fixed nothing. Those tickets look identical to successes in your dashboard, and they resurface later as churn, as a chargeback, or as a second and angrier ticket — usually attributed to something else.

Optimise for resolution and the questions change. Which actions is the agent allowed to perform? What share of requests map to an action in that catalogue at all? Of the proposals it makes, how many are approved unchanged — and where do approvers keep editing or rejecting, because that is your policy telling you something?

Those questions are answerable only if proposals and executions exist as first-class, logged objects — the same infrastructure that makes the agent safe. Governance and measurability turn out to be the same thing; you can see the shape of it on our platform overview.

Deflection asks: did the human avoid the ticket? Resolution asks: did the customer get their money back?

Most support organisations that want this do not have machine-learning engineers, and should not have to hire any. ai.NEST is delivered as a managed, dedicated EU-hosted instance — no cluster for you to run, no model for you to fine-tune. What follows is how we design the rollout to work: a principle, not a case study. The product is in private beta.

• Start read-only. Connect the knowledge — refund policy, billing rules, escalation matrix — and the customer data the agent needs to verify claims. In this phase the agent explains and drafts; it changes nothing. You get to see whether its reasoning is right before you ever let it act.
• Pick one action, not ten. A single high-volume, reversible, idempotent operation — refunds are the classic first choice; subscription changes and access grants are close behind. Nothing outside that catalogue is even proposable.
• Write the rules narrowly. A low auto-approve threshold, one approver role, everything else waiting for a human. It should feel almost too conservative in week one.
• Run in shadow, then in the open. Let the agent propose while humans execute manually, and compare. The approve/reject/edit pattern is your policy specification, discovered empirically.
• Loosen deliberately. Raise the threshold only where the log gives you a reason to. Widen the action catalogue only when the first action is boring.

What is real today: the knowledge layer, the data layer, and roles with tenant-scoped permissions. What is being built: chat end to end, and the Actions and Policy Engine that turn a proposal into a governed execution — those are in private beta and land with early-access customers first. If you want the deep version of how retrieval feeds a proposal, we wrote it up in enterprise RAG.

The moment an AI agent for customer service is allowed to move money, someone will eventually ask why a particular refund happened. If your answer is a chat transcript, you have a story. If your answer is a record — proposal, evidence, rule applied, approver, API call, result — you have an account.

That distinction matters far beyond audits. It is what lets you loosen policy safely, because you can see which decisions were good. It is what lets an approver trust a queue instead of re-investigating every item. And when obligations under regimes like DORA or the AI Act require you to show how an automated decision was made, the evidence exists as a by-product of how the system runs — not as a reconstruction exercise months later.

We build it as one chain, in one order, and we do not skip a link: AI proposes → the Policy Engine checks role, action and limit → a human approves when the rules say so → the Executor runs it through your API → the audit log records all of it. Everything else in the product is a consequence of that sentence — including how we price it.