You're viewing the AI side. See the human side
Vikram Bhalla

Your Meeting Tool Has Never Met You

It only knows what was said. Claude knows what it means for you.

I took a break from writing this Substack for the last couple of weeks because the kids in this country were removing a friction of their own — one of epic proportions. It didn’t feel right trying to write about artificial intelligence while the powers that be displayed so little human intelligence.

Back to regular programming.

I was conducting an AI empowerment workshop for an impact organisation a few days ago, helping their team better equip itself with AI. We were talking about how most of their people are already using AI, and one of their team members brought up a very specific pain point.

“I have 5-6 meetings a day, and it would be impossible for me to keep track of my meeting notes without my Granola app.”

Granola, for those of you who aren’t aware, is a meeting transcription and note-taking app, not unlike Otter.ai, Fireflies, or the built-in meeting functions in Google Meet, MS Teams, or Zoom. What these tools do is fairly straightforward — they record your meeting audio (some of them join your meeting as bots), transcribe it, and then present summaries or key takeaways from those transcripts.

The only problem is that none of these meeting tools actually understand what these meetings are about, because none of them has any context beyond what’s spoken in the meeting.

Our AI agents, on the other hand, now know our context really well, because for the better part of the last few years, we’ve given them our emails, files, challenges, and a remarkable amount of context about our work, roles, and organisations. Sure, Claude and ChatGPT could transcribe audio files you upload, but reliable meeting capture remains awkward inside these tools.

And so most folks, like the team member during that workshop, have found a workaround. They use these third-party “meeting intelligence” tools like Granola to transcribe and summarise their meetings, but then completely disregard the summaries and key takeaways those tools give them, and instead copy-paste the full meeting transcripts into their AI chats or projects. That way, their AI can give them a much richer and more insightful analysis of that meeting, within the broader context.

For me, Mimir already handles that entire workflow automatically — recording the meeting, transcribing it, analysing it in context and producing the final output. But listening to this person’s roundabout manual workflow made me very sad. No one should have to suffer through that.

No sooner had she finished telling us about her frustration around meeting notes than everyone else chimed in too, in complete agreement. Not all of them use Granola; some rely on Zoom’s built-in meeting notes, and one person said they still make notes during meetings with a pen and paper, but then they have a hard time keeping up with the meeting as a result. Almost all of them would eventually end up manually providing the meeting transcript/summary/takeaways to their respective Claudes.

Sure, Granola has a Claude “connector”, but if you want to use that connector, you have to fork out $14 a month to Granola. This is over and above your existing paid Claude subscription, mind you.

Not on my watch.

“What if I could automate the meeting-to-transcript-to-Claude context process for you?” I asked.

She practically jumped out of her seat. “Are you kidding? I would love that!”

That decided it. The weekend was three days away, and I felt confident that I’d have a solution for their team by Monday.

Meetings are an integral — if annoying — part of our work lives, but they remain curiously difficult to integrate into our AI workflows. Plenty of tools will generate a transcript. Some will even connect to Claude for another $14 a month. But none of the tools this team was using would simply place a raw, diarised transcript into a folder for their AI agent to find.

That was the friction.

By Friday, I had a plan in mind for what this solution needed to be, and I also knew this might be something a lot of folks, even outside this organisation, could use.

Here was the shape that solution needed to take.

It would be a discreet menu-bar app that recorded meeting audio without sending a bot into the meeting. It had to work on any and all meeting platforms, from Google Meet to Teams to Zoom. It needed accurate speaker-labelled transcripts, calendar reminders, local file storage and no compulsory monthly subscription.

Enter Deepgram — one of the most accurate transcription APIs currently available. Deepgram is also remarkably generous to new users — as of today, every new account comes with $200 in free API credits. That equates to hundreds of hours of transcription before a user has to pay anything.

I’d never built a macOS menu-bar app before, but my lack of experience stopped being a blocker for building things years ago. I dived in, Claude at my side.

This seemed like the perfect excuse to experiment with Anthropic’s big new Fable model.

