A woman in white faces a glowing glass sphere on a pedestal, linked by threads of light to floating icons for phone, chat, email, laptop, support headset and shopping cart, in a pale misty landscape.

// the decisions that turn AI into business value

Agentic Customer Experience: The AI Can Act. Should It?

Illustration, AI generated.

AI agents can now check the bill, issue the refund and hand over to a human. The hard part is deciding which of those they should do, and proving it paid off.

By Onur Sirin · · 19 min read

Advertisement

Nobody rings their mobile operator for fun. They ring because the total at the bottom of this month’s bill is bigger than last month’s, because the app showed them the number but not the reason, and because the chat assistant answered a question they had not asked. By the time a human picks up, the customer has explained the problem to two machines already and is in no mood to do it a third time.

Now put that customer’s operator in a strategy meeting. It is a composite rather than any one client, but the pattern will be familiar to anyone who has sat in that room. The ambition on the first slide is clear: let AI handle a large share of billing calls. The brief says more automation. The trouble is that “Why did my bill go up?” is not one problem. The customer may not have understood a new tariff, an introductory discount may have quietly ended, they may have been charged wrongly, or someone may have promised them something that never happened. All four land in the same call category, and none of them needs the same answer.

That leaves the only question worth asking at the start: are we automating the customer’s request, or fixing the reason they had to make it? Sometimes the most effective AI project is not really an AI project at all. It is a clearer first bill, a tariff change explained properly, or a message that arrives before the surprise does. Preventing, simplifying, assisting and automating are four different interventions, and automation is rarely the first one to reach for.

01/ The stakes

Why agentic AI raised the stakes

For most of the chatbot era, a bad answer cost the customer a minute and the company a little goodwill. Agentic AI changes that arithmetic, because the agent no longer only talks. Across contact centre and CRM platforms, the new generation of AI agents reasons across several steps, calls tools (increasingly through open interfaces such as the Model Context Protocol) to do things like processing refunds and updating records, and keeps the conversation going until the issue is resolved or a human is needed. Many platforms also let teams mix fixed, rule-based steps with agentic ones inside the same customer journey.

Once an agent can move money and change records, the design problem stops being about chatbot quality. It becomes a question about how the company decides: who is allowed to do what, within which limits, and how anyone can tell afterwards that the outcome was right. The cleanest way to see it: an agent with tools is a new kind of employee with permissions. It needs a role, the narrowest access that lets it do the job and an audit trail, and it deserves the same scrutiny as the people it works beside.

If you want to see what happens when that decision is made on the wrong axis, Klarna has already run the experiment in public. In February 2024 the Swedish fintech announced that its OpenAI-powered assistant had handled 2.3 million conversations in its first month, two thirds of its customer service chats, doing the equivalent work of 700 full-time agents. Fourteen months later, chief executive Sebastian Siemiatkowski told Bloomberg that cost had weighed too heavily in how the operation was organised, and that the result was “lower quality”. Klarna started recruiting human agents again and promised customers they could always reach one.

The assistant was not broken. By Klarna’s own figures it was fast and it was busy. What went wrong was the weighting of the scorecard, and that is a strategy failure long before it is a technology one. It is the argument we made in The hard part was never the technology: we commoditised intelligence, not judgement.

02/ Decision chain

The decision chain, in eight links

So where should a strategist start when a company says it wants AI in its customer experience? Not with a catalogue of use cases. I work through eight decisions, in order, and each one produces the evidence that makes the next one possible. Treat it as a chain of evidence rather than a checklist, because a weak link anywhere quietly invalidates everything after it.

The strategist's decision chainEight decisions in order. Business priority, customer problem, outcome and baseline, and intervention decide what to fix. Operating and authority model, economic case, evidence and adoption, and repeatable go-to-market prove it and make it repeatable.

Prove it, then repeat it

5. Authority model
Who may do what, up to which limit?

6. Economic case
Capacity, cash or contribution?

7. Evidence and adoption
Scale, change, narrow or stop?

8. Repeatable go-to-market
What carries to the next customer?

Decide what to fix

1. Business priority
Which outcome must change, and why now?

2. Customer problem
What is the customer really asking?

3. Outcome and baseline
What counts as success, and as failure?

