A Correct Answer Doesn't Mean the Job Is Done: Why Businesses Need End-to-End AI Agent Evaluation

“Your refund has been processed.”

Read that in a chat window, and you might give the AI a good score. The reply is polite and tells the customer what they wanted to hear.

Now imagine the payment system never received the instruction. Or it received the request but hasn't completed the refund. The customer leaves the conversation expecting their money back. The company closes the ticket.

The reply looks fine. The work is still unfinished.

This is the question that follows when a business moves from dashboards that flag problems to AI agents that can act on them: once an agent starts working with live systems, how do we know it's doing a good job?

I'd want that question on the table before development begins. Without an agreed definition of “done,” we could spend months changing models and improving prompts while remaining unsure whether the business is actually better off.

An AI agent should be evaluated as part of a business process, with answer accuracy as one measure of how well that process works.

A correct reply and a completed task are different things

Take the refund example. A customer reports a missing item. The agent needs to identify the right order, check the affected item, find the policy that applies, and act within its permissions.

It may need approval from an employee. After requesting the refund, it still needs to check the payment system's status before telling the customer what has happened.

That's quite a lot of work hidden inside the word “refund.”

An agent might retrieve accurate information but select the wrong order. It might understand the policy but submit the wrong amount. Or it might get everything right until the payment system stops responding.

