Automatic transcription became reliable and, for most teams, changed nothing. The bottleneck was never capturing what was said — it was that a searchable wall of speech is barely more useful than no record at all. A decision made forty minutes into a call is still effectively lost.
The three things worth extracting
Almost everything in a transcript is context for a small number of durable outputs. Extract those and let the rest be archive:
- Decisions. What was decided, what alternatives were rejected, and on what reasoning.
- Commitments. Who owns what, by when. Distinct from decisions and usually the part that evaporates.
- Open questions. What was raised and deliberately not resolved. The most commonly lost category, and the one that resurfaces as a surprise in a later sprint.
Why raw transcripts fail as records
- No structure. Search returns the moment a topic was mentioned, not the conclusion reached about it.
- No supersession. A decision reversed in a later meeting sits alongside the original with equal weight.
- Ambient noise dominates. Speculation, tangents and thinking-aloud outnumber conclusions by an order of magnitude, so retrieval surfaces the wrong material.
- No provenance for a claim. "We agreed X" — in which meeting, by whom, with what caveats?
A pipeline that produces something durable
recording
-> transcript with speaker labels and timestamps
-> extraction pass: decisions | commitments | open questions
-> human confirmation (the step that must not be skipped)
-> durable records, each carrying:
claim, reasoning, alternatives rejected,
owner, date, source timestamp, status
-> indexed for retrieval alongside your other decision recordsThe confirmation step is not optional
Extraction gets tone and hedging wrong in exactly the situations that matter. "We could use Kafka" and "we are using Kafka" are one modal verb apart in the transcript and a quarter of engineering work apart in reality. A decision record generated without a human confirming it is a plausible-sounding fabrication with a timestamp on it, which is worse than no record.
Link the record back to the moment
Every extracted decision should carry the transcript timestamp it came from. When someone disputes a record six months later — and they will — the resolution is thirty seconds of audio rather than an argument about memory. This single field does more for trust in the system than any accuracy improvement.
What not to record
Recording changes what people say. Conversations about performance, hiring, incidents with a blame dimension, or anything a participant would phrase differently on the record should not be captured by default. Announce recording, make opting out real, and set retention deliberately — an indefinite archive of everything anyone said is a liability that grows quietly.
Where this connects to the rest of the system
An extracted decision and an architecture decision record are the same artefact arrived at from different directions. If your team already keeps ADRs, meeting extraction should write into that store rather than beside it — two decision systems is worse than one, because now the reader has to know which to trust.
Frequently Asked Questions
Do I need speaker diarisation?
For decisions, yes. "Who committed to this" is most of the value of a commitment record, and an unattributed commitment is a note, not an owner.
How accurate does transcription need to be?
Less accurate than people assume for extraction, because the extraction pass is working on meaning rather than exact wording. It matters much more for the verbatim quote you attach as provenance.
What about meetings with customers?
Consent and jurisdiction first - recording law varies and two-party consent is not universal. Where you can record, customer conversations are among the highest-value sources of durable product decisions.
References
- A Survey of Context Engineering for Large Language Models — arXiv
- Documenting Architecture Decisions — Michael Nygard / Cognitect
About Jishu Labs
Jishu Labs is a software development company founded in 2016. We build custom software, AI/ML systems, and full-stack web and mobile applications for clients, and we make eight AI tools for software teams.