A transcript is nearly useless — nobody rereads forty minutes of speech. The value is extracting the three decisions and five actions buried in it.

1. Extract, don't summarise

A generic summary helps nobody. Ask for the specific things people need afterwards:

meeting-extract.txt
Here is a meeting transcript: <transcript>

Extract, as JSON:
- decisions: what was decided, and by whom if stated.
- actions: what, who owns it, and by when. Owner null if unassigned.
- open_questions: things raised and not resolved.
- one_line: what this meeting was about.

Rules:
- Only what's actually in the transcript. Don't infer an owner from
  who spoke most.
- Transcripts are messy — ignore false starts and filler.
- If something is ambiguous, keep the ambiguity. "Someone will look
  into X" is an action with a null owner, not an invented one.
- If a decision was discussed but not concluded, it's an open
  question, not a decision.

That last rule is the one that matters. Meetings frequently end without deciding, and a summariser that manufactures a decision is actively harmful.

2. Handle the length

Long meetings exceed the context window. Chunk by time, extract from each, then merge — deduplicating actions that were mentioned twice.

Say in the output when this happened, so nobody assumes completeness.

3. Keep it reviewable

Always link each extracted item back to where it came from in the transcript, and keep the transcript. Someone will dispute an action item, and being able to point at the sentence resolves it in seconds.

4. Deliver it where people are

An extraction sitting in a database is not a product. Post it to the channel, email it to attendees, or create the tasks directly in whatever tracker they use — with a human confirming before anything is created.

Never auto-assign work to someone based on a transcript. Draft it, show the owner, and let a person confirm. Getting this wrong is a social problem, not a technical one.