How to find failure patterns in AI conversations
Group related interactions, inspect the underlying traces, and turn confirmed patterns into measurable eval cases. A cluster label alone does not establish a failure.
Production agents can fail without throwing an exception. A conversation may end with an unresolved request, a repeated clarification, or a confident confirmation unsupported by the tool result. An uptime dashboard will not necessarily reveal those patterns.
Finding them requires reviewing behavior across interactions while retaining access to the individual traces. Grouping helps narrow the search; human review and outcome evidence establish what actually went wrong.
Choose the unit of analysis
A message, a trace, a conversation, and a user task are different units. If every turn creates a new trace, a failure that emerges over six turns can disappear when each trace is classified independently.
Start with a conversation or task identifier, then preserve its constituent traces. Record the time window, application release, and available outcome signals. Explicitly label incomplete interactions: a recording that stops early is not proof that the user abandoned the task.
Separate intent, behavior, and outcome
| Dimension | Example label | What it establishes |
|---|---|---|
| Intent | Change a delivery address | What the user is trying to do |
| Behavior | Repeated order lookup | What the agent did |
| Outcome | Address unchanged | Whether an observable goal was reached |
| Sentiment | Frustrated | How the user expressed themselves |
A frustrated user may receive a correct answer to an unwelcome question. A polite user may leave after a failed action. Treat sentiment as a review signal rather than a substitute for task success.
Similarly, repeated tool calls can be legitimate polling or a failure to make progress. Inspect the arguments, responses, and state changes before labeling the pattern a loop.
Use clustering to find candidates for review
Summarize interactions consistently, then group similar intents or behaviors. Review a sample from each candidate cluster, including examples near its boundary and examples that appear successful. A cluster named “refund problems” may contain rejected requests, tool outages, policy misunderstandings, and successful refunds with unhappy users.
Braintrust documents Topics as a workflow that summarizes traces through facets such as task, sentiment, and issues, clusters summaries, and attaches classifications to logs. It also supports grouping related traces into conversations. Braintrust Topics documentation.
That can make investigation more tractable. It does not make every generated category a verified root cause. Preserve the source interactions so reviewers can challenge the label and distinguish different mechanisms inside the same group.
Count outcomes with the right denominator
Consider an illustrative week with 1,000 address-change conversations. Review identifies 40 unresolved requests: 25 involve a tool outage, 10 lack a required order reference, and 5 contain an incorrect confirmation after an update failure.
The observed unresolved rate is 40 out of 1,000 only if those outcomes were established across the full set. If reviewers inspected 100 conversations selected because they looked suspicious, 40 failures among them cannot be reported as a 4% production failure rate.
Record sampling rules, review coverage, missing traces, and unclassified cases. To compare releases, use comparable intent groups and time windows. Changes in user traffic or classification labels can move a dashboard without any change in application quality.
Turn a confirmed pattern into an intervention
Each confirmed pattern should have a concrete next step. A service outage may need retry handling. An ambiguous request may need clarification. An incorrect confirmation needs an assertion that the final response agrees with the action result.
For the address-change example, reconstruct the failed update in a fixture and score whether the agent reports the failure accurately. Keep successful updates and ambiguous requests in the same suite so the fix does not teach the agent to refuse every action.
Use the trace-to-dataset workflow to preserve those cases. For behaviors spanning multiple operations, apply tool-call evaluation to the full trajectory.
Check whether the intervention worked
Rerun the relevant cases before release. After release, review the same behavior in comparable production traffic and retain random samples to look for new failures. Keep runtime limits separate from retrospective detection: discovering a looping pattern tomorrow does not stop an agent looping today.
The useful output of conversation analysis is a set of supported findings, reproducible cases, and measurable changes. Topic names help organize that work; the underlying interactions remain the evidence.
Continue with the evals implementation guide for the full workflow.