Summarization patterns for LLM applications

The phrase "we need summarization" is usually missing the most important detail: for whom, and for what decision?

A support handoff summary, an executive recap, and a meeting summary for a workflow engine are not the same product. If you do not define the reader and the decision first, the model will optimize for sounding tidy instead of being useful.

Summaries are different products

If the output needs to drive a system, structured summaries are usually the best production pattern.

A worked example: meeting notes to structured summary

Suppose a product team wants meeting notes transformed into a structured record for follow-up workflows.

The requirement is not "write a nice recap." It is:

• capture decisions
• capture owners
• capture open questions
• keep the output machine-readable

Here is a TypeScript schema for that:

type MeetingSummary = {
  summary: string;
  decisions: { decision: string; owner: string | null }[];
  actionItems: { task: string; owner: string | null; dueDate: string | null }[];
  openQuestions: string[];
};

And here is a sample output shape:

{
  "summary": "The team agreed to ship the pricing page update next Tuesday and delay the onboarding redesign.",
  "decisions": [
    { "decision": "Ship pricing page update next Tuesday", "owner": "Alicia" }
  ],
  "actionItems": [
    { "task": "Update launch checklist", "owner": "Marcus", "dueDate": "2026-03-18" }
  ],
  "openQuestions": [
    "Do we need legal review for the enterprise copy update?"
  ]
}

This is more useful than a free-form paragraph because another system can route tasks, assign owners, or create reminders.

Operational summaries should bias toward action

An operational summary should answer:

• what happened
• what matters now
• what should happen next

Good examples:

• support handoff note
• incident recap
• account-manager follow-up

The common mistake is turning an operational summary into a long paraphrase of the source text. The person reading it usually wants action context, not literary compression.

Executive summaries should compress, not narrate

Executive readers usually need:

• what changed
• why it matters
• what decision or watchpoint follows

If the summary spends half its length repeating background the audience already knows, it is doing the wrong job.

Executive summaries often benefit from a fixed structure such as:

• change
• implication
• next decision

That is easier to review than a generic prose recap.

Ground the summary before polishing it

A reliable summarization workflow usually follows this order:

1. identify the important facts
2. define the audience
3. define the output shape
4. only then tune phrasing

Teams often reverse that order. They focus on tone first and only later realize the summary does not capture the fields or decisions anyone actually needs.

Split the workflow when one prompt is doing too much

Summarization often gets better when you separate it into stages:

• transcript -> extract decisions and action items -> generate human recap
• incident notes -> structured event record -> executive summary

This lowers review burden because the system does not need to both extract facts and produce polished prose in one pass.

How to evaluate summarization

Track:

• factuality
• coverage of required points
• format compliance
• actionability for the intended audience

For structured summaries, also track:

• field completeness
• downstream usability

The right question is not "does this read well?" It is "does this help the next human or system do the job?"

A practical summary spec

Use this before building:

Workflow:
Audience:
Decision this summary supports:
Must-include items:
Must-not-include items:
Output shape: prose, bullets, or schema
Primary metric:
Guardrail metric:

If the "decision this summary supports" line is blank, the summary is too generic to be useful.

The common failure mode

The common failure mode is treating summarization like one universal feature. It is not. The right summary shape depends on who consumes it next.

A polished but generic summary is often worse than a blunt summary that captures the actual action items.

How StackSpend helps

Summarization looks cheap in prototypes because the feature sounds simple. In production, prompts and outputs tend to expand. In StackSpend, you can watch cost per completed summary workflow, see whether one summary type is driving unusually large prompts, and catch when a "simple recap" feature has turned into a high-volume hidden token sink.

What to do next

• Structured outputs for extraction, classification, and scoring
• Production chat systems: memory, handoffs, and escalation

FAQ

When should a summary be structured instead of prose?

When another system, workflow, or model will consume it. Structured summaries are easier to validate and reuse.

How short should an operational summary be?

Short enough that a person can act quickly from it, but complete enough to capture current state, next action, and any risk or blocker.

Why do summaries hallucinate missing facts?

Often because the prompt rewards coherence more than evidence. Requiring explicit fields, source grounding, or "unknown" values helps reduce invented details.

Should I use one summary prompt for every audience?

Usually no. Executive, operational, and structured summaries have different consumers and different success criteria.

What is the best quality metric for summarization?

Start with factuality and required-point coverage, then add actionability or downstream usability depending on the workflow.

References

• OpenAI Prompt Engineering Guide
• Anthropic Prompt Engineering Overview
• OpenAI Structured Outputs Guide