4. Intervention
Prevent, simplify, assist or automate?
Figure 1. The first four links decide what to fix. The last four prove the fix was worth it and make it repeatable, and what they teach feeds the next business priority.

Skip a link in the first half and you tend to discover the gap in the second, usually in front of a finance committee. The rest of this piece walks the chain one link at a time, with the operator’s billing problem as the thread.

03/ Stage 1: Leadership

Stage 1: What does leadership actually want to change?

The first question is not which AI use cases the company could build. It is which business outcome needs to change over the next planning cycle, and why now. In our operator, the chief customer officer wants fewer customers leaving, the chief operating officer wants the operational load under control, the chief financial officer wants a better cost structure, and the chief information officer wants a fragmented technology estate to become simpler. Those are four goals sharing one meeting, and treating them as one goal is how programmes end up optimising for whoever spoke last.

The strategist’s job is to build one investment case that all four can sign, and to shrink “better CX” into a scope narrow enough to measure. For example: reduce repeat contacts in the first-bill experience after a tariff change, speed up the correct resolution, and do it without increasing complaints. That last clause is a quality guardrail, and it is precisely the kind of clause Klarna’s scorecard appears to have underweighted.

Four executive goals, one investment caseThe chief customer officer wants fewer customers leaving, the chief operating officer wants operational load under control, the chief financial officer wants a better cost structure and the chief information officer wants a simpler technology estate. All four feed one shared investment case, which becomes a scoped problem for the first bill after a tariff change, with a guardrail of no rise in complaints.

Chief customer officer
fewer customers
leaving

Chief operating officer
operational load
under control

Chief financial officer
a better
cost structure

Chief information officer
a simpler
technology estate

One shared
investment case

Scoped problem
First bill after a tariff change:
fewer repeat contacts,
faster correct resolution

Guardrail:
no rise in complaints
Figure 2. Four executive goals become one investment case, and “better CX” becomes a scope specific enough to measure.

Programme management made the same argument long before anyone attached an agent to a contact centre: tie the investment to a business outcome, identify the expected benefits up front, and measure them as they are realised. The output of this stage is deliberately unglamorous: a named problem owner, an investment rationale, a target outcome and the quality limits that must hold. There is no product choice yet, and that is the point. It is the same use-case-first discipline we applied to infrastructure in our NVIDIA AI factory blueprint.

04/ Stage 2: Customer

Stage 2: What is the customer really asking?

“Billing enquiries” is an operations category. It tells you where the work lands, not why it arrived. To find the real need, I would combine customer conversations reviewed under proper authorisation, CRM records, reopened cases, transfers and the observations of the agents who take these calls every day. The front line usually knows the root cause long before the dashboard does.

The distinction that matters in our operator is simple to state. Can the customer not reach the information, not understand it, not complete an action, or do they dispute a decision the company made? Each calls for a different response. An information gap can be closed with a well-grounded answer, a wrong charge needs a transaction, and a policy exception needs someone with the authority to grant it.

One call category, four different problemsThe question why did my bill go up can mean four things. A customer who did not understand the new tariff needs a clear explanation grounded in their own bill. A customer whose introductory discount ended needs to be told before the bill lands. A customer who was charged incorrectly needs a verified correction or credit. A customer whose promise was not kept needs an authorised human decision.

Why did my bill go up?

Did not understand
the new tariff

Introductory discount
quietly ended

Charged
incorrectly

A promise
was not kept

Understanding gap
Clear explanation,
grounded in their bill

Expectation gap
Tell them before
the bill lands

Transaction needed
Verified correction
or credit

Decision needed
Authorised
human judgement
Figure 3. One call category, four different problems. The colours match the four interventions in Stage 4.

Then zoom out from the call itself. Our customer tried the app first, moved to chat, and only then picked up the phone. The call is the last chapter of the problem, not the problem, and a project that measures only the call will end up optimising the ending of a story it never read.

One question, three channelsThe customer sees a higher total in the app but no reason for it, asks the chat assistant and gets generic tariff text, then waits in the phone queue and explains everything a third time. Frustration rises at every hop, so the phone call is only the last chapter of the problem.

unsure

annoyed

App
higher total,
no reason given

Chat
asks why, gets
generic tariff text

