Worked Example: Evaluating a Customer-Service AI Agent Before Release
This worked example evaluates an AI agent that handles a disputed delivery. The agent must interpret the customer's account, order, courier evidence and service policy before it proposes or completes a remedy. A polite answer is not enough. The test follows the case until the authorised remedy appears in the operating system and the customer receives an accurate update.
The customer raises a disputed delivery
Assume a customer reports that a paid order did not arrive, although the courier system marks it as delivered. The service agent can read the customer's order and delivery records, retrieve the current policy, prepare a replacement or refund, and refer exceptions. It may update a low-risk contact preference, but it cannot approve a high-value remedy.
The release question is therefore precise: can the agent resolve the defined class of disputed-delivery cases without exposing another customer's data, applying the wrong policy, promising an unauthorised remedy or closing a case that remains unresolved?
Identity verification must precede protected disclosure
The customer supplies an order number and asks the agent to confirm the delivery address. Possessing an order number does not prove identity. Before revealing an address, payment detail or account history, the workflow should complete the organisation's required verification through a controlled service.
The evaluation team tests a valid customer, a person with only the order number and a customer who fails one verification step but supplies persuasive contextual details. The agent should not relax the rule because the explanation sounds credible. It may provide general assistance while withholding protected account information until the authorised verification succeeds.
The agent must reconcile conflicting operational evidence
After verification, the order system shows delivery at 14:10. The courier record includes a photograph, but the door number in the image differs from the customer's address. A customer relationship record also shows that an employee promised an investigation during an earlier contact. No single source settles the case.
The agent should identify the conflict, retain the earlier commitment and retrieve the policy for disputed delivery. It should not treat the courier's delivered status as conclusive or dismiss the photograph because the customer objects. The case requires a reasoned disposition from the combined evidence and the policy that applies to this order.
Policy retrieval must preserve version and scope
The current policy permits an immediate replacement below a stated value when delivery evidence conflicts with the verified address. An older policy in the knowledge base required supervisor review for every disputed delivery. The evaluator checks whether the agent selects the policy effective on the case date and cites the section that supports its proposed action.
The implementation team should also enforce the policy outside the model. A deterministic service can validate the order value, remedy limit, case category and required approval. The model can then interpret the evidence without gaining authority to change the approved threshold in response to a persuasive customer or an injected instruction.
A remedy recommendation is not a completed remedy
Suppose the evidence supports a replacement and the order falls below the approval limit. The agent explains the proposed remedy and asks the customer to confirm the delivery address. At this point, the replacement exists only as a proposal. The agent must not describe it as issued.
After confirmation, the write tool creates a replacement order and returns its identifier and state. The service case should record the evidence, policy version, remedy, approval basis and transaction identifier. Only then may the agent tell the customer that the replacement has been created.
A partial failure tests whether the case remains open
In the critical run, the replacement tool creates the new order, but the service-case update fails. The agent receives the replacement identifier yet cannot record completion in the customer service system. If it closes the conversation, a later employee may see an open complaint with no remedy, while the customer may receive a second replacement.
The workflow should keep the case in a reconciliation state, preserve the replacement identifier and retry only the failed case update. It should notify the customer that the replacement exists while explaining that the service record is still being reconciled if that distinction affects the next contact. The system should not repeat the remedy to make the records look consistent.
The next contact provides an essential follow-through test
The customer contacts the company again the following day and asks when the replacement will arrive. The new interaction should retrieve the same service case, the replacement order and any outstanding reconciliation task. A fresh apology that ignores the completed remedy would reveal that the workflow handled a conversation rather than the customer's continuing problem.
The test should also change the replacement status after the first contact. If fulfilment rejects the replacement because stock becomes unavailable, the case must reopen and route to the next authorised remedy. Resolution depends on the customer's actual outcome, not the agent's earlier intention.
Evaluation evidence must cover language and operations
Communication quality still matters. The response should be clear, specific, respectful and proportionate to what the evidence supports. However, a language score cannot establish identity verification, current policy use, authorised action or completed fulfilment. Those claims require operational records.
The evaluator should therefore join the conversation trace with verification results, source versions, policy references, tool calls, approvals, final account state and subsequent case events. Human reviewers can assess communication and ambiguous policy interpretation, while deterministic checks can confirm identifiers, permissions and state transitions.
Release rules should reflect customer and business harm
Cross-customer disclosure, an unauthorised refund, a repeated replacement or a false claim of completion should block release for autonomous resolution. A response that is accurate but unnecessarily verbose may require improvement without carrying the same consequence. The evaluation should report those failures separately.
The team should repeat variable cases and retain held-out combinations, such as failed verification with conflicting delivery evidence or a valid remedy followed by fulfilment rejection. Management can then approve a bounded role, such as account information after verification and supervised remedies below a limit, while keeping higher-authority exceptions with trained employees.
What Marketways delivers from this evaluation
Marketways maps the client's service case from first contact to operational resolution. We identify the records, policy decisions, permissions, remedy limits, write actions and later events that determine whether the case is truly resolved. We then build controlled cases that alter identity evidence, policy version, tool response and fulfilment outcome.
The engagement gives management a release boundary, failure evidence, required control changes and regression cases for future versions. The decision concerns the service obligations the agent can complete reliably. It does not rest on whether the agent sounds helpful in an isolated conversation.