Feed a transcript to a model and ask for a summary and you will get one. Whether it is worth circulating depends almost entirely on two decisions made before the model ever sees the text.
What it can do well
Extract, when told exactly what to extract. Decisions, agreements, action items with an owner and a due date, figures, commitments, disagreements, open questions, verbatim quotes. These are retrieval tasks over a document, and models are good at them.
Work in a language nobody spoke. The minutes of a Spanish-language session can come out in English, or in any of the 58 catalogue languages, without a second pass.
Cite the moment. If the transcript carries real clock times, the model can attribute a decision to 11:40, which is what makes minutes checkable against the recording rather than merely plausible.
What it does badly, and why
Free prose. Asked for “a summary”, a model decides what mattered, and it consistently drops whichever section it judges thin. An eight-hour conference comes back as one page. The fix is not a better prompt in the same shape: it is demanding a fixed structure so that an empty section is empty because the event was, not because the model economised.
Long events, if you let it. This is the failure worth knowing about because it is invisible. We measured it: planting thirty stated facts in a synthetic transcript and counting how many survived to the rendered document, a smaller model kept a median 18 of 30 on a seven-hour event, against 29 of 30 for a larger one. On a two-hour event the two were 28 and 30. Nearly identical. The loss grows with the length of the event, which means it is worst exactly where nobody proof-reads the minutes against what was said.
If you are evaluating any summarisation tool, that is the test: a long transcript with known facts in it, counted. And run it twice, over the same transcript the same model scored 19/30 and then 29/30, so a single run is noise, not a result.
Guessing who spoke. A model asked to tell speakers apart from a single mixed microphone will guess, and it will do it confidently. Minutes that attribute a decision to the wrong person are worse than minutes that attribute it to nobody: the first is a document somebody will act on. This is why speaker names should be typed by the technician where each person has their own microphone, and why nothing should be attributed where they do not.
The two decisions that matter
One: enforce the shape. A schema the model must fill, not a request it may interpret. Sections the event did not contain come back empty, which is information.
Two: keep authoritative data out of the prose. Audience votes and launched questions are recorded facts with exact tallies. If they are concatenated into the transcript and the transcript is long enough to be processed in pieces, they end up condensed alongside unrelated speech and the final pass never sees the originals, so the half-day conference, the event most likely to have had a Q&A segment, is the one that loses it. They have to travel beside the transcript, not inside it.
What to expect in practice
A first draft, not a finished document. It removes the blank page, it will not remove the reader. For a council sitting it is a starting point the clerk edits; for a corporate meeting it is usually close enough to circulate with a glance over it.
And one practical note on privacy: minutes are the main reason to store the transcript at all. A live caption pipeline does not need to keep the text, so ask any supplier whether theirs does, whether summarisation is opt-in, and how long the stored text survives if you use it.