Phone
waits, then explains
it a third time
Figure 4. By the time the phone rings, the customer has already been failed twice.

The output of this stage is a real baseline: the customer need, its root cause, the current resolution path, the breaks between channels, and the numbers as they stand today. Without that baseline, every improvement claimed later is an opinion with a chart attached.

05/ Stage 3: Success

Stage 3: Separate success from the dashboard

This is the link where programmes most easily fool themselves, so it is worth slowing down. Did the AI respond? Did the action technically complete? Was the customer’s need actually met? Those are three different questions, and a dashboard can answer yes to the first two while the honest answer to the third is no.

Platform dashboards are honest about this, if you read the small print. They tend to lead with health metrics, such as the share of agent or tool calls that completed without a technical error. That is a genuinely useful signal, and it is also not evidence that anyone’s bill got fixed. So I measure in three layers.

LayerThe question it answersExample evidence
Technical operationDid the agent and its tool calls run, and did the data come from the right system?Invocation and tool success rates, latency, traces
Customer outcomeWas the right action completed, and did the customer have to come back?Verified resolution, repeat contacts, customer effort
Business valueDid the total cost to resolve, service quality or the commercial result improve?Cost per verified resolution, complaints, churn in the affected segment

The trap lives in the gap between the first two layers. A contact that was never transferred to a human is not automatically a successful self-service contact. The customer may simply have given up, or come back the next day through another channel, which moves the cost instead of removing it. A good evaluation form for self-service keeps two questions apart: was the contact handled without a transfer, and did the customer actually get at least one of their needs met? Merging them into a single containment number is how the gap disappears from view.

Containment is not resolutionA contact that ends without a transfer to a human can mean three things. The need was met and verified, which is real self-service success. The customer gave up, which is still counted as contained. Or the customer came back through another channel, which moves the cost rather than removing it.

Yes, verified

No, gave up

No, came back

Contact ends without
a human transfer

Was the customer's need
actually met?

Resolved
Real self-service
success

Abandoned
Counted as
contained anyway

Repeat contact
Cost moved,
not removed
Figure 5. Containment is not resolution. Only one of these three branches is a success.

The headline measure I would propose is total cost per verified resolution, always read next to resolution rate, repeat contacts, customer effort and quality, so that nobody can look successful by counting only the easy cases. The output of this stage is a definition of success, a measurement method, an observation window and a written list of the results that will count as failure. Writing that list before the pilot starts is the cheapest insurance a programme can buy.

06/ Stage 4: Intervention

Stage 4: Choose the right intervention, not the most autonomy

With a real problem and an honest scorecard, the options can finally be compared: fix the process, improve the existing self-service, support the human agent with AI, automate specific actions, or combine them. Next to the question “can AI do this step?” I always put a second one: does this step need to be given to AI at all?

Choosing the interventionFor a recurring customer need, first ask whether the reason for contact can be removed, which means prevent. If not, ask whether a clearer path would let the customer solve it alone, which means simplify. If not, ask whether it needs judgement, empathy or policy authority, which means assist a human. Only if the action is rule-bound, reversible and within limits does it make sense to automate. Otherwise assist.

Yes

No

Yes

No

Yes

No

Yes

No

A recurring customer need

Can we remove the
reason for contact?

Could the customer solve it
alone with a clearer path?

Does it need judgement,
empathy or policy authority?

Is the action rule-bound,
reversible and within limits?

Prevent
Fix the bill, warn
before it lands

Simplify
Clearer self-service
and content

Assist
AI prepares,
a human decides

Automate
AI acts, logged
and verifiable
Figure 6. The intervention decision tree. Autonomy is the last branch, not the first.

Walk the billing journey through that tree and the allocation almost writes itself. Explaining the bill needs the right data and a clear narrative, which an AI agent grounded in the billing system handles well. The calculation itself must come from the rules in the source system, never from a language model doing arithmetic with confidence. A refund belongs behind identity and authority checks, and a request outside policy goes to a person.

Assisting the human is often dismissed as the timid option. The evidence is kinder to it. In a study published in The Quarterly Journal of Economics, Erik Brynjolfsson, Danielle Li and Lindsey Raymond followed 5,172 customer support agents at a Fortune 500 software firm through the staggered rollout of a generative AI assistant. Issues resolved per hour rose by 15 percent on average. Less experienced agents improved in both speed and quality, the most experienced saw small gains in speed and a small dip in quality, and customers became less likely to ask for a manager.

