Summarize a long email thread with AI without losing decisions

An email summary is a work product, not a shorter inbox

A long email thread rarely contains one clean story. It contains a proposal, a correction three replies later, a date that moved, a person who was copied but never accepted an action, and an attachment that changed the meaning of the discussion. A fluent paragraph can compress all of that while quietly turning uncertainty into certainty.

That is why I treat an AI email summary as a small piece of operational work. Its job is not merely to be shorter than the thread. Its job is to preserve the state of the conversation: what is confirmed, what is still being discussed, who has actually committed to what, and which facts came from which message.

Current workplace guidance reflects the demand for this task. OpenAI Academy includes summarizing a long email among its common prompts for work and recommends highlighting decisions, action items, and open questions. Microsoft documents email-thread summarization as a Copilot workflow, while also warning that a generated summary can overlook details or misread context. Those two ideas belong together: the use case is valuable precisely because the source is cumbersome, and it needs review precisely because the source is cumbersome.

The workflow below works whether you paste an approved thread into a general assistant or use an AI feature connected to an organizational mailbox. The interface changes; the review problem does not. I use a fictional thread so the expected result can be inspected without exposing a real customer, employee, or commercial discussion.

Sources: OpenAI Academy: ChatGPT prompts for any work role; Microsoft Learn: email summary capabilities and limitations

Start with a six-message thread that has a trap in it

Imagine a fictional team arranging a product demo for a retailer. On Monday, Ada proposes Thursday at 2 p.m. and says the demonstration will include the new returns dashboard. Ben replies that the dashboard is not approved for external use. Chidi suggests Friday at 11 a.m. instead. Ada says Friday works for her and asks Ben to confirm. Ben confirms Friday but says the demo must use the existing analytics screen. Later, Chidi writes that the retailer has requested 11:30 a.m., and asks whether everyone can accommodate the change. No one replies before the cutoff.

The correct state is more nuanced than the latest message. Friday is confirmed as the day. The last mutually confirmed time is 11 a.m.; 11:30 is only a requested change. The new returns dashboard is explicitly excluded, and the existing analytics screen is the approved substitute. No named person has accepted ownership of updating the calendar invitation. Chidi raised that need, but raising a task is not the same as owning it.

This tiny fixture exposes four common errors. A model may report 11:30 as final because it appears last. It may include the new dashboard because it appeared in the initial proposal. It may assign the calendar update to Chidi because Chidi mentioned it. Or it may smooth the unresolved scheduling question into a confident meeting plan.

Write down the expected answer before running a prompt. A test with no expected result only tells you whether the output looks plausible. The fixture should make it possible to say exactly what the assistant preserved, changed, or invented.

Confirmed: demo is Friday; use the existing analytics screen.
Last mutually confirmed time: 11:00 a.m.
Proposed change: retailer requested 11:30 a.m.; team confirmation is missing.
Open action: update the calendar after the time is confirmed; no owner accepted it.
Superseded: Thursday at 2:00 p.m.; new returns dashboard in the external demo.

Prepare the thread before asking for a summary

A summary cannot recover a message it never received. Expand collapsed replies, include the latest message, and decide whether attachments or linked documents are part of the task. If an email says see the revised scope and the scope is not supplied, the honest output is that the revised scope was referenced but not reviewed.

Preserve a stable reference for each message. I use M01, M02, and so on, with sender, timestamp, recipients, subject, and body. Keep the original order even if the email client displays newest first. The labels let the assistant cite a decision as M04 plus M05 and let a reviewer jump back to the supporting text.

Remove repeated quoted copies when they are exact duplicates, but do not delete a quoted passage merely because it looks familiar. Sometimes a reply changes one sentence inside a quoted proposal. If deduplication is uncertain, retain the material and mark it as quoted. Do not ask the model to infer which copy is authoritative without a rule.

Set a cutoff: include messages received through a named date and time. This prevents a recap from sounding current after another reply arrives. If the thread crosses time zones, include offsets or normalize timestamps while preserving the originals. A deadline at 5 p.m. is not usable if nobody knows whose 5 p.m. it is.

Finally, check whether the thread is permitted input. Use the account and workspace approved by the organization. Minimize personal, customer, financial, health, legal, credential, and confidential data. A convenient paste box does not replace the data-handling policy that governs the underlying conversation.

Ask for five buckets instead of one polished paragraph

A polished paragraph encourages the model to connect ideas and remove friction. That is useful for prose but risky for operational state. I ask for five separate buckets: confirmed decisions, action items, open questions, superseded proposals, and a short narrative recap.

A confirmed decision needs evidence that the relevant participants accepted it. Silence is not acceptance. An action item needs an owner only when the thread assigns one or the person explicitly accepts it. A deadline belongs in the action only when it appears in the source. Otherwise the fields should say unassigned or not stated.

