/case-studies

Real Problems, Solved End to End

Each of these starts with raw traces and ends with a shipped change. Here's how the loop plays out in practice.

Case 01 · Marketing platform · ad-copy generation agent

Figuring out which evals actually matter.

A marketing platform ran a dozen evals against its ad-copy agent but had no idea which ones tracked real quality. TwoTail found the two that predicted whether a human editor approved the copy, and showed the rest were noise.

12 → 2evals that actually predict editor approval
1

Define what "good" actually means

The team rebuilt their evals as scoring rubrics: the quality dimensions they cared about (brand voice, factual accuracy, length), each written down, plus the real business outcome, editor-approved.

rubrics · what good looks like, written down
brand_voiceon-brand tone & register
factual_accuracyclaims supported by the brief
lengthwithin the channel's limit
editor_approvedoutcome · shipped by a human editor
2

Label a sample, name the failures

An annotation queue picked the traces worth the team's time. As they labelled, the failures got names and a taxonomy: off-brand tone, unsupported claims, and bloated copy, sized by how often each showed up.

failure taxonomy · 4,182 graded traces
Off-brand tone
Unsupported claims
Bloated copy
3

Correlate every eval against the outcome

With judges calibrated on those labels, every trace carried scores worth trusting. One view put each eval against editor approval: which ones move with the outcome, and which just add noise to the scorecard.

eval correlation vs. editor-approved
brand_voice0.71
factual_accuracy0.63
keyword_coverage0.24
output_length0.04
4

Keep the signal, drop the noise

Two evals predicted the outcome; the rest came off the scorecard. The survivors became the live suite: always running, and worth trusting because they tie to the metric the business already cares about.

eval scorecard
brand_voice
factual_accuracy
keyword_coverage
output_length
+ 8 more dropped
outcome

From 12 evals down to the 2 that predict editor approval. The live suite now scores what actually correlates with quality, not metrics that were quietly measuring nothing.

Case 02 · Customer-support chat agent

Segment intent, measure success, find the root cause.

A support agent's overall success rate looked healthy. Segmenting by what users actually asked for revealed one intent dragging the average down, and a retrieval gap underneath it.

38% vs 82%resolution gap on one intent, found in an afternoon
1

Segment conversations by intent

Segmentation grouped raw conversations into the intents users actually arrived with: FAQ, how-to, billing, refund, and ambiguous, no manual tagging required.

conversation share by intent · 9,400 chats
faq31%
how-to24%
billing18%
refund14%
ambiguous13%
2

Measure success rate per intent

A calibrated resolution judge graded every conversation, so the rates were worth reading. The aggregate looked healthy. Broken out by intent, one segment stood far below the rest.

resolution rate by intent
88%
faq
84%
how-to
79%
billing
38%
refund
72%
other
3

Put a name on the failure

Pulling the refund failures into the taxonomy and comparing them to the wins exposed the structural difference: failing runs retrieved irrelevant documents, the winners didn't.

low retrieval precision (< 0.4)
68%
of refund failures
12%
of refund successes
4

Hand back a change worth making

The diagnosis came with a direction: add query rewriting for refund-shaped questions and a dedicated refund-lookup skill. And because refund resolution is now an eval, the same suite that found the problem measures the change.

changeAdd query rewriting for refund-shaped questions and a dedicated refund-lookup skill. The refund eval stays on to measure the change.
outcome

The one intent dragging the average down, and the retrieval gap causing it, found in an afternoon, not a quarter of dashboard-staring.

Case 03 · Research-assistant startup · multi-step web-research agent

Cutting cost without losing quality.

A research-assistant startup's agent calls an LLM at every step to choose its next source. They wanted to cut spend on that per-step call without dropping task completion. Calibrated evals meant they could change the model and trust what the needle said.

−42%cost on the per-step call, completion within 3 points
1

Find the cost driver

Segmenting spend by step and model pointed straight at the culprit: the per-step source-selection LLM call, run once for every hop, dominated the bill.

spend by span · last 7 days
source-selection71%
synthesis19%
other10%
2

Calibrate the judge that guards quality

Task completion was already an eval. Annotating a sample calibrated the judge against their own reading of the traces, and turned the raw score into a corrected baseline with an interval.

completion judge · calibrated on 150 labels
judge vs you94% agreement
raw judge rate65.8%
corrected baseline62.1% (58.4 to 65.9)
3

Swap in the cheaper model

With the measure trusted, the source-selection call moved to a lite model. The calibrated judge scored both sides of the change, putting cost next to completion.

source-selection variants · scored by the calibrated judge
variantcompletioncost / run
baseline · flagship62%$0.024
lite model59%$0.014
4

Check it held everywhere

Segmenting the results confirmed the saving held on routine queries as well as the hard outliers, so it was real rather than a sampling artifact.

routine-query segment · completion
61%
lite model completion
63%
baseline completion
outcome

−42% cost on the source-selection step, completion within 3 points of baseline, shipped with the receipts to back the call.

What would TwoTail find in your traces?

Setup in 10 minutes. First insights within a week.