Summarization Features Users Trust

"Add a summary" sounds like the easiest AI feature you'll ever ship: one API call, one paragraph back. That's why so many summary features quietly fail. They read fluently, users skim them, and somewhere in week three a support agent promises a refund the customer never asked for because the summary blended two different requests into one. Summarization is easy to demo and hard to make trustworthy.

In this lesson you'll build ticket summaries for Deskmate, the help-desk app we use as a running example, and you'll learn the design decisions that separate a summary people rely on from one they learn to ignore: deciding what the summary is for, structuring it so omissions are visible, handling long and messy threads, and checking that it says only what the source says.

Start with the job, not the length#

The most common summarization bug isn't a model failure. It's a missing spec. "Summarize this ticket in two sentences" tells the model how long to be, but not what matters, so it does its best guess at "important": usually the first and most emotional parts of the text.

Before you write a prompt, name the reader, the moment, and the decision the summary supports. Different jobs produce genuinely different summaries of the same text:

Each of these is a different feature, even though all of them are "summarize." Pick one per surface in your UI. If you try to make one summary serve every job, you'll get the average of all of them, which serves none.