Evaluating an AI agent for production

Three numbers that are not the same number

This is the most consequential confusion in the field, and it is everywhere. Deflection rate, containment rate, resolution rate, and first-contact resolution are not interchangeable terms — and the gap between them is where disappointing AI programs live.

For orientation, published 2026 benchmarks put median tier-1 deflection around 41% across enterprise CX programs, with the top quartile near 59%; a well-configured agent is commonly reported to handle roughly 40–65% of ecommerce support tickets without a human. Treat those as context for what is plausible, not as targets. A reported number that is far above the range usually means deflection is being measured where resolution should be.

Step 1: define "working" before you measure anything

Most evaluations fail here, before any testing happens. "Is it ready?" is unanswerable until somebody writes down what ready means.

Agree, per intent, in advance:

• Which intents are in scope. Not "customer service" — the specific things the agent is expected to handle.
• What counts as resolved, for each one. This must be observable. "The customer got their balance" is observable. "The customer was satisfied" is not, unless you are measuring it.
• What the escalation contract is. When must the agent hand off, and what must it pass across? An escalation that dumps the customer at the start of a queue with no context is a failure, even though it looks like a successful handoff.
• What is unacceptable at any rate. Some failures are not tradeable against a good average — stating a policy that does not exist, giving incorrect regulated information, failing to escalate a vulnerable customer, or a safety-relevant error. These are pass/fail gates, not percentages.

Step 2: build an evaluation set from real traffic

The set determines the result. Build it from your own transcripts and call recordings, not from the vendor's examples.

• Sample the long tail, deliberately. If you sample proportionally, you get the easy top intents and almost none of the cases that break things. Stratify so the tail is genuinely represented.
• Keep the mess. Interruptions, background noise, accents, code-switching, callers who answer a different question from the one asked, callers who change their mind mid-sentence. This is what production sounds like.
• Include multi-intent turns. Real customers ask two things at once.
• Label independently. Ground-truth labels should come from someone other than the team that built the agent. Have a second annotator on a sample and check agreement — if humans cannot agree what "resolved" means here, no measurement of it will mean anything.
• Hold out a set. Keep a portion the build team never sees. Without it you are measuring how well the system fits the examples it was tuned on.

Step 3: measure the things separately

Step 4: test the conditions demos avoid

This is where an evaluation earns its cost.

• Degraded audio. Mobile callers, hands-free, wind, background conversation, a bad connection. Not a headset in a quiet room.
• Accents and dialects representative of your actual customer base, and measured separately rather than averaged into a single score that hides which groups are served worse.
• Interruption and barge-in. Customers talk over prompts. Turn-taking behavior is a common failure point.
• DTMF fallback. When speech fails repeatedly, is there a keypad path out?
• The storm case. Outage lines, incident days, product recalls — traffic arrives all at once, from stressed callers. Test concurrency explicitly, and test what happens to escalation when the human queue is already saturated. That combination is where systems fail worst and it is almost never tested.
• Adversarial input. Prompt injection, attempts to extract system instructions, attempts to make the agent commit the business to something it should not. For LLM-driven agents this is a security test, not a quality test.
• Regression. Every model or prompt change can move behavior anywhere. The evaluation set must be re-runnable on every release, automatically.

Step 5: write go-live criteria that can fail

A criterion that cannot produce a "no" is not a criterion. A usable set looks like:

• Per-intent thresholds, not an overall average. An agent at 85% overall can be at 40% on your highest-value intent.
• Hard gates for the unacceptable-failure categories, at zero tolerance.
• Escalation correctness as its own threshold.
• Latency at the 95th percentile, not the mean.
• A defined scope of launch. Frequently the honest answer is "launch for these three intents, hold the other seven." That is a good outcome, not a failure.
• A rollback trigger — what production signal sends traffic back to humans, and who is authorized to pull it.

Step 6: keep measuring after launch

Evaluation is not a gate you pass once. Model updates, prompt changes, knowledge-base edits, and shifting customer behavior all move quality, usually without anyone noticing.

• Re-run the evaluation set on every change, automatically.
• Sample production conversations for human review continuously — a small percentage, forever.
• Track containment and true resolution as separate lines on the same chart. When they diverge, that is your signal.
• Watch repeat-contact rate. A rising repeat rate alongside rising containment is the clearest evidence that the system is deflecting rather than resolving.

The uncomfortable finding

Sometimes the honest answer is that the use case is not ready — that the underlying process is too inconsistent to automate, or that the knowledge the agent needs does not exist in a usable form anywhere in the organization.

That finding is worth more than a launch. An AI agent placed in front of customers on top of a broken process does not hide the process; it advertises it, at scale, in transcripts.

Related reading

• CCaaS migration — the platform this usually runs on.
• Voice quality — audio quality caps ASR accuracy, so measure it first.
• PCI DSS in the contact center — what happens when AI tooling starts reading transcripts.