How to Build an AI Customer Support Agent (Resolution, Not Deflection)

An AI customer support agent is a retrieval and routing system with a chat window on top. You build it in four moves: pick the ticket types it is allowed to own, give it the exact documents and lookups that answer them, define the small set of actions it may take, and hand everything else to a person with the context attached. The model is the smallest decision you will make.

TL;DR

• Gartner predicts agentic AI will autonomously resolve 80 percent of common customer service issues by 2029, cutting operational costs about 30 percent. Note the year.
• Klarna's assistant handled 2.3 million conversations in its first month, two-thirds of chats, with average resolution falling from 11 minutes to under 2, per Klarna's own release.
• Roughly a year later Klarna was recruiting human agents again, with the CEO saying cost had been "a too predominant evaluation factor" and the result was lower quality.
• Deflection is not resolution. Deflection counts every ticket a human never touched, including the customer who gave up and emailed you from a different address.
• Scope it to the five intents that carry most of your volume, with a deterministic answer behind each one. Everything else escalates on day one.

Read the ticket log before you write a prompt

The first week of this project has no model in it. Export the last ninety days of conversations, cluster them by what the customer actually wanted, and count.

Almost every support queue is lopsided. Five to ten intents usually carry 50 to 70 percent of volume, and they tend to be the same ones: order status, refund status, delivery date, password or login, plan or seat change, billing address, cancellation. What matters is not the count but what sits behind each intent.

An intent qualifies for automation when three things are true. The answer is deterministic, meaning it exists in a system you can query rather than in someone's judgment. The source of truth is reachable through an API or a document you control. And a wrong answer is cheap to reverse, so a mistake costs a follow-up message rather than a chargeback.

"Where is my order" passes all three. "I was charged twice and I am furious" fails the third one badly. Sort your list that way before anything else, and the scope of version one writes itself.

Three lanes, decided before the first token

Every incoming conversation goes down one of three lanes. Decide the lane with a classifier and a confidence floor, not with the answering model's own optimism.

Lane three is the one to ship first, and almost nobody does. It is tempting to build the answering path and treat escalation as a fallback you will wire up later. Do it the other way around. If handoff works on day one, a bad answer costs you one message. If it does not, a bad answer costs you the customer.

Put a hard never-automate list in code, not in a prompt. Fraud, account security, payment disputes, anything with a legal or medical edge, and any message where the customer says cancel, lawyer, or complaint. Those route to a person regardless of how confident the classifier feels.

Retrieval is the product

The quality difference between a support agent people trust and one they route around is almost entirely retrieval. Two sources feed it, and they behave differently.

Static knowledge is your help center, policy pages, and internal runbooks. Chunk by heading rather than by character count so each chunk is a complete thought, and keep the source URL as metadata on every chunk so the answer can link to it. I wrote the full approach in how to chunk documents for RAG. The rule that matters most here: if nothing clears your similarity threshold, the agent does not answer. It escalates. An agent that says "I do not have that" and hands off beats one that improvises a policy you do not have.

Live state is the order record, the subscription, the shipment, the invoice. That is a tool call, not a vector search, and it is where most of the real answers live. Connect it through a scoped read-only credential. If you are wiring these connections, THE MCP BIG THREE covers the three connections worth setting up first.

Two rules keep this honest. Every factual claim in the reply carries a link or a record ID the customer can check. And every answer that touched live data includes the timestamp of the lookup, because "your order shipped" ages badly.

Actions: read wide, write narrow

Reads can be generous. Writes need a leash.

Give the agent broad read access to orders, tickets, shipments, and subscriptions. Then define the write actions as an explicit, tiny list with limits baked into the tool itself rather than into the prompt:

• Issue a refund up to a fixed dollar amount, on orders under a set age, once per conversation, logged with the ticket ID.
• Resend a shipping confirmation or a receipt.
• Update a delivery address before the fulfillment cutoff.
• Cancel an order that has not shipped.

Anything outside those bounds becomes a draft with an approve button. That pattern is covered in human in the loop AI agent, and support is the clearest case for it because the approval queue doubles as your training data for what to automate next quarter.

One thing that catches teams late: ticket text is untrusted input. A customer can paste instructions into a support message, and a forwarded email or an attached PDF can carry them too. Treat every retrieved document and every customer message as data, never as instructions. The full pattern is in how to prevent prompt injection.

Measure resolution, not deflection

This is where most support AI projects quietly fail while the dashboard stays green.

Track four numbers and nothing else at first:

True resolution rate. No human touched it, and that customer did not contact you again about the same issue within seven days, on any channel. The cross-channel part is what makes this number honest.

Escalation rate, split by reason. Low confidence, never-automate list, customer asked, two failed attempts. The mix tells you what to fix. A rising "two failed attempts" share means your retrieval is thin, not that your model is weak.

Time to resolve after handoff. This measures the quality of your context package, not the agent. If it is worse than a cold ticket, your handoff is dumping a transcript instead of a summary.

CSAT split by lane. Blended CSAT hides everything. Structured intents like password reset tend to score close to human handling. Sentiment-heavy intents like billing disputes trail, which is an argument for routing them, not for a better prompt.

The handoff is the whole trust story

When lane three fires, the human should receive a package, not a wall of chat. Four things: a one-line summary of what the customer wants, the intent the classifier picked and its confidence, the records the agent pulled with timestamps, and what it already tried and why that failed.

That last item prevents the worst experience in AI support, which is a customer explaining their problem for the third time to someone who cannot see the first two attempts. Agents who inherit full context close escalations meaningfully faster than agents starting cold, and the customer feels the difference immediately.

Klarna is the case study worth reading twice. The February 2024 numbers were real: 2.3 million conversations, 23 markets, 35 languages, resolution time down from 11 minutes to under 2. The correction was also real. By May 2025 the company was hiring support people again, with the CEO conceding they had underestimated the tradeoff and that optimizing on cost produced lower quality. The technology worked. The org chart got ahead of it.

Run it as a loop, not a launch

Once one lane is live, the work becomes weekly and boring, which is the point.

Every week, pull the twenty worst conversations by CSAT and re-contact, and label each failure with one cause: missing document, missing tool, wrong routing, or wrong wording. Fix them in that order. Missing documents and tools account for most failures and cost nothing to fix. Prompt wording is last because it is the thing everyone reaches for first and the thing that changes the least.

Freeze forty of those real conversations into an eval set and run it before every prompt change and every model swap. How to test an AI agent has the full setup. If you want the working pattern for running any AI system as a repeatable loop instead of a one-off prompt, WRITE LOOPS NOT PROMPTS is the resource I hand people first.

I send one build like this every week, with the prompts and the numbers attached. You can join the newsletter if you want them.

The bottom line

An AI customer support agent is not a chatbot with a better model behind it. It is a triage system: a classifier that picks a lane, retrieval that grounds every claim in a document or a record, a short list of bounded write actions, and a handoff that arrives with context. Build the escalation path first, scope version one to the intents with deterministic answers, and measure resolution with a seven-day re-contact window instead of deflection.

Do that and the ceiling raises itself over the next two quarters, one intent at a time. Skip it and you will have a dashboard reporting 45 percent while your inbox reports otherwise.