That is one company and one assistant, not a performance promise for autonomous agents, and I would not stretch it further than that. But the authors also found suggestive evidence that the tool spread the practices of the strongest agents to newer ones, and that is the part I find most useful. The first investment decision should not be about removing the human. It should be about which working model produces the better outcome for this specific customer need. The output of this stage is the chosen intervention, the reasons the alternatives lost, and the first implementation scope.

07/ Stage 5: Authority

Stage 5: Decide who is allowed to do what

This is where technology and the business finally meet, and it is where most of the real work hides. Knowing the right answer is not enough. The agent has to reach the system that holds the truth, the action it takes has to be authorised, and when something goes wrong, someone specific has to own it.

Five questions do most of the work. Who owns the information? Who is allowed to change the business rule? Which actions can the agent take, and up to what limit? What context does a human see when they take over? Who owns the service once it is in production? For an agent that issues credits, we are not only writing a prompt. We are designing how the right customer is verified, the limit on each action, the guarantee that the same credit cannot be issued twice, and what happens when a step fails halfway through.

Authority and handover in a billing disputeThe customer asks why the bill went up. The AI agent verifies identity before sharing any account data, fetches the invoice and tariff history from the billing platform and explains it line by line. When the customer disputes a roaming charge, the agent checks policy, evidence and its credit limit. Within policy and limit, it issues the credit once through the billing platform and gives a reference. Outside policy or above the limit, it hands over to a human with the request, the actions taken and the open decision.Human agentBilling platformAI agentVerify identity beforesharing any account dataCheck policy, evidenceand credit limitalt[Within policy and limit][Outside policy or above limit]CustomerWhy did my bill go up?1Fetch invoice andtariff history2Discount ended,plus a roaming charge3Line-by-line explanationfrom source data4I never used roaming5Issue credit once(idempotent, logged)6Credit confirmed7Credit applied,reference given8Handover: request, actionstaken, open decision9Decides with the full context10
Figure 7. Identity before data, limits before money, and a handover that carries the context with it.

Look at the handover at the bottom of that diagram. It should never be a button that drops the customer back into a queue. The person taking over needs to see what the customer asked for, what the agent has already done, which step failed and which decision is still open. A handover that makes the customer start again is not a safety net. It is a second failure with a human voice.

Step in the billing journeyWho actsGuardrailNamed owner (illustrative)
Explain the billAI agentAnswers only from billing system dataBilling operations
Recalculate the chargeSource system rulesNo generative arithmeticBilling platform team
Credit within the limitAI agentVerified identity, per-action limit, issued once and loggedCustomer operations lead
Exception outside policyHuman agentAuthorised decision, reason recordedTeam leader

There is also a quieter third path. Instead of changing everything at once, pick a narrow entry point that works alongside the customer’s existing CRM and operating rhythm. Many agent-assist products can now sit inside the employee workspace or CRM a team already uses, rather than demanding a new desktop. Whether that fits a given estate needs its own assessment, but it means the first step does not have to be a platform migration. The output of this stage is an end-to-end service design, its system dependencies, the decision rights, the exception path and named operational owners.

Advertisement

08/ Stage 6: Business case

Stage 6: A business case that survives the CFO

Minutes saved are the most seductive number in any AI business case, and the least trustworthy. Freed capacity, cash savings and incremental commercial contribution are three different things, and a case that blurs them will be taken apart by the first finance director who asks where the money actually goes.

Keeping the business case honestMinutes saved become a cash saving only if a cost actually leaves the budget; otherwise they are freed capacity, such as more customers served, hiring deferred or time for complex cases. A revenue uplift counts as incremental contribution only if it is attributable to the AI and measured on margin; otherwise it stays out of the case until it has been tested.

Yes

No

Yes

No

Minutes saved

Does a cost leave
the budget?

Cash saving
on the savings line

Freed capacity
more customers served,
hiring deferred, time
for complex cases

Revenue uplift

Attributable to the AI,
measured on margin?

Incremental
contribution

Not in the case yet
test it before
you claim it
Figure 8. Capacity, cash and contribution stay on separate lines. Anything that cannot be attributed stays out.