I went back and forth with Fable (a breathtaking model, by the way) for about an hour, hashing out every possible detail of the plan so the build itself would be smooth (and maybe even one-shot?).

When I was satisfied with the plan, I pasted it into a new Claude Code session, again with Fable at the helm.

Fable accepted the plan, deployed a small team of sub-agents, while I gave it the classic LLM instruction: “Make no mistakes.”

By the time Claude Code was done with v0.1 of the app, it had been running autonomously for almost 45 minutes, and I was itching to test it out.

Double-clicking the app icon launched the app. Lovely.

The icon bounced twice in the Dock, disappeared, and a tiny circle appeared in my menu bar. Exactly as planned. I clicked “Start recording”.

Nothing happened.

I tried again. Still nothing.

“Claude, recording won’t start. Can you investigate and fix, please?”

Fable quickly identified it as an issue with macOS’ very strict screen-recording permissions settings, and its team of sub-agents fixed the bug quicker than I expected. Suspiciously, I restarted the app. This time, when I clicked “Start recording”, my Mac threw up 2-3 permissions pop-ups. I allowed everything, and the app automatically quit and re-opened.

Then “Start recording” actually started the recording! A little pill-shaped bubble floated on the top-right of my screen, showing me the recording in progress. I spoke some random gibberish at my computer for a whole minute before clicking the “Stop” button on the floating pill. The pill changed to a “Transcribing” state and the little menu bar icon turned into a diamond. So subtle. So sick.

It didn’t take more than a few seconds for the transcription to complete, and the Markdown text document appeared in the test folder on my Desktop, my minute-long gibberish captured perfectly.

I then tested the app with a YouTube clip of a Conan O’Brien podcast episode, and again the transcript identified the different speakers (as “Speaker 0”, “Speaker 1”, “Speaker 2”, etc.) and transcribed their speech accurately.

Alright, eureka! The app could do the main thing I needed it to. From this point on, everything else would be a bonus.

Luckily, everything else went pretty smoothly, for the most part. The only significant speed bump was Google Calendar. Because Calendar access requires Google verification and review, which could take days or even weeks, I temporarily added the client’s team as approved test users while the public review continued.

Monday morning, I shared v1.0 of the app with a VP at the company — the most AI-forward member of the team — to see if the app would work for him, and get his initial feedback before deploying it to the others.

He reported back almost immediately with the same damn macOS permissions bug. I took the feedback back into Claude Code and demanded that Fable “fix it once and for all.”

A few minutes later, Fable delivered v1.0.1. This one worked flawlessly. With the VP’s blessing, I shared it with his team.

By the next day, that VP had already connected the Transcripts folder to his Claude Cowork workflow. Before a meeting, Claude could read the previous transcript alongside recent emails and remind him what was still unresolved. Afterwards, it could pull out decisions, commitments, and follow-ups, then enrich them with relevant context from his email and Google Drive. He no longer had to carry anything from one tool to another. And he could focus on the meetings instead of frantically documenting them.

I’ve now built a similar workflow for myself on this same client engagement. Every morning, Cowork checks for new transcripts, updates a running “Where_things_stand.md” document, and cross-references it against my Gantt chart of the project timeline. If a workstream is slipping, the system flags it early on. This too is barely scratching the surface, but you get the drift.

Consent, of course, remains the most critical and human part of this system. Everyone on a call should know if they’re being recorded. The app follows a local-first setup: the recordings and finished transcripts live on the user’s Mac, while the meeting audio only goes to Deepgram for transcription. The app requires no user account, has no cloud servers of its own, and automatically deletes recordings after seven days (which is configurable by the user).

Watching their team adopt it so quickly convinced me that the problem extended well beyond one organisation. So I polished the client build into a public macOS app and named it Minutehand. It’s now available to anyone for whom this particular friction sounds familiar, with a one-time introductory price, no unnecessary subscription, and a lifetime licence covering two Macs. Calendar reminders are temporarily limited to approved testers while Google completes its verification process, but the rest of the app is ready to use.

I’m just glad nobody needs to play courier between their meetings and Claude. That time is better spent doing literally anything else, like hugging your dog.

