A teardown of the exact workflow for turning messy meeting notes into a client-ready brief — including the three failure modes that aren't in any tutorial.
The worst brief I ever sent a client was written on a full recording, a complete transcript, and a capable AI model. It was also the wrong brief — coherent on the surface, wrong about what the client actually needed, smooth enough that I didn’t catch it before it went out.
The failure wasn’t the tools. It was the pipeline. I had automated too far in the wrong direction and skipped the one step that makes the difference between a brief that helps the client think and one that just proves you were in the room.
This is the teardown of the pipeline I now run — the real steps, in order, with the three places it breaks and what I do about each one. No aspirational framing. This is what actually runs on real client work.
Before the steps: let’s be honest about what AI cannot do in this workflow, because every tutorial skips this part.
AI cannot tell you which moment in the meeting was the one that mattered. It cannot distinguish between the thing a client said and the thing a client meant. It cannot hear the pause before an answer, or the way a question got deflected. Those signals are yours. They live in the notes you take during the meeting, not in the transcript after it.
So the first constraint of this pipeline is architectural: AI operates on what you bring to it, and what you bring to it is the output of your own perception in the room. Automate the transformation of good input, and you get good output. Use AI to rescue bad input — thin notes, no context, a raw transcript with no human annotation — and you get a plausible brief that misrepresents the meeting. I’ve generated both. Only one is useful.
During the meeting I take sparse typed notes. Not a transcript attempt; not bullet points of everything said. I am looking for three specific things, and I tag them inline:
[D] — a decision, even a tentative one[T] — a tension that didn’t resolve (“they want X but also said Y”)[Q] — a question they asked that nobody answered, or that got buriedNothing else gets tagged. The discipline is deliberate. If I try to capture everything, I am transcribing, and transcription in the room trades attention for coverage — a bad trade. These three tags take fifteen seconds each and cost me nothing in the room. By the end of a ninety-minute meeting I have, typically, four to eight of them. That is the real input to everything that follows.
After the meeting, I transfer the annotated notes to Obsidian and run them through a single compression step. The instruction I use:
Here are annotated notes from a client meeting. Tags: [D] = decision, [T] = tension, [Q] = unanswered question.
Produce a structured outline only — no prose. Three sections:
1. Decisions taken or effectively taken (list the decision and the confidence level: firm / provisional / tacit)
2. Tensions still open (list each tension as a genuine either/or)
3. Questions nobody answered (verbatim or close to it)
Do not interpret. Do not add context I haven't provided. If you are uncertain whether something is a decision or a tension, put it in both.
The “do not interpret” instruction is the load-bearing one. Interpretation is my job, for reasons the third step makes obvious. What I need from the compression stage is shape — a clean structure that makes the content of the meeting scannable and argument-ready. I do not need the model’s read on what the client was really saying. That is the one thing it reliably gets wrong.
Now I write the brief. By hand. From the compressed outline.
The brief has three sections that map to the three tag types. This is not a coincidence; I designed the tags to produce the sections. Decisions become the “Where we landed” section. Tensions become the “Open questions” section — reframed as actual questions, not as AI-generated diplomatic statements. Unanswered questions become “Next conversation starters.”
The writing at this stage is genuinely mine, for the same reason the first draft of a recommendation has to be mine: the brief is a client-facing document, and anything in it represents my understanding of what happened. If I let the model write the prose, I end up editing a plausible version of events that may or may not be what I actually think. It looks finished. The client can tell when it doesn’t quite capture the room — even when they can’t articulate why. They were in the room too.
The brief is not a transcript in paragraph form. It is a record of what you understood, and what you understood is yours to write.
Total time from meeting end to brief sent: typically thirty to forty-five minutes for a ninety-minute meeting. The meeting-notes-to-brief step used to take two hours and required re-listening to recordings. That re-listening is what I cut — not the writing.
Every version of this pipeline I’ve run has broken in the same three places. Knowing them in advance is the only thing that stops me from being surprised by them.
Break one: the transcript trap. The most common failure is starting from a full transcript instead of annotated notes. Transcripts are comprehensive and useless in the same way that scraped inputs were useless in the research workflow — they are a complete record of noise alongside signal, with no way to distinguish which is which. When I feed a transcript to the compression step, the model has to guess which moments mattered. It guesses by finding what was said most, or most emphatically, or most clearly — none of which is a reliable proxy for what the client actually cared about. My three-tag annotation is precisely the signal layer that a transcript cannot provide. The transcript is not a substitute for the notes; it’s an alternative to having paid attention.
Break two: the confidence-laundering problem. The compression step has a failure mode I now guard against explicitly: the model will produce confident, clean prose about decisions that were, in the room, provisional, tentative, or contested. A client who said “I think we’re leaning toward option B” becomes, in an AI-generated brief, “The client has chosen option B.” The word “think” disappears in summarisation. The label “provisional” never appears because the model doesn’t know what confident and provisional look like from the inside of a live business conversation.
This is why the compression instruction asks for confidence levels explicitly — “firm / provisional / tacit” — and why I read the output against my own memory of the room before the brief goes anywhere. The model cannot know the difference. You can. Use that.
Break three: the clean-prose problem. The final failure mode is the subtlest. A well-written brief smooths everything — including the tensions that should stay sharp. A tension that read as “they want weekly granularity but resist the data governance required to produce it” becomes, in model-generated prose, something like “the team is working to align on reporting cadence.” That sentence is not wrong. It is also not useful. The client cannot act on it. The tension is what they need to sit with, and smooth prose dissolves it.
My rule: if a tension in the “Open questions” section doesn’t feel slightly uncomfortable to read, I have written it wrong. Discomfort is the signal that the brief is honest about the actual problem — which is the only reason to send it.
Obsidian for the notes and the compression step. One capable AI model for the compression. A template in Obsidian with the three sections pre-built so the filling step has a consistent frame to work into. No recording tools, no auto-transcription, no meeting-notes bots — they optimise for capture, and capture is not the bottleneck. Annotation in the room is. The tools I run are linked where an affiliate program exists; I only list what’s in my actual stack.
If you want the exact template — the tag conventions, the compression prompt, and the three-section brief frame with the confidence-level scaffold built in — it’s packaged:
→ The Meeting-to-Deliverable template — $49. Drop it into Obsidian and run your next client meeting through it. (Shipping to the newsletter list first; sign up below.)
Disclosure: Some links on this site are affiliate links — if you buy through them I may earn a commission, at no cost to you. I only recommend tools I actually run. See the brief you just read: the failures are in here too, because that’s what “actually run” means.
The brief I mentioned at the top — the wrong one, sent on a full recording and a transcript — was wrong for a specific reason. I had an accurate record of everything that was said. I had no record of what I’d noticed. The difference between those two things is the annotation step, which takes fifteen seconds per tag in the room and cannot be recovered after the fact. That’s the whole lesson, if you need it in one sentence.
Next in Workflows → My full consulting AI stack, and what each tool actually costs.
The exact Obsidian template and the full prompt chain — the structured intake note, the contrast prompt, and the provocation checklist. Drop it into your vault and run your next prospect through it in forty minutes.
No schedule. No filler. No sponsored placements. A new build goes out only when it's worth your ten minutes — usually every 2–4 weeks.
"I'll only send you something I would have written even if nobody paid me to. The day that stops, the newsletter stops."