Every team with decent evaluation eventually hits the same wall: the pipeline works, low-scoring runs pour in, and now there are nine thousand of them. Nine thousand anecdotes. The eval system has successfully converted "we don't know what's wrong" into "we know 9,000 things are wrong," which is somehow worse for morale and no better for planning.
The missing operation is clustering: collapsing thousands of individual failures into a handful of named, counted, trending patterns. Anecdotes are unactionable; patterns are just engineering tickets.
Cluster the diagnosis, not the transcript
The naive approach — embed the raw conversations and cluster those — groups failures by topic, not by failure mode. All the shipping conversations clump together whether the agent failed by misreading policy, calling the wrong tool, or hallucinating a tracking number. Three unrelated bugs, one useless cluster.
The fix is to cluster one level up. When your evaluator flags a run, have it also emit a short structured diagnosis: what was expected, what the agent did instead, and the apparent cause. Embed that. Now "cited §4.2 for partially-shipped orders where §4.6 applies" clusters with its true siblings across every conversation topic, and the tool-selection bugs form their own cluster regardless of what the user was asking about. You're grouping by the shape of the mistake, which is the shape a fix has to match.
Labels humans actually trust
A cluster nobody understands is a cluster nobody fixes. For each cluster, generate a plain-language name ("Misapplies refund policy to partially-shipped orders"), a two-sentence description, three representative examples, and the count and trend. This sounds cosmetic; it's load-bearing. The moment an engineering lead can read the top of the failure report and recognize their system's actual problems, the loop stops being an ML curiosity and becomes part of how the team plans work. Bad labels — vague, overlapping, or wrong — kill trust in one meeting.
Ranking: where the backlog writes itself
With clusters in hand, priority stops being a debate. Rank by frequency × trend × blast radius: how often, growing or shrinking, and what each occurrence costs (an annoyed user? a wrong refund? a reverted production deploy?). The unit-economics math falls straight out — cluster #1 at 63 weekly occurrences and $15 each is a $49k/year problem, and suddenly the improvement backlog is ordered by money instead of by whoever complained loudest. New clusters appearing out of nowhere are your early-warning system for drift and regressions; a cluster that reappears after being fixed means your gate has a hole.
Downstream: clusters are half a fix already
The best property of a well-formed cluster is what it contains: dozens of concrete examples of one misunderstanding, often alongside correctly-handled near-misses. That's precisely the context a model needs to draft a targeted prompt revision or new few-shot example — which is why clustering isn't the end of the pipeline but the handoff point to candidate generation. A cluster is a bug report so complete it nearly writes its own patch.
If your eval dashboard is a list of scores, you've built the sensor. Clustering is where the sensor data becomes a to-do list — and in a working loop, the to-do list is where improvement stops being aspirational and starts being scheduled.