Read on Substack ↗

Your Meeting Tool Has Never Met You

It only knows what was said. Claude knows what it means for you.

I took a break from writing this Substack for the last couple of weeks because the kids in this country were removing a friction of their own — one of epic proportions. It didn’t feel right trying to write about artificial intelligence while the powers that be displayed so little human intelligence.

Back to regular programming.

I was conducting an AI empowerment workshop for an impact organisation a few days ago, helping their team better equip itself with AI. We were talking about how most of their people are already using AI, and one of their team members brought up a very specific pain point.

“I have 5-6 meetings a day, and it would be impossible for me to keep track of my meeting notes without my Granola app.”

Granola, for those of you who aren’t aware, is a meeting transcription and note-taking app, not unlike Otter.ai, Fireflies, or the built-in meeting functions in Google Meet, MS Teams, or Zoom. What these tools do is fairly straightforward — they record your meeting audio (some of them join your meeting as bots), transcribe it, and then present summaries or key takeaways from those transcripts.

The only problem is that none of these meeting tools actually understand what these meetings are about, because none of them has any context beyond what’s spoken in the meeting.

Our AI agents, on the other hand, now know our context really well, because for the better part of the last few years, we’ve given them our emails, files, challenges, and a remarkable amount of context about our work, roles, and organisations. Sure, Claude and ChatGPT could transcribe audio files you upload, but reliable meeting capture remains awkward inside these tools.

And so most folks, like the team member during that workshop, have found a workaround. They use these third-party “meeting intelligence” tools like Granola to transcribe and summarise their meetings, but then completely disregard the summaries and key takeaways those tools give them, and instead copy-paste the full meeting transcripts into their AI chats or projects. That way, their AI can give them a much richer and more insightful analysis of that meeting, within the broader context.

For me, Mimir already handles that entire workflow automatically — recording the meeting, transcribing it, analysing it in context and producing the final output. But listening to this person’s roundabout manual workflow made me very sad. No one should have to suffer through that.

No sooner had she finished telling us about her frustration around meeting notes than everyone else chimed in too, in complete agreement. Not all of them use Granola; some rely on Zoom’s built-in meeting notes, and one person said they still make notes during meetings with a pen and paper, but then they have a hard time keeping up with the meeting as a result. Almost all of them would eventually end up manually providing the meeting transcript/summary/takeaways to their respective Claudes.

Sure, Granola has a Claude “connector”, but if you want to use that connector, you have to fork out $14 a month to Granola. This is over and above your existing paid Claude subscription, mind you.

Not on my watch.

“What if I could automate the meeting-to-transcript-to-Claude context process for you?” I asked.

She practically jumped out of her seat. “Are you kidding? I would love that!”

That decided it. The weekend was three days away, and I felt confident that I’d have a solution for their team by Monday.

Meetings are an integral — if annoying — part of our work lives, but they remain curiously difficult to integrate into our AI workflows. Plenty of tools will generate a transcript. Some will even connect to Claude for another $14 a month. But none of the tools this team was using would simply place a raw, diarised transcript into a folder for their AI agent to find.

That was the friction.

By Friday, I had a plan in mind for what this solution needed to be, and I also knew this might be something a lot of folks, even outside this organisation, could use.

Here was the shape that solution needed to take.

It would be a discreet menu-bar app that recorded meeting audio without sending a bot into the meeting. It had to work on any and all meeting platforms, from Google Meet to Teams to Zoom. It needed accurate speaker-labelled transcripts, calendar reminders, local file storage and no compulsory monthly subscription.

Enter Deepgram — one of the most accurate transcription APIs currently available. Deepgram is also remarkably generous to new users — as of today, every new account comes with $200 in free API credits. That equates to hundreds of hours of transcription before a user has to pay anything.

I’d never built a macOS menu-bar app before, but my lack of experience stopped being a blocker for building things years ago. I dived in, Claude at my side.

This seemed like the perfect excuse to experiment with Anthropic’s big new Fable model.

I went back and forth with Fable (a breathtaking model, by the way) for about an hour, hashing out every possible detail of the plan so the build itself would be smooth (and maybe even one-shot?).

