Meeting MOM · Audio to document

Everything that matters gets said out loud, then evaporates

Briqhaus meetings decide who owes what, by when, and at what cost. All of it gets said in the room, and none of it survived the meeting. A week later the record was whoever had the best memory.

These run four and five hours. The old fix was to nominate a note-taker, but we are a startup: the person typing was always someone who also needed to talk. It cost a participant, it cost the pace, and the notes still were not reliable.

It puts the person with the best recall in charge of the truth

So the product records the meeting, transcribes it, and hands back minutes with every action item pinned to the person who owes the work. It runs on 15 to 40 meetings a week now.

A working MVP existed by the time it reached me. I designed everything the user touches from there: the capture screen, the wait, the document, the review, and the register people chase work from. I built the front end for all of it. Three weeks to the first client meeting, two people: me and one backend engineer.

Five screens, one meeting

Scroll the diagram sideways for the rest of the pipeline. Everything before the review step is machine work that can be wrong. The document does not leave the building until the one human step has happened.

Meeting AI as it ships: record, transcribe, assign, send

Attendees go in first, before anyone hits record. It looks like friction on a form and it does two jobs: the count tells the transcription API how many voices to separate, and those names are the only thing an action item can be assigned to. Ask afterwards and the document is already wrong.

New meeting dialog: title, agenda, and the attendee list — Who is in the room, before recording starts. The agenda is optional and makes the minutes better organised, because the model gets some structure to work from.

The wait is named, not hidden. Transcription and summarising take real time and come back different each run, so the page says which of seven steps it is on rather than spinning. You can close it: the minutes arrive by email.

A meeting mid-pipeline, showing step 3 of 7, transcribing — Step 3 of 7. The work is slow, so the wait is named instead of hidden, and you can close the page because the minutes arrive by email.

It comes back as a document, not a wall of transcript: a summary, numbered sections, decisions, concerns, and the questions nobody answered. It carries an AI disclaimer at the top and a link to the transcript for anything you plan to rely on.

The generated minutes, with numbered sections and a contents rail — The minutes as they ship, with the AI disclaimer at the top and a link to the transcript for anything you plan to rely on.

Then it leaves, as a PDF, by email, and onto the deal record in the CRM. Every commitment from every meeting also collects in one register, which is the screen people actually chase work from.

Action register listing every action item across all meetings with owner and deadline — The action register. Minutes are a document per meeting. This is the thing people actually chase work from.

And when the audio loses, it says so. A failed pipeline is a state with a retry on it, because an eighteen minute call that produced nothing is worth saying out loud.

A meeting whose pipeline failed, with a retry available — Sometimes the audio simply loses. The failure is a state with a retry on it rather than a silence, because an eighteen minute call that produced nothing is worth saying out loud.

A third of action items named the wrong person

The screens were the easy half. I mapped every task from opening a meeting to sending the document, then sat with people while they ran real meetings on it. The feature the whole product was sold on, action items pinned to the person who owes the work, was the one getting it wrong. About a third of them carried the wrong name.

That matters more than a bug count. An action item is an assignment, not a note, so a wrong name is an accusation with a deadline on it. Clients read these documents, and a summary that is visibly wrong costs trust in the platform rather than in the feature.

I assumed the model was mishearing. It was not.

Long meetings were recorded and transcribed in twenty-nine minute segments, deliberately: a segment can start transcribing while the meeting is still running, so a two-hour call is not a two-hour wait at the end. But the transcription API labels speakers per call. Speaker 0 in one segment is not Speaker 0 in the next, and nothing carries between them. Our data model allowed one label per person, so it could not hold "Priya is Speaker 0 early and Speaker 2 later." It kept one, and the other became a wrong name on somebody's task.

Scroll the diagram sideways for call 2, where the numbers change. The transcription API numbers voices per call, not per person, so the seam resets everyone to zero. Segmenting the recording was a safety decision that leaked into transcription, and this is where the wrong names came from.

Two fixes, neither of them a better prompt

Transcribe the whole meeting in one call

Instead of Keeping per-segment transcription because recording was already segmented

Segmenting bought two things, crash safety and a shorter wait. Only the first is worth the wrong names. Recording still uploads in pieces, but they are joined and transcribed once, and the wait moves to the end where the page names it.

After Speaker identity holds across a two-hour meeting. Built, not yet rolled into Rails.

Owners became real records, correctable one at a time

Instead of Regenerating the whole document to fix a name

The owner became an editable field on the action item instead of words inside the generated document, so a correction is one dropdown and a save. Nothing re-transcribes, nothing regenerates, and the corrected name flows straight through to the register everyone chases work from.

Action items with the model's guessed owners: Rahul Mehta twice and one unassigned — Before. The model put Rahul on two items and refused to guess the third. Two of those three are wrong, and this is what a generated document honestly looks like.

The same action items after a person reassigned two owners and saved — After. Two corrections and a save, no regeneration. In the rebuild this goes further: the model's first guess is kept beside the correction, so attribution becomes a number you can count.

After A wrong name becomes one dropdown and a save, instead of a regenerated document.

The model drafts, a person signs off

The model drafts. A person signs off.

Instead of Sending the generated summary straight to attendees

A summary that reaches a client with the wrong name does more damage than no summary, because it arrives looking official. So it stops at a draft. Whoever ran the meeting walks the action items, confirms the owner on each one, adds a name that was never in the attendee list if they need to, and sends it.

What changed people's minds was seeing what the model wrote before anyone checked it.

What the step really buys is credibility. When this document goes to a client, somebody knows it is right before it leaves.

After Nothing has gone to a client with a name nobody checked.

People resented the sign-off at first. I kept it

Fifteen to forty meetings a week

It is the default for anything client-facing at Briqhaus, run by whoever chaired the meeting, and nobody waits on the document.

The shipped version is Rails. The attribution fix is built and not yet deployed: I rebuilt the front end end to end to prove the design, and the plan is to roll it into Rails rather than move clients onto a second product.

The part I would defend: nobody takes notes any more, so nobody sits out of the conversation to keep the record.

What it still cannot do

Separating voices will never be reliable, so the human check stays. That is right, rather than a compromise.
Reviewing is still work, and on a busy day it is the thing that slips.
Attribution starts from zero every meeting, even for the six people in most of these calls. Persistent voice profiles are next.