Open questions include explicit questions that have no answer and conflicts that the thread does not resolve. Superseded proposals matter because a reader may remember the first suggestion and accidentally act on it. Keeping them outside the current plan reduces that risk without erasing useful history.

The narrative recap comes last, after the structured state. It should be written from those buckets rather than from a fresh interpretation of the entire thread. This order gives the reviewer something inspectable before receiving the convenient paragraph.

I also require evidence references beside decisions, dates, figures, and commitments. A reference does not prove that the model interpreted the message correctly, but it makes verification much faster. If the interface can link directly to messages, use those links. If it cannot, the M-number convention is enough for a manual check.

Summarize the email thread below as of [CUTOFF WITH TIME ZONE]. Use only the supplied messages and attachments. Return: (1) confirmed decisions, (2) action items with owner and deadline only when explicitly assigned or accepted, (3) open questions and conflicts, (4) superseded proposals, and (5) a recap under 120 words. Cite the supporting message ID beside every decision, date, number, and commitment. Distinguish a proposal from an agreement. Treat silence as no confirmation. Write 'not stated' or 'unassigned' instead of guessing. List referenced attachments that were not supplied under 'not reviewed.' Thread: [PASTE M01, M02, ... IN CHRONOLOGICAL ORDER]

Read for conversation state, not keyword frequency

Important words repeat in email. The difficult part is determining their state. A date may be proposed, rejected, restored, or awaiting confirmation. A price may be an estimate in one message and an approved ceiling in another. The word approved may refer to a draft layout, not to the whole project.

For each decision candidate, trace the sequence. Who proposed it? Who needed to agree? What later message changed it? Does the latest message contain acceptance or merely another request? A summary that cites only the most recent mention can still be wrong because the most recent mention may be a question.

Pronouns also deserve attention. We can deliver Friday may refer to the sender's team, the whole project group, or a vendor mentioned earlier. Ask the assistant to retain the exact named owner when available and to flag ambiguous pronouns. Do not let it replace we with a guessed department just to make the table look complete.

Thread structure can mislead as well. A side reply between two people may not constitute agreement by everyone on the main thread. Forwarded text may describe an older state. Automated signatures, disclaimers, and ticket histories may repeat names and dates without adding a new decision.

This is where a source-linked result earns its keep. The reviewer does not need to reread every greeting. They need to inspect the small number of messages that allegedly establish the current state and compare each claim to the surrounding context.

Verify names, dates, numbers, and commitments first

Not every summary error has the same cost. I start review with the fields that can trigger an action: recipient names, meeting dates and time zones, money, quantities, deadlines, approvals, obligations, and links or attachments.

Read the evidence message and at least one message before and after it. The surrounding replies often reveal a correction or limitation. Check whether the cited amount includes tax, whether a date is a delivery date or a review date, and whether approved means approved to explore or approved to send.

Then check the action table. Search the thread for each owner's name and the task language. Did the person say I will do it, or did someone else ask them to? Did the sender specify a deadline, or did the model derive one from the meeting date? Derived deadlines can be useful suggestions, but they belong in a separate recommendation column, never in the sourced commitment column.

Inspect negative statements. Phrases such as do not share, not final, no longer required, and excluding can disappear in compression while the surrounding noun survives. In the fictional example, preserving dashboard without preserving not approved would reverse the meaning.

Finally, verify completeness against the last message at the cutoff. A summary can be accurate about the first ninety percent and still miss the reply that changed the plan. Record the cutoff in the final recap so readers know whether they need to check for later mail.

1. Latest included message and cutoff
2. Names and accepted owners
3. Dates, times, and time zones
4. Amounts, quantities, and versions
5. Approval and prohibition language
6. Missing or unreviewed attachments
7. Open questions that could block action

An attachment mentioned is not an attachment reviewed

Email threads often carry their most important facts outside the email body. A message may say the redlines are resolved, see v4, or use the schedule attached. If the model cannot access that file, the summary must not inherit the sender's claim as an independently checked fact.

I use three labels: supplied and reviewed, referenced but not supplied, and supplied but unreadable. This avoids the vague phrase attachment unavailable, which does not tell the next person whether the file was missing, inaccessible, corrupted, or simply outside the task.

If several versions are attached, identify them by filename, message, and timestamp. Do not assume final in a filename is authoritative. Ask which version the thread explicitly adopts and whether a later attachment supersedes it. If the model compares attachments, keep that comparison separate from the email-state summary so a reviewer can see what came from the messages and what came from the files.

Links deserve similar treatment. A link to a live document may show content that changed after the email was sent. Record when it was accessed and avoid claiming that the current page exactly matches what the sender saw. Permission errors should remain visible rather than being filled with context from nearby messages.

For a high-stakes thread, open the decisive attachment yourself. AI can point to the relevant page or clause, but the person acting on the recap should verify the source that creates the obligation, price, scope, or deadline.

Create the reply only after the summary is approved

It is tempting to ask for a summary and reply in one step. I separate them. Otherwise an uncertain interpretation can flow directly into an outward-facing promise before anyone notices it.