Some of those failures will go unnoticed if we score only the message the customer sees. (A chat window doesn't tell us whether any money has actually moved.)

End-to-end evaluation follows a case from the initial request through to the required business outcome. For a refund, the endpoint might be confirmed completion in the payment system. The agent finishing its reply is simply one event along the way.

The wording matters here, too. “Refund requested,” “refund processed,” and “funds received” may describe different stages. The agent should communicate the stage the available evidence supports.

Small error rates become expensive at scale

Zepto, an Indian quick-commerce platform, offers a useful sense of the scale involved.

A Databricks case study published on September 9, 2026 reports that Zepto's multi-agent customer support system processes more than 100,000 tickets a day, with agents managing over 80% under human oversight. Reported results include a 65% reduction in support costs, a 20% improvement in customer satisfaction (CSAT), development cycles described as three times faster, and time to resolution described as four times faster. Read the Databricks / Zepto case study.

These are results reported in a technology vendor's case study, rather than an independent assessment. They shouldn't become targets that every other business is expected to match. The reported 20% CSAT improvement also shouldn't be restated as a 20-percentage-point increase.

For a simple illustration, a hypothetical 1% error rate across 100,000 daily cases would mean 1,000 affected cases a day. (That's arithmetic, not Zepto's reported error rate.)

The type of error matters as much as the count. A slightly delayed reply and a duplicate refund carry very different costs.

The question I'd bring back to the business is: which failures can we tolerate, at what frequency, and how quickly will we know when they happen?

Seeing only the final answer can lead us to fix the wrong thing

Suppose a customer hasn't received a refund. The team reviews the conversation, spots the incorrect status, and adds an instruction to the prompt: “Do not say the refund is complete unless it has succeeded.”

That sounds reasonable. But what if the integration returned “request accepted,” and the application treated it as “completed”? Another sentence in the prompt may do little to address the cause.

The team needs a trace: a record of what happened during that case. It should show which prompt version was used, what information was retrieved, which tools were called with which inputs, and what the connected systems returned. Timing and handoffs to employees belong in that record as well.

A “decision path” here means evidence the application can record, such as a condition being met, a rule being applied, or an approval being granted. It doesn't mean we can inspect every internal step of the model's reasoning.

For actions that change records or create transactions, the case should also be linked to the resulting record in the receiving system. That lets the team check what an instruction actually caused.

Traces need sensible limits, too. Record what's needed to investigate and evaluate the work, and restrict access where customer or business information is involved. Better visibility doesn't require copying everything into a log.

Evaluation-first means agreeing on the criteria before changing the system

Zepto's case study describes development and production loops connected by a quality gate, with failures from live operations feeding back into the test dataset. That gives the team evidence for comparing agent versions. See Zepto's evaluation-first approach.

For a business getting started, I'd turn that principle into a practical working routine.

Before development, the process owner and technical team should agree on the evidence required to call a case successful. They should also identify failures that must block release. Test cases need to cover ordinary work as well as awkward situations: incomplete information, an unavailable payment system, or a request beyond the agent's authority.

When a prompt, model, or tool changes, compare the new version with the current one under the same conditions. Check whether the intended improvement happened and whether something else got worse. Keep a separate evaluation set that wasn't used to tune the system, so the assessment doesn't simply reward familiarity with examples it has already seen.

Before release, apply the agreed quality gate. Some criteria will concern speed. Others will concern permission to act. A strong average score should never hide a failure to respect transaction limits.

Once the agent is live, someone needs to own the follow-up. Failed cases should become tests for future versions, and the team should know when to pause a function or return to an earlier version.

This is where “the AI project is finished” becomes a difficult claim to make. Business processes keep changing. So do the conditions the agent has to work within.

Agent KPIs should answer business questions

The following is a suggested framework to adapt to your own process. It isn't a claim that Zepto uses this exact set of KPIs.

Business outcome

Question to answer: Are customers and the business better off?

Example measures: Cost per successfully resolved case; repeat contact rate within a defined period; customer satisfaction

Task success

Question to answer: Has the work met the agreed definition of done?

Example measures: Percentage of cases with confirmed completion in the receiving system, required conditions met, and no subsequent correction within a defined review period

Accuracy / groundedness

Question to answer: Is the information correct and supported by evidence?

Example measures: Accuracy of amounts and statuses; use of the correct source data and policy version

Tool failure / retry

Question to answer: Where do interactions with other systems break down?

Example measures: Failed tool calls; retry counts; duplicate transactions; cases requiring manual repair

Cost / latency

Question to answer: Are the resources and time spent justified by the result?

Example measures: Total cost per successful case; time to completion; P95 completion time

Human intervention / acceptance

Question to answer: Why do people need to step in, and how well can they take over?

Example measures: Handoffs by reason; percentage of agent proposals accepted without edits; time spent reviewing or correcting work

P95 is the completion time at or below which 95% of measured cases fall. It helps expose slower cases that an average can hide. Track unresolved cases separately, too; they can disappear from a completion-time metric if it includes only finished work.

Total cost should include relevant tool charges and the time employees spend checking or correcting work, wherever that can be measured. Token costs alone won't tell the full story.

Every metric also needs a clear denominator. Does task success cover all cases assigned to the agent, or only those selected for automatic handling? Teams using different definitions can produce figures that look comparable but aren't.

One metric I'd be particularly careful with is tickets closed. Reward that number alone, and you may end up with more closed tickets alongside more customers returning the next day.

(A closed ticket doesn't necessarily mean a solved problem.)

A well-timed handoff can be a successful outcome

Human-in-the-loop needs a more specific meaning than “someone is keeping an eye on it.”

In the refund example, an agent might be allowed to check the details and prepare a transaction, but need approval above a set amount. Conflicting order information should cause it to pause. If the payment system doesn't confirm the outcome, it should report only what is known and hand the case to the responsible person.

Those handoffs are the intended behavior. They should be distinguished from cases where an employee has to repair a mistake the agent made.

A very low handoff rate doesn't automatically indicate a capable system, either. It could mean the agent is carrying on with cases it should have escalated.

We need to ask both whether it escalates unnecessarily and whether it misses situations that require human attention.

When a handoff happens, the employee should receive the evidence and a record of what has already been attempted. The customer shouldn't have to start the whole story again.

An agent dashboard needs to show where work is stuck

IT monitoring still matters. We need to know whether services are available and connections are failing. An agent dashboard should add a view of the business work moving through those services.

For refunds, that means distinguishing cases awaiting approval from requests awaiting confirmation. It should show which cases have exceeded the agreed time limit, as well as customers who have contacted support again.

Executives may start with cost per successful case and customer outcomes. Operations managers need the queue of work requiring attention. Technical teams need access to the traces that help explain a failure.

Those views should lead back to the same case. Otherwise, each department arrives at the meeting with its own numbers, while nobody can explain where a particular customer's refund is stuck.

And an alert needs a next step: who will respond, what should they do, and by when?

That's where the connection from dashboard to action becomes real.

Start with one use case and a shared definition of success

You don't need several agents or a large evaluation platform to begin. Choose one task with a clear process owner and an outcome you can track.

For the refund example, the starting agreement could look like this:

• Success: The correct amount is refunded against the correct order, all required approvals are in place, and completion is confirmed by the payment system.

• Failure: The agent claims success without evidence, creates an incorrect or duplicate transaction, or leaves a case overdue without an assigned owner.

• Human involvement: The request exceeds the agent's authority, information conflicts, or the transaction outcome cannot be confirmed.

• Measurement: Track successful completion, cost and time per case, subsequent corrections, and repeat customer contact.

Capture a baseline from the current process first. Then run a limited trial using comparable case types and conditions. If the AI receives all the easy cases while employees handle the difficult ones, comparing their averages directly could produce a misleading conclusion.

Expand once there is evidence that the process works better and the team can handle its failures.

To me, this is where AI becomes part of day-to-day operations: there is a person accountable for the work, an agreed way to judge it, and continuing care after launch.

Before the next meeting about which model to use, ask the process owner one question:

“When the agent says the job is done, where do we look for the proof?”

If there isn't an answer yet, that seems like a good place to start.

Source and scope: This article draws on the Databricks / Zepto case study. The refund scenarios are hypothetical, and the KPI framework is a proposed approach, rather than a description of Zepto's implementation. Reported case-study results do not guarantee comparable outcomes for other organizations.

Apply This to Your Organization

Piloting an AI agent? Agree on a definition of success, an evaluation set, and clear handoffs before expanding.

Data Story serves organizations across Thailand through Corporate → BI → AI.

Explore Services · Discuss Your Business Question

By Data Story · Approx. 10 min read · Service links updated 1 October 2026