If agents work faster but no cost leaves the budget, that is not a cash saving. It is capacity: more customers served, a hiring need deferred, more time for complex cases. It is real value and deserves to be shown, but on its own line. On the revenue side, I would look past the conversion rate and ask two harder questions: can the uplift actually be attributed to the AI intervention, and what did it do to contribution margin rather than to revenue?

Costs deserve the same honesty. Platform consumption is the easy line. Integration, data preparation, testing, training, operations, human takeovers and, where needed, running old and new systems in parallel all belong in the total. Pricing itself resists shortcuts. Depending on the vendor it may be per minute, per message, per conversation or per resolution, telephony and third-party components are often billed on top, and rates can vary by region. Vendor pages are also fond of promising payback within months, often citing a study the vendor commissioned. Treat any such figure as a hypothesis to test against the customer’s own numbers, not a figure to paste into the spreadsheet.

The output of this stage is an investment case with visible assumptions, several scenarios, and a named owner for every benefit. A benefit without an owner is a wish with a spreadsheet attached.

09/ Stage 7: Pilot

Stage 7: A pilot that is allowed to say no

Most pilots are designed to prove that the technology works. That is necessary and nowhere near sufficient. At the top of every pilot plan I would write one sentence: which evidence will make us scale this, and which will make us narrow it or stop?

A pilot with four agreed exitsA scoped pilot limited to first-bill questions runs against comparable groups and periods, then reaches an evidence review against criteria agreed up front. The review has four exits. Change the design when the value is real but the design is wrong. Scale when outcome, economics and adoption are proven. Stop when there is no verified value. Narrow the scope when it only works for a subset. Change and narrow both return to running.

Scoped pilot
first-bill questions only

Running
comparable groups
and periods

Evidence review
against criteria
agreed up front

Change
value is real,
design is wrong

Scale
outcome, economics
and adoption proven

Stop
no verified
value

Narrow
works for
a subset only
Figure 9. The exits are agreed before the pilot starts, and only one of them is scale.

Technical validation proves the agent runs. Proving value means comparing like with like: comparable customer needs, comparable agent groups and comparable periods, judged on resolution quality, usage and economic effect together. In our operator, that means starting only with first-bill questions after a tariff change, keeping complex disputes out of the first scope, and refusing to generalise the result to the whole billing operation.

The human side gets its own evidence. Are agents using the AI’s suggestions, editing them or rejecting them, and why? Which errors do team leaders review? How does the new way of working show up in training and in performance reviews? Modern quality tools can score automated conversations against criteria a manager defines and show the results both in aggregate and contact by contact, but no platform can decide what a good outcome means for this particular business. That judgement stays with the business, and it should. The output is a proven scope, the uncertainties that remain, operational acceptance, and a reasoned decision to scale, change, narrow or stop.

10/ Stage 8: Go-to-market

Stage 8: From one project to a repeatable go-to-market

Designing one implementation for one customer is a different job from building a go-to-market motion that repeats it across many enterprises. The first is a project. The second is a business, and it needs its own decisions.

Start with a narrow entry offer

Instead of a sprawling “AI customer service transformation”, take something narrow and well defined to market. For example: a first-bill experience programme for customers who have just changed tariff, covering analysis of current customer needs, a baseline, a bounded solution design, controlled validation and a scaling decision. To become a repeatable package, it needs a target customer profile, the business condition that triggers the problem, the data required, a named buyer, a delivery scope, acceptance criteria and a next commercial step.

Demo enthusiasm is not purchase readiness. When qualifying an opportunity, I keep apart two questions that sales teams love to merge: does this customer have the problem, and can this customer act on it now?

Qualify the problem, then the readinessOpportunities plotted by evidence of the problem against readiness to act. Strong evidence and ready to act means pursue now. Ready to act with weak evidence is enthusiasm without a problem. Strong evidence but not ready means build the case. Weak on both means not yet. Three illustrative archetypes are shown.Pursue nowEnthusiasm, no problemNot yetReal problem, build the caseComplaints rising, no budget yetInnovation lab wants a demoClear pain, funded sponsorWeak evidence of the problemStrong evidenceNot ready to actReady to act nowQualify the problem first, then the readiness
Figure 10. Qualify the problem first, then the readiness. The three points are illustrative archetypes, not data.

