DEV Community

Michael Tuszynski
Michael Tuszynski

Posted on • Originally published at mpt.solutions

Getting Customers to Trust an Agent That Acts on Their Behalf

Part 2 of 2 on agentic system adoption. Part 1 covered internal adoption: getting your own team to actually use the agent you built.

In February 2024, Klarna announced that its AI assistant had handled 2.3 million customer conversations in its first month — two-thirds of all customer service chats, doing the work of 700 full-time agents, with resolution times down from 11 minutes to under 2. It was the poster child for agentic deployment.

Fifteen months later, CEO Sebastian Siemiatkowski conceded that the rollout had produced "lower quality" service. Klarna started rehiring humans.

If you're shipping agentic features to paying customers — users who can churn the moment the agent confidently does the wrong thing — Klarna's arc is your warning. Internal adoption (covered in Part 1) dies quietly. Engineers stop using the tool and find a workaround. External adoption dies loudly. Customers post screenshots, file chargebacks, and leave.

External adoption isn't a feature launch. It's a trust contract. And the contract has five terms.

The stakes are different

When internal adoption fails, your throughput drops 1.5% and your delivery stability drops 7.2% (the DORA 2024 numbers I cited in Part 1). When external adoption fails, the consequences look more like:

  • Air Canada was ordered by the BC Civil Resolution Tribunal in February 2024 to pay a customer whose refund policy the airline's chatbot had invented. Air Canada's defense — that the chatbot was "a separate legal entity" — was rejected. Your agent is legally you.
  • DPD had its customer service chatbot, after a system update, swear at a customer and insult the company in a haiku. The screenshot hit 800,000 views in 24 hours. DPD pulled the AI element within the day.
  • McDonald's killed its IBM-powered voice-AI drive-thru in June 2024 after a hundred-plus restaurant pilot. The proximate cause was viral TikToks of the agent adding bacon to ice cream and ordering 260 McNuggets unprompted.

All three stories have the same structure: the agent confidently did the wrong thing, the failure mode was visible to users before it was visible to the company, and the choice was recall or litigate. None of them chose "iterate in place."

Here's how you don't end up there.

1. Make the undo obvious

The Nielsen Norman Group has ranked "user control and freedom" as the third core usability heuristic for decades. In plain language: users need an emergency exit.

For agentic products, this is move number one. A button that says "undo this action." A visible confirmation before anything moves money, sends messages, or modifies customer state. A "revert to before the agent touched this" option.

The reason is psychology: users experiment more when they know they can back out. That experimentation is how they learn what the agent is actually good at. Without an obvious undo, the first surprise is a last surprise — the user closes the tab and doesn't come back.

In NEXUS, every time my content pipeline drafts a LinkedIn post, Slack gets an approval with edit/reject buttons. Nothing posts without me hitting approve. That approval surface isn't a development stage; it's the product. Remove it and I don't trust the pipeline, even though I built it.

2. Signal uncertainty

Overconfidence is how agents lose users. The agent that says "here's your answer" and is wrong burns more trust than the agent that says "this looks likely but I'd double-check" and is wrong.

This isn't a UX trick. It's a calibration problem. Most LLM-powered agents have the confidence signal available — log probabilities, retrieval scores, constraint violations — and throw it away before it reaches the user. Surface it.

Concrete patterns that work:

  • Show which sources the agent used. If the retrieval score is low, say so.
  • When the agent takes an action based on an ambiguous instruction, show the interpretation it chose and offer the alternative.
  • Flag "this is outside the agent's usual scope" when the request deviates from a known pattern. Don't let the agent bluff.

Air Canada's chatbot didn't hedge. It invented a refund policy with full confidence. If it had said "I'm not 100% sure about the bereavement policy — let me route you to a human," Air Canada would have lost nothing. Instead, they lost a court case and a reputational hit still being cited two years later.

3. Tell them what the agent won't do

Scope boundaries build trust. If the agent is going to draft replies but never send them, say so on the label. If it will summarize but not delete, say so. If it will take action inside the product but never touch external systems, say so.

The EU AI Act, Article 50, now requires disclosure when users interact with AI systems. That's the regulatory floor. The product floor is higher: tell users not just that they're talking to an agent, but what the agent's blast radius is.

Users who know the limits stop testing them. Users who don't know the limits probe until they find the edge, and the edge is always embarrassing.

4. Price for non-determinism

This is the move most teams miss. Agentic systems have variable cost per interaction — tokens, tool calls, retries — and if you pass that variability through to the customer via token-based pricing, you're asking them to bet on their own workload. Most will churn the first time a 5x cost spike hits their bill.

Intercom's Fin AI agent prices at $0.99 per resolution. Their definition of "resolution" is itself a product decision: the outcome is counted when a customer confirms the issue is resolved, when they don't follow up after Fin responds, or when Fin completes a workflow. One charge per conversation, regardless of how many messages it took.

That's a pricing model that says to the customer: the variability is my problem, not yours. Teams adopting outcome-based pricing are absorbing the non-determinism into their margin instead of their customer's budget.

If your pricing page requires a customer to model their own token usage to predict monthly cost, you've shifted your operational risk onto their finance team. They will fire you and buy from someone who didn't.

5. Make failure modes visible

The DPD chatbot didn't start swearing on its first day. It started failing after a system update. Somewhere, someone had logs. The failure was visible internally — to nobody who was watching — before it was visible externally, to everyone who was.

Build the visibility into the product. For every action the agent takes, the user (and your on-call) should be able to answer three questions within 30 seconds:

  1. What did the agent try to do?
  2. What did it actually do?
  3. What did it decide not to do, and why?

For paying customers, this often lives in an activity log, an audit trail, or an admin dashboard. It doesn't have to be beautiful. It has to be complete. When a customer files a ticket saying "the agent did something weird," the ticket is cheap to resolve if the log is there. If it isn't, you're reconstructing state from memory, and the customer's story beats yours in court.

How you know it's working

For internal agents, I track daily active use by engineers who aren't on the project team. For external agents, the leading indicators are different:

  • Unprompted return rate. Users who came back without a marketing nudge. Internal usage can be mandated; external cannot.
  • Override rate trending down. If customers are manually correcting the agent less over time, trust is rising.
  • Escalation-to-human rate holding steady, not dropping to zero. An agent that never escalates is one that's confidently wrong. Healthy agents know their limits.
  • Net revenue retention on accounts that opted into the agent. The hardest proof: do customers expand after the agent ships, or contract?

Klarna is the cautionary tale for all of these. The launch numbers looked spectacular. The retention numbers told a different story, quietly, for a year, until Siemiatkowski had to say the quiet part out loud: "cost was a too predominant evaluation factor… what you end up having is lower quality."

Closing

Internal adoption dies in the gap between demo and fourth use. External adoption dies the moment the agent confidently does the wrong thing to a customer who's paying attention.

Both failures are preventable. Both require the same underlying discipline: trust is earned on boring interactions, not hero ones. The patterns that build internal trust — readable logs, obvious override, default to boring — scale externally if you take them seriously.

Air Canada, DPD, McDonald's, and Klarna all had one thing in common. Their agents worked in the demo. They worked with the pilot group. They worked for the first thousand users. Then the distribution shifted, or an update went out, or a customer asked a question nobody had predicted, and the agent confidently did the wrong thing.

The companies that keep shipping agentic features — and keep their customers — aren't the ones with the smartest agents. They're the ones whose agents know what they don't know, whose pricing absorbs the variance, and whose undo button is bigger than the agent.

Top comments (0)