A summary email is a short account of a longer exchange, so somebody knows what it holds without reading all of it. The phrase covers two jobs that point opposite ways. There’s the recap you send after a meeting. And there’s the summary written for you, about a thread you haven’t opened yet.
- The two jobs are one thing aimed in different directions. What makes a recap worth sending is what makes a thread summary worth trusting.
- Your inbox list shows you a sender, a subject, and the opening words of the newest message. All three describe the packaging. What the thread holds stays behind them.
- Four things decide whether you can act on a summary: what it’s about, what’s being asked, who’s asking, and where it’s gotten to.
- A summary is somebody’s judgment. Two people reading the same document pick the same sentences less than a third of the time. That’s why the test is whether the thread stays one click behind it, rather than whether the summary is correct.
What is a summary email?
Two different things go by the name. Both are real.
The first is the one you write. A meeting ends. Five people leave with four versions of what was agreed. Somebody types out what happened and sends it round. That’s the summary email most people search for: a recap, a note of a call, a weekly update to a client. It’s written for somebody else’s inbox. Its job is to turn a thread into something a half-listening reader can still act on.
The second is the one you read. A thread sits in your list, eleven messages long, and you’ve never opened it. Something has already told you what it’s about and what it wants from you. That’s the summary email that changes a working morning. Until recently nobody could offer it, because writing one for every thread in a full inbox costs more work than reading the inbox.
The two are the same thing facing opposite ways. Somebody read a thread you didn’t, and hands you a short version so you can decide what to do. The only difference is who did the reading. So the standard holds in both directions. The recap is the easier place to see it, because you’ve written one and you know exactly when it failed.
What goes into a summary email you send
Think about the recap you’d actually want to receive.
A good recap carries four things, and roughly always the same four: what was decided, who’s doing what, by when, and what was left open. The fifth is a pointer, so anyone who wants the detail knows where the detail lives. Minutes are a different object. A transcript of who said what in which order records a meeting rather than accounting for it, and nobody reads it.
The open items are the part people leave out, and they’re the part that causes the follow-up email. A recap lists three decisions. It quietly omits the two questions nobody answered. It reads as complete, so everyone files it. Three weeks later the unanswered question turns out to be the expensive one, and nothing on record says it was ever raised. What was left unsettled belongs in the account. It’s part of the meeting, and writing it down says nothing bad about how the meeting went.
The test is worth stating plainly, because the rest of this guide runs on it. A summary works when somebody who wasn’t there can act from it without asking you a question. That’s the whole bar. Elegance, brevity and coverage all sit beside it. If your reader replies to ask who’s sending the schedule, the summary failed at the one job it had.
Send it the same day. Use your reader’s words rather than your profession’s. Keep it to something that fits on a phone screen. That’s the whole craft of it.
Now turn it round. Those four things, and that test, are exactly what you want from a thread you didn’t write and haven’t read. You’d expect a colleague to hand you the decisions, the owners, the dates and the open questions. Expect the same from anything that offers to summarize your inbox. Most things that offer fall short.
Why a preview is not a summary
Open any mail app and look at what one row in the list gives you. A name. A subject. A time. Then a fragment of text, usually the first few words of the most recent message. Four pieces of evidence. You decide whether to open on the strength of them, a hundred or so times a day.
Each one carries a little, and each stops in its own place.
The sender tells you who’s speaking. It’s genuinely useful, and it’s why a list of names is the first thing anybody sets up. Your best client emails you about a signature, about a new company, and about their vacation. The name reads the same on all three.
The subject was written once, at the start, by whoever began the thread. It described a message that no longer exists in that form. By reply nine the thread has moved on and the subject has stayed put, because nobody edits a subject line mid-thread. Anyone who’s answered “Re: Re: Fwd: March” knows the subject works as a thread identifier.
There’s a measurement of how little a subject line carries, and it arrives from an unexpected direction. In This Email Could Save Your Life, presented at the 2019 meeting of the Association for Computational Linguistics, Rui Zhang and Joel Tetreault built the first corpus for teaching a machine to write subject lines, 18,302 emails out of the Enron archive. The interesting part for a reader is what they found about the task itself. Subject line writing “favor[s] extremely abstractive summary”, which sets it apart from writing a news headline. A headline is largely made of the article’s own words. A subject line is largely made of new ones. So the subject is a poor door into the message. Most of the message was never in it.
The snippet is the opening words of the newest message, which is the least informative message in the thread. Threads end in acknowledgment. “Thanks, that works.” “Will do.” “Adding Priya.” Add a signature block or a mobile footer and your preview is a phone number. The one place the software could tell you something, it spends on the sentence that carried the least.
The time tells you when. It’s the axis the list is already sorted on, and the axis with the least to do with whether you should open the thing.
So the row does one job, and does it well. It gives you four facts about a message’s packaging. A preview is a fragment of one message. A summary is an account of a thread. That’s a difference in kind, and more preview characters leave it exactly where it is.
What a summary has to carry
There’s a decent public record of what people ask for when they commission summaries of email specifically, rather than of documents.
In EmailSum, presented at the 2021 meeting of the Association for Computational Linguistics, Shiyue Zhang, Asli Celikyilmaz, Jianfeng Gao and Mohit Bansal built a corpus of 2,549 email threads out of a real corporate archive. Each thread runs three to ten messages. Every one of them was summarized by hand twice: once short, under thirty words, and once long, under a hundred. The short instruction asked for “a concise and abstractive description of what the thread is mainly talking about”. The long one asked for “a narrative of what happens”. It had to read as a coherent account rather than a message-by-message list, stay on “the major concerns, decisions, and consensus”, and use the annotator’s own words rather than lines lifted out of the mail.
Their averages are the useful part. A thread in that corpus runs 233.2 words across an average of 4.5 messages. The short summary of it runs 27.1 words. About one word in nine survives. Eight in nine get discarded by somebody other than you, on a judgment you never made and can’t see. That’s the real trade. It’s why the surviving eight percent has to be the right eight percent, and not merely a fluent one.
Four things have to be in there.
- What it’s about, in a phrase, and in terms that mean something to your business rather than the sender’s own subject line. “Deadline change on the Henderson S-corp election” tells you more than “March”.
- What’s being asked of you, if anything. This is the requirement that gets missed most, and the EmailSum authors measured the failure precisely. The models they tested tended to “overly focus on details” and lose the sender’s high-level intention. A sender might be starting a discussion. They might be broadcasting a decision. They might be asking for something. A summary can list four accurate facts, leave out that somebody needs an answer by Thursday, and still read as complete. That makes it worse than no summary.
- Who. The second frequent failure in the same study was misattribution, summaries putting information in the wrong person’s mouth. The authors classify that as a kind of unfaithfulness rather than a stylistic slip. In a six-person thread, “they want it by Friday” leaves you where you started. The client wanting it, the junior promising it and the supplier refusing it are three different situations, and one sentence covers all three.
- Where it’s gotten to. Decided, waiting on someone, blocked, or gone quiet. That’s the state of the thread rather than its content. It’s most of what you actually need when the thread has been running for two weeks and you last looked on Tuesday.
And one thing that isn’t content at all: the thread itself, one click behind the summary. That’s the subject of the next section, because it sits there for a bigger reason than convenience.
Whose summary is it?
Here’s the awkward fact underneath all of this. Every summary of a thread is the summary somebody wrote. People writing about the same thing write different ones, and there’s no correct version sitting behind them.
The clearest recent measurement of that arrives from an odd angle. Language Models Agree With Each Other, Not With Readers, a preprint posted on July 31, 2026, by Kazuki Nakayashiki and Keisuke Watanabe, was written to test whether AI models are converging on a single voice. Commissioning judgments for a study makes the human side an artifact of the instructions given, as they argue. So they used a reference nobody built for the purpose: 2,523 sets of highlights that real readers had made across 120 web documents, on a platform where other people’s marks stay hidden by default. People marking what mattered to them, for their own reasons, with no task and no audience.
On a median document of 70 sentences, each party named 14. Two readers shared 4.1 of them. Two models shared 8.7.
Take the readers’ number seriously before the models’. Two people read the same piece, and both marked what mattered. They overlapped on under a third of their choices, and both of them were paying close attention. What matters in a document depends on who’s reading it and what they have to do next, and those two things were different. The paper’s other finding cuts the same way. No model agreed with the readers detectably more than another reader did. The authors name the limits themselves. It’s a preprint. The material is web documents rather than email. The readers were highlighting for themselves, while the models worked to a task. The direction still holds, and anybody who has read two people’s notes from the same meeting already believed it.
The EmailSum team hit the same wall from the other side. They checked whether the standard automatic scores agreed with human opinion of their summaries. The best correlation they could find was between ROUGE-1 and overall human ranking of the short summaries, at 0.14 with a p-value of 0.16. That’s no relationship worth the name. Their human raters scored on five-point scales and agreed with each other at between 0.09 and 0.23. So there’s no single right summary, and no reliable agreement on whether a given one is any good.
Two things follow, and they’re the whole design.
The source has to stay one click behind. A summary is a judgment made on your behalf. So you check it in the time it takes to be suspicious, on the thread, in place, with nothing to navigate and no message to hunt for. A summary you can’t get behind replaces your mail with a paraphrase of it, and that’s a bad trade at any accuracy.
It has to be correctable, and the correction has to stick. The right summary depends on who’s reading. So a summary written to a general standard goes wrong for you in a consistent, boring, repeated way. Too long. Missing the dates. Burying the ask in a narrative. That’s the gap between a general reader and you, rather than a defect in any one summary, and it closes when the thing learns what you want and keeps it. Making the same correction twice is a fault.
What a summary is not for
Four boundaries. Each one is a job somebody expects the summary to do.
Telling you what matters is a separate job. A summary says what a thread is about. Whether it needs you today, tomorrow or never is a separate measurement, taken on different evidence, and a beautifully accurate summary of a newsletter is still a newsletter. Sorting the inbox by what it costs to ignore is its own discipline, worked through in how email triage works. One score can’t carry that on its own, and important versus urgent has the reason.
The task is a separate object. A summary can say that the client needs the accounts by the fourteenth. The thing with a date on it, sitting where you keep your commitments, has a different lifespan, and email task management covers how an ask inside a paragraph turns into one. A summary hands the task off, and you still want the task.
A digest of your day is a different shape. One thread, one account. A briefing runs across everything that arrived and answers a separate question. The two get confused because both are short. If you find yourself wanting a weekly summary email of your own inbox, the briefing is the thing you want.
A summary is not the record. This is the one boundary where getting it wrong costs money, so it’s worth the flat statement. Where the stakes are real, you read the thread. A summary tells you which threads those are, which is the more useful job anyway. Nobody should be advising a client, signing anything, or quoting a figure back to a tax authority off a paraphrase, and any tool suggesting otherwise is selling you a risk you never priced.
How Point writes one for every thread
Point is a full email client rather than a button added to the one you have, so the reading is done before you arrive. Every thread carries a plain summary Point wrote. The feed comes in three depths, and single clicks move you between them.
The first depth is the line in the feed. A few words, a marker for whether it needs you now, and a time. Point’s own description of it is the honest one: often that line is all you need to read, and the thread is finished without ever being opened.
The second is the summary card. One click opens it in place, with nothing navigated away. A four-paragraph message becomes a short account with the decisions in it. You can act from there. Reply, set it aside, or file it. How much Point handles unprompted is a setting you hold separately for each kind of action. It starts on review, so out of the box the work arrives prepared and waits for you.
The third is the mail itself. One more click and you have the original, with real headers and the full formatted body, exactly as it arrived. The whole message stays there behind the summary, and one click goes back. You choose the depth thread by thread, and that’s the part that makes the summary safe to trust. The mail is always still there.
A thread grows attachments, a meeting and a task around it. Point draws those into the same expandable idea, so the summary you open covers the whole situation rather than the last mail in it. And when Point’s idea of a summary differs from yours, you say so in a sentence. Point keeps it as a preference from then on, applied fresh to the next thing that sender sends.
What an AI email client is covers why the summarizing has to live in the client rather than beside it. The benefits page lists what else comes with reading the mail before you do.
Common questions
What should a meeting summary email include?
What was decided, who owns each piece, by when, and what was raised and left unsettled. Then a pointer to where the detail lives. Check it against one test: could somebody who wasn’t in the room act on it without replying to ask you a question. The open items are the part most people cut, and the part that costs the most when it’s missing.
Can I trust an AI summary of an email?
Trust it for the decision it’s built to support, which is whether to open the thread, and treat it as a paraphrase for everything else. It’s a judgment rather than a fact, and two human readers disagree enough about what matters in the same document that “correct” isn’t really the standard on offer. What makes it safe is the original staying one click away, so checking costs you a second.
How long should an email summary be?
Short enough to read without deciding to read it. The hand-written corpus above compresses a 233-word thread into about 27 words, roughly one word in nine, and that ratio is a reasonable expectation for the version you scan. Longer summaries earn their place once you’ve decided a thread matters. A summary you have to commit to is doing the job of the email.
What is the difference between a summary and a preview?
A preview is the opening characters of the most recent message. A summary is an account of the whole thread. The preview comes from the least informative message in the thread, since replies end in acknowledgments, and it reaches back exactly that far. Anything decided four messages ago stays out of it. More preview text leaves the two as far apart as they were.
Do I still need a weekly summary email?
If it’s a report you send a client, yes, and it’s one of the things worth writing by hand. If you mean a weekly digest of your own inbox, that’s a briefing across many threads rather than a summary of one, and it solves a different problem. Per-thread summaries are for deciding what to open. A briefing is for knowing what the day contains.
Does this mean I stop reading my email?
No. You keep reading. What stops is opening threads in order to find out what they are, which is most of what opening currently buys you. Reading becomes something you choose to do because the summary told you the thread deserves it, instead of the only way to learn anything at all.
The short version
A summary email is an account of a thread, written for somebody who didn’t read it, and it works when its reader can act without asking a question back. What your inbox offers today is a sender, a subject written before the thread happened, and the first few words of the least informative message in the thread. Then it asks you to decide from that, a hundred times a day.
What a real summary has to carry is short: the subject in a phrase, the ask, who’s asking, and where it’s gotten to. What it has to admit is that it’s one reading among several. That’s why the thread stays one click behind it, and why a correction has to stick. Get those right and the summary is the thing that tells you which mail is worth your full attention, and lets you spend it there.
How much that’s worth depends on the mail. A twenty-message thread means one thing to a tax practice in February and something else to a coaching business in any month. If yours is neither, the morning is written out eight ways.