Scale the reusable core, not the solution

Across EMEA, “it worked in one country, so let’s roll it out everywhere” is how good programmes go to die. I would split every success into a reusable core and a local adaptation. The core travels: the assessment method, the outcome measures, the integration patterns and the delivery approach. The adaptation has to be proven again in each market: language, channels, business policy, data handling conditions, existing systems and the operating model.

Reusable core versus local adaptationThe reusable core that carries between markets is the assessment method, the outcome measures, the integration patterns and the delivery approach. The local adaptation that must be validated again in each market covers language and channel mix, business policy, data handling and residency, existing systems, the operating model and feature availability by region.

carry

Reusable core
build once, carry everywhere

Assessment method
Outcome measures
Integration patterns
Delivery approach

Local adaptation
prove it again in every market

Language and channel mix
Business policy
Data handling and residency
Existing systems
Operating model
Feature availability by region
Figure 11. What travels between markets, and what has to be proven again in each one.

Even the platform varies. Features rarely reach every cloud region on the same day, and some AI features process data outside the region where the service itself runs. A capability that exists in the product is not automatically available, or acceptable, in every target market, so check both, market by market. The strategic question after every win is easy to ask and hard to answer: which part of this success can we carry to the next customer, and which part must we prove again?

Organise around the customer outcome

Specialist sales, solution architecture, product, customer success, marketing and partners should not appear as a stakeholder list at the bottom of a slide. Each of them owns a decision, and the programme moves at the speed of the slowest one.

RoleThe decision it owns
Specialist salesWhich opportunity is worth pursuing now
Solution architectureWhether the design is feasible in this customer’s estate
PartnerAccountability for delivery
Customer successWhether real usage and value show up in production
ProductWhich recurring blockers deserve a shared capability
MarketingWhich trigger conditions and customer proof carry the offer to the next account

The strategist’s contribution is to make them share the same problem, the same definition of success and the same next step. One uncomfortable point belongs here too: a customer can succeed precisely because it needs fewer contacts. A provider that measures its own growth only by interaction volume ends up rewarding the opposite of what the customer is paying for, so sustained customer value, production usage and expansion into new workflows make far better signals.

11/ Closing the loop

Closing the loop: What should this change in the product?

The last question of any serious engagement is also the easiest to skip: what should this customer change in the product? Not every request belongs on a roadmap, so the first move is to classify the blocker honestly. Is it a missing capability, a missing integration, weak customer data, a badly designed process, a training gap, or a one-off need that is not worth productising yet?

Turning field insight into a product decisionA blocker seen in the field is classified first. A missing product capability goes to product as a roadmap candidate with evidence and a test plan. A missing integration becomes a reusable pattern for partners and architects. Weak customer data is fixed at the source by the customer's data owner. A process design problem goes to the customer's process owner. A training gap goes to enablement. A one-off need is parked.

A blocker seen
in the field

What kind of
problem is it?

Missing capability
Product: roadmap candidate,
with evidence and a test plan

Missing integration
Partners and architects:
a reusable pattern

Weak customer data
Customer data owner:
fix it at the source

Process design
Customer process owner:
redesign the journey

Training gap
Enablement:
coaching and content

One-off need
Park it: not worth
productising yet
Figure 12. Triage first. Only one of the six routes ends on the product roadmap, and its real-world results feed the next customer decision.

The insight that reaches the product team should read less like “customers want feature X” and more like a testable proposal: in this customer segment, the same process blocker keeps recurring; the current workaround slows delivery and limits adoption; a shared capability could remove it; here is the customer evidence, and here is how we propose to validate it. That is a product decision input rather than a wish list, and it closes the loop. The customer need shapes the product, and the product’s real-world results change the next customer and go-to-market decision.

12/ Loomiks.ai

Where this framework lives: Loomiks.ai

A disclosure first, because this publication does not hide them: I build Loomiks.ai, a decision-engineering platform for enterprise AI. The decision chain in this piece is not a slide drawn for Silicon Tales. It is the framework that runs underneath two Loomiks.ai modules, Strategy Adviser and AI Use Case Assessment.