When I was satisfied with the plan, I pasted it into a new Claude Code session, again with Fable at the helm.

Fable accepted the plan, deployed a small team of sub-agents, while I gave it the classic LLM instruction: “Make no mistakes.”

By the time Claude Code was done with v0.1 of the app, it had been running autonomously for almost 45 minutes, and I was itching to test it out.

Double-clicking the app icon launched the app. Lovely.

The icon bounced twice in the Dock, disappeared, and a tiny circle appeared in my menu bar. Exactly as planned. I clicked “Start recording”.

Nothing happened.

I tried again. Still nothing.

“Claude, recording won’t start. Can you investigate and fix, please?”

Fable quickly identified it as an issue with macOS’ very strict screen-recording permissions settings, and its team of sub-agents fixed the bug quicker than I expected. Suspiciously, I restarted the app. This time, when I clicked “Start recording”, my Mac threw up 2-3 permissions pop-ups. I allowed everything, and the app automatically quit and re-opened.

Then “Start recording” actually started the recording! A little pill-shaped bubble floated on the top-right of my screen, showing me the recording in progress. I spoke some random gibberish at my computer for a whole minute before clicking the “Stop” button on the floating pill. The pill changed to a “Transcribing” state and the little menu bar icon turned into a diamond. So subtle. So sick.

It didn’t take more than a few seconds for the transcription to complete, and the Markdown text document appeared in the test folder on my Desktop, my minute-long gibberish captured perfectly.

I then tested the app with a YouTube clip of a Conan O’Brien podcast episode, and again the transcript identified the different speakers (as “Speaker 0”, “Speaker 1”, “Speaker 2”, etc.) and transcribed their speech accurately.

Alright, eureka! The app could do the main thing I needed it to. From this point on, everything else would be a bonus.

Luckily, everything else went pretty smoothly, for the most part. The only significant speed bump was Google Calendar. Because Calendar access requires Google verification and review, which could take days or even weeks, I temporarily added the client’s team as approved test users while the public review continued.

Monday morning, I shared v1.0 of the app with a VP at the company — the most AI-forward member of the team — to see if the app would work for him, and get his initial feedback before deploying it to the others.

He reported back almost immediately with the same damn macOS permissions bug. I took the feedback back into Claude Code and demanded that Fable “fix it once and for all.”

A few minutes later, Fable delivered v1.0.1. This one worked flawlessly. With the VP’s blessing, I shared it with his team.

By the next day, that VP had already connected the Transcripts folder to his Claude Cowork workflow. Before a meeting, Claude could read the previous transcript alongside recent emails and remind him what was still unresolved. Afterwards, it could pull out decisions, commitments, and follow-ups, then enrich them with relevant context from his email and Google Drive. He no longer had to carry anything from one tool to another. And he could focus on the meetings instead of frantically documenting them.

I’ve now built a similar workflow for myself on this same client engagement. Every morning, Cowork checks for new transcripts, updates a running “Where_things_stand.md” document, and cross-references it against my Gantt chart of the project timeline. If a workstream is slipping, the system flags it early on. This too is barely scratching the surface, but you get the drift.

Consent, of course, remains the most critical and human part of this system. Everyone on a call should know if they’re being recorded. The app follows a local-first setup: the recordings and finished transcripts live on the user’s Mac, while the meeting audio only goes to Deepgram for transcription. The app requires no user account, has no cloud servers of its own, and automatically deletes recordings after seven days (which is configurable by the user).

Watching their team adopt it so quickly convinced me that the problem extended well beyond one organisation. So I polished the client build into a public macOS app and named it Minutehand. It’s now available to anyone for whom this particular friction sounds familiar, with a one-time introductory price, no unnecessary subscription, and a lifetime licence covering two Macs. Calendar reminders are temporarily limited to approved testers while Google completes its verification process, but the rest of the app is ready to use.

I’m just glad nobody needs to play courier between their meetings and Claude. That time is better spent doing literally anything else, like hugging your dog.

Read on Substack ↗