How an AI meeting summary is written

A transcript tells you everything that was said. That is rarely what anyone wants. What people want is the four decisions, the six open items and the one number that changed — which is a different task, done after the transcript exists, by a different kind of model. Here is what actually happens between the recording and the page of notes.

Transcript first, summary second

These are two separate jobs and it helps to keep them apart. Transcription is an audio problem: a speech model turns sound into words, and its errors are acoustic — a name misheard, a digit swapped, a sentence mangled where two people talked at once. Summarisation is a text problem: a language model reads the finished transcript and decides what mattered. It never hears the recording.

The practical consequence is that a summary can only be as good as the transcript under it. If the audio was poor, a fluent summary is a warning, not a comfort — it means the model wrote something plausible over shaky text. This is also why the transcript is worth a glance even when you only asked for notes.

What comes out

The structure is fixed on purpose. A summary whose shape changes from meeting to meeting cannot be skimmed, and cannot be fed into anything else. A fixed shape can be read at a glance, compared across weeks, and pulled through the API by your own tools.

The instruction is the part people skip

The default summary is general because the model has no idea why you recorded the meeting. One sentence changes that completely. Compare:

• Nothing: a faithful, even summary of a sixty-minute conversation.
• "Focus on pricing objections and anything we promised to send": the objections are quoted, the promises are a list with owners, and the small talk disappears.
• "Write minutes for a board pack: decisions, dissent, and what was deferred": a different document entirely, from the same transcript.

You can also set a standing instruction so every meeting comes back in your team's format, and re-summarise an old meeting with a new instruction at any time.

Writing a meeting that summarises well

Half of summary quality is decided in the room, before any software is involved:

• Say decisions out loud. "So we're going with option B" is extractable. A nod is not.
• Name the owner. "Dana will send the draft by Sunday" produces an action item with a person and a date; "someone should send that" produces nothing useful.
• Close the loop verbally. Two minutes of "what did we agree?" at the end improves the notes more than any model change.
• Mute what isn't speaking. Background noise costs you transcript accuracy, which costs you summary accuracy.

What a summary is not

It is not a record of what people meant, only of what they said. It is not a substitute for reading the transcript when money or a contract depends on the wording. And it is not a reason to have more meetings — if anything, a team that can read the decisions from last Tuesday in fifteen seconds tends to need fewer of them.