Part 1
What is an “eval”?
How teams find out whether an AI system is actually any good — before customers do.
The word is short for evaluation, and in AI teams it has become a noun: “we wrote an eval”, “the eval failed”, “what does the eval say?”. An AI model does not come with a specification sheet. Nobody can read its parts list and tell you whether it will handle an angry customer well. The only way to know what an AI system does is to try it — many times, in many situations, and score the results.
That is what an eval is. Not a one-off demo, but a structured set of test scenarios that the system runs through again and again, with each run scored against criteria someone wrote down. Less like checking an engine’s specifications, more like a driving test — or a mystery shopper visiting the same shop a hundred times and filing a report each visit.
In one sentence: an eval is a repeatable set of test scenarios, plus the scoring criteria, that measures how well an AI system performs — so quality becomes something you can see and improve, not something you hope for.
Part 2
Why agents make evals essential
Classic software is predictable: the same input gives the same output, so you can test it once and trust the result. AI agents are not like that. Ask the same question twice and you may get two different answers — both reasonable, or one of them wrong. And an agent working towards a goal takes many steps in a row, so one small misjudgement early on can send the whole journey somewhere unexpected.
This is why a convincing demo means very little. A demo proves the agent can succeed once; an eval measures how often it succeeds across hundreds of realistic situations — and what happens in the ones where it fails. Teams that take agents seriously treat their evals the way pilots treat flight checklists: the boring discipline that makes the impressive thing safe.
What a good eval scores
Outcome
Did the customer’s problem actually get solved — not just answered?
Tone & clarity
Was the language right for the moment — clear, honest, matching the brand?
Safety
Did the agent stay inside its guardrails — no invented facts, no forbidden actions?
Handoffs
When it reached its limits, did it hand over to a person — at the right moment, gracefully?
Part 3
The quality bar is a design decision
Here is the part that matters most for designers: whoever writes the eval defines what “good” means. The agent will be tuned, iterated and shipped against those criteria — and nothing else. What the eval measures improves; what it ignores quietly degrades.
Left to default, eval criteria are technical: task completed, no errors, fast response. All necessary — none sufficient. An agent can complete every task and still leave customers feeling processed rather than helped. Whether the eval also scores tone, effort, and the grace of a handoff decides which of those two agents your customers will meet.
Part 4
What to remember
-
01
An eval is a repeatable test: many scenarios, scored runs. A demo proves it can work; an eval measures how often it does.
-
02
Agents give different answers on different runs, so quality is a distribution — something you measure, not something you assume.
-
03
Whoever writes the eval defines “good”. What the eval measures improves; what it ignores degrades.
-
04
Eval results are experience data. Read them the way you read research findings — they tell you where the journey breaks.
For business & service designers
Writing the quality bar
is service design
Defining what a good experience looks like is already our job. We do it with research, journey maps, service blueprints and success metrics — long before anything is built. An eval is that same definition, made executable: the standard of “good” written down so precisely that a machine can be tested against it every day.
Which means the eval is where our understanding of the customer either enters the system — or doesn’t. Look at what goes into one, and you find our craft everywhere.
- Test scenarios → journey research & personas
- Realistic scenarios don’t come from a developer’s imagination. They come from research: the situations, emotions and edge cases we already collect in journey maps and customer archetypes.
- Success criteria → journey outcomes
- “Task completed” is a system outcome. “Customer left with their problem solved and their confidence intact” is a journey outcome. We know the difference — the eval should too.
- Failure tolerance → moments of truth
- Not all errors weigh the same. A clumsy phrasing is survivable; a wrong answer about a bill is not. Deciding which failures are acceptable, and which never are, is moment-of-truth thinking.
- Eval results → experience insight
- A scorecard over hundreds of runs is a continuous usability study of your service. It deserves the same attention we give NPS drops and research findings — and it arrives every single day.
What will we do in the future?
Again: much of what we already do, applied to a new material. Four places where eval work belongs on a designer’s desk:
-
Turn journeys into scenario suites
Every journey map we own contains the test cases an agent needs: the happy path, the frustrated retry, the vulnerable customer, the moment people give up. We will write those into the eval, so the agent is tested against reality.
-
Define pass and fail with the squad
Sit with the engineers when scoring criteria are written. Push “resolved for the customer” into the definition of success, and name the failures that are never acceptable.
-
Read eval dashboards as experience data
Treat scores across scenarios the way we treat research: find where the journey breaks, for whom, and how it feels — then feed that back into the harness and the service around it.
-
Keep the bar alive
Journeys evolve, propositions change, new edge cases appear. The eval is a living CX standard, not a launch checklist — someone has to own its evolution, and that someone should understand customers.
The question to take with you
If the eval defines what good looks like —
who defines the eval?