A meeting summary is not minutes, and the difference is the work

The call ends and the email lands eleven minutes later. Four hundred words, well organized, accurate: the team discussed the staging environment, agreed to move the demo, and raised a concern about the auth migration. Everyone reads the first two lines. By Thursday nobody can tell you what was agreed, because not one thing in that email is an object anybody owns.

Meeting transcription got very good, and the problem it was sold against is still sitting there. That is not a failure of the models. It is that a summary and minutes are two different documents with two different jobs, and the tools are extremely good at producing the one you needed less.

Three artifacts wearing one name

A transcript is evidence. It is verbatim, searchable, and almost never read. Its job is to settle a disagreement about what was said, which is a job it does perfectly and roughly twice a year. Length is not a defect in a transcript, because nobody reads it front to back.

A summary is a compression, and its audience is someone who was not in the room. It is optimized for reading time, and its correctness test is whether a person who missed the call now understands what happened. Every good summary is lossy on purpose. That is what makes it a summary.

Minutes are neither. They are a record of commitments, and they are not a shorter version of the meeting but a different selection out of it: decisions with a date, obligations with an owner, open questions with an addressee. The test is not whether they read well. It is whether each line can be acted on, and whether its absence would break something later.

The failure modes are asymmetric, and that asymmetry is the whole argument. A summary that leaves out a detail is still a good summary. Minutes that leave out a decision are a defect, and it surfaces three weeks later as an argument about scope that nobody can win. Two documents graded that differently cannot come out of one pass over the same text at the same standard.

What a transcription tool actually hands you

Three things, usually: the verbatim text, a summary, and a bulleted list labeled action items. The first two are genuinely solved and worth the money on their own. The third is where the promise lives, and it is the structurally weakest of the three.

The reason is not model quality. It is that the list is extracted from what was said, and what was said is not what is owed. Three shapes account for most of the gap.

• The hedge."Someone should probably look at the staging environment" is a sentence in the shape of an action and a commitment by nobody. It arrives in the list carrying exactly the same weight as a real one, because grammatically it is one.
• The delayed yes. The actual commitment is often two words, three turns after the thing being committed to, from a voice the transcript labels Speaker 3. Recovering it is an attribution problem across the conversation, not a summarization problem within a paragraph.
• The item that already exists. A good part of any list is work that is already a ticket. Nothing in the recording knows your backlog, so nothing in the list can tell you which lines are new, and the cost of that shows up as duplicates your team has to close.

And even the lines that are right are not yet actionable in the only sense that matters. They have no owner as your tools know owners, no destination, and no shape. They are sentences about work rather than work.

The last mile is where the hour goes

Time the part after the call sometime. Very little of it is writing. It is three decisions per item, repeated: does this count, who owns it, and where does it live. None of the three can be answered from the recording, because all three depend on what you know about the team, the sprint and the quarter.

Then there is the shape tax, which is the part people underestimate. A Jira issue is not a sentence: it needs a project, an issue type, and often fields that particular project marks required, which differ from project to project and appear in no transcript ever recorded. A Slack message needs a channel. A Confluence page needs a space and a parent. Each is a small question, answered per item, in a different interface, and the switching costs more than the typing.

What a good handoff looks like

If the last mile is a routing problem rather than a writing problem, the tool should be shaped like a router rather than a writer. Five properties separate the ones that help from the ones that add a document to your week.

• It reads what you already have. The notes you typed, the transcript someone sent you, a document on disk. A tool that requires a bot in the call has made joining the meeting a precondition for organizing it.
• It proposes rather than files. Reading a proposed write with its target already filled in takes a few seconds. Writing the same thing by hand takes a couple of minutes. That ratio is the entire economics of the last mile, and it only holds if the proposal is specific enough to approve.
• Approval is per item. One button that files everything is a button for approving a list you did not read, and the items you would have deleted are exactly the hedges from the section above.
• Destinations are asked before the model runs, not after. Picking the project or the channel first means a change of mind costs nothing. Generating a draft and then discovering the target was wrong means paying for the draft twice.
• Something comes back. A created issue key, a message link, a page URL. Without a receipt you have no way to tell an item that landed from an item you approved, and you end up checking each tool by hand, which is the work you were removing.

That is the shape Khint's Super Khint step takes. It reads a selection, your clipboard or a document, proposes each write with its target filled in, and runs nothing until you click Run on that row. Anything the planner could not know, such as a field the destination project marks required, is asked in the row at the moment you approve it. Each write returns its key or URL, and the completed run leaves a row you can open straight to the thing that was created. The writes themselves are the ordinary integration writes that a scripted workflow uses, with an approval in front of each one.

What no tool decides for you

A proposal list is a draft of your judgment, and it is wrong in both directions. It will offer you the hedge as a ticket and it will miss the sentence that mattered because nobody phrased it as an action. Approving quickly is fine; approving without reading gives you a backlog full of somebody's conversational filler, and the cleanup is worse than the retyping was.

Writes to other people's tools are also not atomic, and any tool that claims otherwise is describing something it cannot deliver. If three writes go out and the second fails, the first one already exists and a colleague can already see it. Rolling back would mean deleting a ticket someone may have started reading. The honest contract is to report exactly which ones landed and let you decide about the rest, which is why a run should tell you per item rather than per batch.

Then the limits that are simply outside software. The decision made in the corridor afterwards is not in any input. Neither is the thing everyone in the room understood and nobody said, which is often the most important constraint on the work. And Khint in particular has no recorder and no bot that joins your call: it works on text you already have, so if your problem is that nobody is taking notes at all, you want a note-taker first and the comparison with one is the honest version of where the line sits.

Where to start on Monday

Stop producing a minutes document. It is the artifact everyone asks for and almost nobody reads, and it survives because it is a familiar shape rather than because it works. Produce two things instead, and let them be different.

The record goes where the work happened. A work session in Khint is a container for exactly this: notes and results accumulate as entries, and a compacted state keeps the objective, the open threads, the decisions and the artifacts current, so the next thing you run knows what has been going on. Sessions and their entries live in a local database on your machine and are never synced to any server, which is the right default for a record that contains half-formed opinions about people.

The commitments go into the trackers that already own them, one at a time, each with a destination you approved. That is minutes: not a page describing obligations, but the obligations themselves, existing as objects in the places your team already looks. If you want the mechanics of the first one, the walkthrough for turning meeting notes into Jira tickets covers the setup, and why AI tickets get rejected in refinement covers what has to be in one for it to survive contact with a developer.