To summarize a long document with AI without losing key details, tell the model exactly which details count (figures, names, dates, decisions, obligations), put the document first and your instructions last, ask it to quote the relevant passages before summarizing, and make it write “Not stated” instead of guessing. If the document is longer than the model can handle well in one pass, split it into sections, summarize each with the same instructions, then merge the section summaries. The prompts below implement each of those steps and can be copied as they are.
Featured image: “Legal Contract & Signature – Warm Tones” by Blogtrepreneur, licensed under CC BY 2.0.
This guide is built as a workflow: first why long summaries lose detail, then a base prompt, then variants for reports, transcripts, research papers and contracts, then the chunk-and-merge method for documents that are too long, and finally a short verification pass that catches what the summary got wrong.
Why “summarize this” drops the details you needed
A plain “summarize this” request loses detail for three separate reasons, and each needs a different fix.
- The model does not know what matters to you. A summary is a selection. Without a stated purpose, the model picks what looks central to the text, which is often the narrative and not the numbers, deadlines or exceptions you care about. The fix is to name the fields you need.
- Single-pass summaries do not scale with input length. OpenAI’s cookbook notebook on summarizing long documents points out that summarizing a very long text in one call tends to produce a short output whose length barely grows with the input, so a 100-page report and a 10-page report can come back at similar lengths. The fix is to chunk the document and control detail per chunk.
- Information in the middle of a long input is used less reliably. The paper Lost in the Middle: How Language Models Use Long Contexts (Liu et al.) found that models did best when relevant information sat at the start or end of the input and noticeably worse when it sat in the middle, including models built for long contexts. Newer models handle this better, but the fix is cheap: make the model quote first, and keep sections small enough that nothing is “in the middle” of very much.
A fourth problem appears once you start asking for specific fields: the model may fill a field it cannot find. Asking for a “budget” when the document has none invites an invented number. That is why every prompt below includes an explicit instruction for missing information. For a deeper treatment of that failure mode, see reducing AI hallucinations with better prompts.
The base prompt for any long document
The base prompt below works for most documents up to the size your model handles comfortably in one pass. It follows the layout Anthropic recommends in its prompting best practices for long inputs: the document goes at the top, wrapped in XML-style tags, and the instructions and question come after it. Anthropic’s documentation says placing the query at the end can noticeably improve response quality on long, multi-document inputs, and recommends asking for relevant quotes before the task itself.
<document>
<source>[file name or title]</source>
<document_content>
[paste the full text here]
</document_content>
</document>
I need a summary of the document above for this purpose: [who will read it and what decision or task it supports].
Step 1. Inside <quotes> tags, copy word for word the passages that contain:
- every number with its unit (amounts, percentages, dates, counts)
- every named person, team, company or product and their role
- every decision, commitment, deadline or obligation
- every risk, exception, condition or open question
Number each quote and note the section or page it came from.
Step 2. Inside <summary> tags, write the summary using only what is in your quotes:
- One-paragraph overview (3-4 sentences) answering: what is this document and what does it conclude?
- Key facts: a bulleted list, each bullet ending with the quote number it relies on, e.g. [Q4].
- Decisions and obligations: who must do what, by when.
- Risks and open questions.
Rules:
- If a field above has no support in the document, write "Not stated in the document". Do not infer it.
- Keep numbers exactly as written in the source. Do not round or convert them.
- If two passages contradict each other, report both and say they conflict.
- Length: the overview is short; the lists can be as long as the document requires.Why each part is there
- The purpose line is the most important sentence in the prompt. “For a CFO deciding whether to renew the contract” produces a different, better summary than “for a general audience”, because it tells the model what to keep and what to drop.
- The quote step forces the model to scan the whole document for the categories you named before it starts compressing. It also gives you something to check: every bullet can be traced to a passage.
- Quote numbers on each bullet make verification fast. If a bullet cites [Q7] and Q7 does not say that, you found an error in seconds. If you need stronger sourcing, the technique is covered in detail in a prompt for making Claude cite the exact sentence behind every claim.
- “Not stated in the document” gives the model an approved way to leave a gap. Without it, a field you asked for is pressure to produce something.
- Exact numbers and conflict reporting prevent two quiet errors: rounding “$1,240,000” to “about $1.2M” in a context where precision matters, and silently picking one of two contradictory figures.
If you only need a quick read and not a traceable summary, drop Step 1 and the quote numbers. Keep the purpose line and the missing-information rule; those two do most of the work.
Variants for four common document types
The base prompt’s extraction list is generic. Replacing it with fields specific to the document type gives better recall, because the model knows exactly what to look for. Paste each block in place of the Step 1 bullet list and the Step 2 headings.
Long business reports
Extract and summarize:
- The report's main conclusion in one sentence, as the authors state it.
- Every metric reported, with period, unit and comparison baseline (e.g. "Q3 revenue $4.2M, up 8% vs Q3 last year").
- Recommendations, each with the owner and timeline if given.
- Assumptions the conclusions depend on.
- Data limitations or caveats the authors mention.
Output headings: Conclusion / Metrics table (Metric | Value | Period | Baseline | Section) / Recommendations / Assumptions / Caveats.The metrics table is the useful part. Reports tend to scatter numbers across narrative paragraphs, and a table with a “Section” column makes each figure checkable.
Meeting and call transcripts
Extract and summarize:
- Topics discussed, in the order they came up.
- Decisions made: what was decided and who agreed. Mark a decision as "tentative" if anyone expressed doubt and it was not resolved.
- Action items: task, owner (a named person), due date. If owner or date was not said, write "No owner named" or "No date given".
- Questions raised but not answered.
Ignore small talk, repeated points and filler. Attribute statements to speakers only when the transcript labels the speaker.The “tentative” label matters because transcripts often contain statements that sound like decisions (“let’s go with vendor B”) followed ten minutes later by “actually, let’s check pricing first”. If action items are the main output you need, the dedicated guide on turning meeting notes into action items goes further.
Research papers
Extract and summarize:
- Research question, in one sentence.
- Method: data, sample size, setup, and what was compared against what.
- Main results, with the exact numbers and the conditions under which they hold.
- Limitations the authors state.
- What the paper does NOT show (claims a reader might assume but the results do not support).
Write for a practitioner who will not read the paper. Keep the authors' own hedging ("suggests", "in our setting") rather than turning it into certainty.The last two lines address a common summary distortion: hedged findings come back as general facts. “Improved accuracy on two benchmarks” becomes “improves accuracy”. Asking explicitly for what the paper does not show counters that.
Contracts and agreements
Extract and summarize, citing the clause number for every item:
- Parties and their roles.
- Term, start date, renewal mechanism and notice period for termination.
- Payment terms: amounts, schedule, late fees, price change rules.
- Each party's main obligations.
- Liability caps, indemnities and exclusions.
- Data, confidentiality and IP clauses.
- Anything unusual or one-sided compared with the rest of the contract.
If a standard item is absent, list it under "Not found in this contract".
This is a reading aid, not legal advice; flag clauses whose meaning is ambiguous instead of interpreting them.For contracts, the “Not found” list is often more valuable than the summary. A missing termination-for-convenience clause or a missing liability cap is a finding in itself. Have a qualified person review anything you will sign.
When the document is too long: chunk, summarize, merge
Chunking means splitting a document into sections, summarizing each section with the same instructions, and then combining the section summaries in a final call. Use it when the document exceeds the model’s context window (the maximum amount of text it can take in at once; see the explainer on context windows), and also when it fits but you need more detail than a single pass returns.
Step 1: split on the document’s own structure
Split at chapter, section or heading boundaries rather than at a fixed character count. A section summarized whole keeps its internal logic; a fixed-size cut can separate a figure from the sentence that explains it. If sections are very uneven, merge small neighbors and split giant ones at subheadings. The OpenAI notebook mentioned above makes the trade-off explicit: more, smaller chunks produce a longer and more detailed combined summary, fewer chunks a shorter overview. Choose chunk size by how much detail you need, not only by what fits.
Step 2: summarize each chunk with a running context
<context>
Document: [title]. Purpose of the final summary: [purpose].
This is section [n] of [total]: "[section heading]".
Summary of earlier sections so far (for reference only, do not repeat it):
[paste the previous section summaries, or "None - this is the first section"]
</context>
<section>
[paste this section's text]
</section>
Summarize only this section, using the same fields as the other sections:
- Key facts (exact numbers, names, dates), each with the page or paragraph reference.
- Decisions, obligations, deadlines.
- Risks and open questions.
- Terms defined in this section that later sections may use.
If this section refers to something defined elsewhere that you cannot see, write "Refers to [X], defined outside this section" instead of guessing what it means.Passing the earlier summaries keeps terminology consistent and lets the model notice when a later section revises an earlier figure. The “defined outside this section” line handles the classic chunking error, where a section says “the amount in Schedule B” and the model invents what Schedule B contains.
Step 3: merge the section summaries
Below are summaries of every section of [document title], in order.
<section_summaries>
[paste all section summaries, each labeled with its section number and heading]
</section_summaries>
Write the final summary for [purpose]:
1. Overview: 4-6 sentences on what the document is and what it concludes.
2. Key facts: deduplicate across sections. Where sections give different values for the same thing, show both with their section numbers.
3. Decisions, obligations and deadlines, in date order.
4. Risks and open questions, including any "Refers to ... defined outside this section" notes that the other summaries do not resolve.
Keep section references on every item. Do not add anything that is not in the section summaries.This three-step chain is a specific case of prompt chaining: each call does one job, and you can inspect the output between steps. If one section summary looks thin, rerun that section alone instead of the whole document.
A worked example of the chunked approach
The following is an illustrative scenario, not a real document. Suppose an operations manager has a 120-page vendor due-diligence report and needs a two-page brief for a renewal decision.
| Step | What the manager does | What to check in the output |
|---|---|---|
| Split | Uses the report’s eight chapters as chunks; splits the 40-page security chapter at its three subheadings, giving ten chunks. | No chunk starts mid-table or mid-list. |
| Summarize | Runs the Step 2 prompt ten times, purpose “renewal decision: cost, risk, exit options”. | Each summary has page references; “defined outside this section” notes are collected. |
| Merge | Runs the Step 3 prompt on the ten summaries. | Conflicting values (for example, two different uptime figures) appear side by side with their chapters. |
| Verify | Runs the verification prompt below against the two chapters with the most numbers. | Every flagged item is checked by hand against the page cited. |
The point of the example is the order of work, not the numbers: structure-based chunks, a stated purpose repeated in every call, references carried through to the final brief, and a targeted check at the end.
Verify the summary before anyone relies on it
A summary verification pass is a second prompt that compares the summary against the source and lists discrepancies. It is cheap and catches the errors that matter most: wrong numbers, invented details and dropped exceptions. Run it in a fresh conversation so the model is not defending its own earlier output.
<source>
[paste the original document or the section being checked]
</source>
<summary>
[paste the summary]
</summary>
Check the summary against the source, item by item. Output a table with columns:
Summary item | Status (Supported / Not found / Contradicted / Distorted) | Source passage (quoted) | Note
"Distorted" means the source says something related but the summary changed its meaning, certainty, number or scope.
After the table, list important facts in the source that the summary omitted, given this purpose: [purpose].The “Distorted” status is the one that earns its place. Outright inventions are rare when the base prompt is used; the more common problems are a “may” turned into “will”, a figure for one region presented as global, or a condition dropped from an obligation.
Mistakes that undo a good summary prompt
- Asking for a fixed word count first. “Summarize in 200 words” makes length the main constraint, so detail is cut to fit. Specify the fields first; set length only for the overview paragraph.
- Putting the instructions above a very long document. On long inputs the instructions can end up far from where the model generates its answer. Put the document first and the instructions after it, as in the templates above.
- Pasting a PDF conversion without checking it. Text extracted from PDFs often has broken tables, headers repeated on every page and columns merged out of order. Skim the extracted text before blaming the model for a garbled summary.
- Summarizing a summary of a summary. Each merge step loses information. With many chunks, merge in one step from all section summaries rather than in pairs.
- Trusting a summary of a document you never opened. For anything with legal, financial or safety consequences, read the passages behind the key bullets. The quote numbers make that a five-minute job.
- Pasting confidential documents into tools your organization has not approved. Check your data-handling policy before uploading contracts, HR files or customer data to any AI service.
Choosing the approach by document size and stakes
| Situation | Approach |
|---|---|
| Short document, quick read, low stakes | Base prompt without the quote step; keep the purpose line and “Not stated” rule. |
| Document fits in context, decisions depend on it | Full base prompt or a type-specific variant, then the verification prompt. |
| Document fits but the single-pass summary is too thin | Chunk by section anyway to get more detail per section. |
| Document exceeds the context window | Chunk, summarize with running context, merge, verify the highest-stakes sections. |
| Several related documents | Wrap each in its own <document> tag with a source label, ask for quotes per document, and require source labels on every summary item. |
Whatever the size, the pattern is the same: say what the summary is for, name the details that must survive, let the model say “not stated”, and keep a trail from every claim back to the page it came from.