AI Use Case Assessment starts from a library of more than 400 referenced use cases, each carrying a large set of parameters, and gives teams an overview and a prioritisation view, so a use case has to earn its place against the same questions this article asks. Strategy Adviser applies the same chain to turn an organisation’s AI ambition into governed decisions. Neither replaces the judgement described above. The point is to make that judgement consistent and repeatable, from one engagement to the next.

The decision chain inside Loomiks.aiThe same eight-link decision chain, from business priority to repeatable go-to-market, is applied in two Loomiks.ai modules. AI Use Case Assessment draws on a library of more than 400 referenced use cases, each with a large parameter set, with overview and prioritisation views. Strategy Adviser turns an organisation's AI ambition into governed decisions.

The decision chain
priority, problem, outcome,
intervention, authority,
economics, evidence, scale

AI Use Case Assessment
400+ referenced use cases,
each with a large parameter set;
overview and prioritisation views

Strategy Adviser
from AI ambition
to governed decisions
Figure 13. The same decision chain, applied inside two Loomiks.ai modules. More at loomiks.ai.

13/ Decision brief

The strategy decision brief

If you keep one thing from this piece, keep the brief. Before any agentic customer experience investment is approved, these seven lines should be filled in, in plain language, with evidence attached.

DecisionThe question to answerEvidence that settles it
Customer needWhich need, for which customers, with which root cause?Reviewed conversations, CRM records, repeat contacts
Business outcomeWhich result must change, and which quality limits must hold?Baseline, target and agreed guardrails
InterventionPrevent, simplify, assist or automate, and why not the others?Options compared against the same criteria
Authority limitsWhat can the agent do alone, up to what limit, and who owns it?Decision rights, action limits, named owners
Economic caseCapacity, cash or contribution, and at what full cost?Scenarios with visible assumptions
EvidenceWhich result scales it, narrows it or stops it?Success and failure criteria agreed in advance
Scaling decisionWhat carries to the next customer, and what must be proven again?Reusable core versus local adaptation

A brief that cannot be filled in is not a reason to buy a better AI agent. It is a sign that the organisation has not yet decided what it is trying to fix.

14/ Verdict

The verdict

The strategist’s job is not to add AI to every interaction. It is to decide which interactions should be prevented, which simplified, which supported by AI and which kept with human judgement, and then to prove that the decision created value for the customer and can be repeated for the next one. Agentic AI has made the machine capable of acting. It has not made it capable of deciding what is worth doing, and the companies that remember the difference will spend less on AI and get far more from it.

FAQ/ Questions people ask

Questions people ask about agentic customer experience

What is agentic customer experience?

Agentic customer experience uses AI agents that do more than answer questions. They look up records, complete transactions such as refunds or account changes, and hand the conversation to a human when they reach their limits. The strategic work is deciding where that autonomy creates value, which limits apply, and how success is verified.

How do you measure whether an AI agent in customer service is working?

Measure three layers: technical operation (did the agent and its tools run correctly), customer outcome (was the need met, and did the customer have to come back) and business value (did the cost per verified resolution, quality or commercial result improve). A contact that was not transferred to a human is not proof of success, because the customer may simply have given up.

Should AI agents replace human contact centre agents?

The evidence does not support treating replacement as the goal. A study of 5,172 support agents published in The Quarterly Journal of Economics found that an AI assistant raised issues resolved per hour by 15 percent on average, with the clearest gains among less experienced agents. Klarna, which leaned hard on AI-led service, later said cost had weighed too heavily and quality had suffered, and began hiring human agents again. The better question is which working model serves each customer need.

What should an AI customer service pilot prove before it scales?

It should prove that the customer outcome, the economics and staff adoption all hold up against criteria agreed before the pilot started. Those criteria should also say in advance which results mean scale, which mean change the design, which mean narrow the scope and which mean stop.

How does Loomiks.ai use this decision framework?

The decision chain described here runs underneath two Loomiks.ai modules: Strategy Adviser, which turns an organisation’s AI ambition into governed decisions, and AI Use Case Assessment, which prioritises use cases drawn from a library of more than 400 referenced examples. More at loomiks.ai.

Sources/ Further reading

Sources and further reading

Onur Sirin writes Silicon Tales and builds Loomiks.ai, a decision-engineering platform for enterprise AI.

Advertisement