Approve the structured summary first. Resolve or explicitly retain the open questions. Then ask for a reply using only the approved decisions and actions. Provide the audience, purpose, tone, and desired ask. Tell the assistant not to add reassurance, a deadline, a concession, or a commitment that is absent from the approved state.

In the fictional demo thread, the correct reply should not announce 11:30 as the final time. It should ask Ada and Ben to confirm whether the requested change works, restate that the existing analytics screen will be used, and avoid assigning the calendar update until someone accepts it.

Check recipients before sending. A thread summary may include internal commentary that should not be repeated to an external recipient. Remove quoted history if it exposes unnecessary information. Confirm the correct attachment is present and that track changes, hidden sheets, comments, or document metadata do not reveal internal material.

Connected tools may be able to draft inside a mailbox, but drafting is not authorization to send. Keep the final send as a deliberate human action unless an approved workflow explicitly defines otherwise. The ten seconds saved by skipping review are not worth an invented commitment sent to a customer or colleague.

Using only the approved thread state below, draft a reply to [RECIPIENTS]. Purpose: [PURPOSE]. Tone: [TONE]. Ask: [DESIRED NEXT ACTION]. Do not turn open questions into decisions, assign unaccepted owners, invent dates, or mention internal-only discussion. Keep unresolved items explicit. End with a short confirmation request. Approved state: [PASTE REVIEWED SUMMARY]

Change one message and see whether the result changes correctly

A reusable prompt should respond to meaningful changes in the source. After the first run, make a copy of the fictional fixture and change one fact at a time.

First, add a reply from Ada saying 11:30 works. The time is still not fully confirmed if Ben's agreement is required. Then add Ben's acceptance. Now 11:30 can move from proposed change to confirmed decision. The summary should retain the approved analytics screen throughout.

Next, change Chidi's message from please update the calendar to I will update the calendar after confirmation. That creates a conditional owner, not a completed action. The output should name Chidi and preserve the condition. If the model reports the calendar as already updated, it has confused intention with completion.

Try removing Ben's dashboard restriction. The summary should no longer claim the new dashboard is prohibited; it should say the demo content is unresolved unless another message settles it. This test catches prompts that memorize an expected answer instead of reading the supplied thread.

Return to the unchanged fixture between tests and record expected versus observed results. A prompt that passes a single example may only fit that wording. A few controlled mutations reveal whether it understands proposal, acceptance, supersession, ownership, and completion well enough for the class of threads you plan to summarize.

Choose between pasting, connecting, and built-in summaries

There are three common ways to run this workflow. You can paste a minimized thread into an approved assistant, connect an assistant to the mailbox under organizational permissions, or use a summary feature built into the email product.

Pasting gives you tight control over the exact input and makes message labeling easy, but copying is manual and can accidentally move data into the wrong account. A connection reduces copying and can preserve links to source messages, but its access scope and workspace controls need review. A built-in summary is convenient, though it may offer less control over output structure and evaluation.

The best option is the one that fits both the data policy and the review need. For a low-risk coordination thread, a built-in recap may be enough. For a complicated project handoff, I want a structured prompt and explicit evidence references. For legal, personnel, health, financial, security, or regulated matters, use the approved environment and the qualified review required by the organization; a general workflow article cannot set that standard for you.

OpenAI's current guidance for work specifically cautions against connecting company email, calendars, messages, or files to a personal account unless the organization permits it. That is a useful baseline regardless of product: access should follow the workplace's authorization, not the user's convenience.

Whichever path you choose, save the summary with its cutoff, not as a timeless replacement for the thread. New replies change the state.

Sources: OpenAI Academy: getting started with ChatGPT Work; OpenAI Help: using ChatGPT in Slack and its data controls

Hand off a summary that tells readers what to verify

A useful final recap includes the thread subject, covered dates, cutoff, messages included, attachments reviewed, and the five output buckets. It also names the reviewer and review status. Draft, checked, and approved are different states.

For the fictional thread, I would hand off: six messages reviewed through Tuesday at 4 p.m.; Friday confirmed; 11 a.m. last mutually confirmed time; 11:30 awaiting team confirmation; existing analytics screen approved for the external demo; calendar update unassigned until the time is settled; no attachments reviewed. That is longer than a one-line recap and far safer to act on.

Keep a link to the source thread when permissions allow. Do not paste the entire conversation into another broad channel merely for convenience. The summary should reduce reading effort without widening access to the underlying material.

If someone corrects the recap, update it visibly and note the source message. Do not silently edit a confirmed decision and leave readers wondering which version they saw. For recurring summaries, use the same headings and review rules so missing owners or unreviewed files remain easy to spot.

The goal is not to replace reading forever. It is to direct attention. A good AI summary tells a busy reader what the conversation currently means, where the evidence lives, and which questions still prevent action. When it does that, the thread becomes manageable without pretending that compression is certainty.