What "without a bot" actually means
"Bot-free" describes where a tool gets its audio, not how it looks. A bot is a separate participant that joins the call from a link, takes a seat in the roster and records the meeting on the platform's side. A bot-free tool obtains the meeting another way: it reads the platform's live captions in the browser, pulls data through an official API, or listens to the sound on your own computer.
There are exactly three approaches, and the difference between them is not cosmetic. It determines which platforms the tool works on at all, what ends up in the transcript, who can see that recording is happening, and what breaks first.
Through 2026 the platforms began closing their doors to third-party bots.
Google Meet has, since March, routed them into a separate queue as a
"potential risk", denied by default. Microsoft Teams went further:
administrators get a switch for external meeting bots, defaulting to
RequireApprovalWhenDetected — Teams itself identifies third-party
notetakers and sends them to the lobby. The older CAPTCHA controls were retired
in late July, and the new policy has been rolling out since August 2026.
The trigger was a cluster of lawsuits against Otter.ai, after which third-party
notetakers landed on every security team's risk register.
The practical consequence: an approach that worked a year ago may now stop at your own employer's policy — and that is not a product defect, it is the architecture's limit.
All three at a glance
1. BROWSER EXTENSION 2. PLATFORM API / BOT 3. OS AUDIO
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ the meeting tab │ │ the conference │ │ your computer │
│ │ │ │ │ │
│ ↓ captions │ │ ↓ bot joins │ │ ↓ audio output │
│ read from DOM │ │ or API │ │ + microphone │
└──────────────────┘ └──────────────────┘ └──────────────────┘
Caption TEXT AUDIO + roster AUDIO of
(already rewritten) (authoritative) everything heard
Works only where Works only on supported Works anywhere
captions exist and platforms, and where there is sound
the tab stays open IT allows it and a desktop
Mechanism 1. Browser extension
The extension lives in the meeting tab and reads the captions the platform itself draws. It usually has no speech recognition of its own: the text is already there, and the job is to lift it out of the page markup and assemble a transcript.
What it gets
Ready-made lines of text and, with luck, speaker labels — the platform prints them next to each phrase. Installation takes a minute, nothing is installed into the operating system, and no extra participant appears in the meeting.
What it does not get
Audio. Everything else follows from that. Captions are not a transcript but an assistive text: platforms shorten long phrases, paraphrase and drop punctuation. Whatever was lost when they were generated is lost for good — there is nothing to re-listen to.
Reliable speaker attribution. Labels appear on screen, but they are not exposed as a stable machine-readable field: parsing them rests on class names and visual heuristics. Which leads to the second consequence — any interface update on the platform breaks the parser, and until it is fixed the tool quietly writes nonsense, or nothing.
Where it stops
The browser only: a meeting in the Zoom or Teams desktop app is out of reach. The tab has to stay open. Captions must be switched on — and switching them on is visible to everyone, which some companies forbid outright. None of this helps for a call in a messenger or a meeting held in a room.
When it beats the others
When you already work in the browser, need an approximate written trace of the conversation, and installing software is impossible or unwelcome.
Mechanism 2. Official platform API, or a bot
Here the tool works with the platform as a partner: it either sends in a bot participant or pulls data through an official interface. This is the only mechanism with authoritative information about people — the platform knows exactly who spoke, rather than "the second voice".
What it gets
A platform-grade transcript and recording, a roster with real names, join and leave times, sometimes cloud recordings held by the platform. None of it depends on your computer, which can be switched off entirely.
What it does not get
Anything outside the supported platforms. The list is finite, and shorter than it looks: Zoom, Meet, Teams — then nothing. A call in Telegram or Discord, or a room with no conference at all, simply does not fit this mechanism.
A separate awkwardness is that the official interfaces are worse than generally assumed. The Meet Media API is limited to selected beta users. Zoom requires real-time streams to be enabled at account level plus a registered Marketplace app. Teams, through the Graph API, exposes a transcript after the meeting, with no live stream. So "official API" often turns out to be the same bot participant after all.
Where it stops
At the administrator. A bot is visible to everyone and has to be let in — and in 2026 that is exactly where things halt: Meet holds third-party bots in a screening queue, and since August Teams can send them to the lobby automatically. The decision belongs to the security team, not to you.
When it beats the others
When you are inside a corporate perimeter on a supported platform, your vendor is approved by IT, and you specifically need participant names — for minutes that will go into external correspondence, say, or for hiring, where which interviewer asked what actually matters.
Mechanism 3. Operating-system audio capture
An application on your computer listens to two streams: the system's audio output (the other person's voice — everything you hear) and the microphone (you). The platform plays no part in the scheme: to the application there is no difference between Zoom, Discord and a voice message.
What it gets
Real audio rather than a paraphrase. Which brings its own speech recognition, punctuation, and the ability to re-listen to a disputed passage. And an unambiguous split between sides: the microphone is you, the system audio is the other party — there is nothing to guess. It works on any platform, including those a bot cannot be invited to, and in a room where there is no conference at all.
What it does not get
The names of individual participants. This is the main limitation and it is an honest one: on the far side of the wire there is a single stream of sound. The mechanism separates you from the other party, but not Anna from Boris. On a two-person call that makes no difference; in a meeting of eight the transcript will say "the other party", not "the head of sales".
Anything without your computer. A closed laptop means no recording. A meeting you did not attend cannot be reconstructed this way.
Where it stops
On macOS, system audio is only released through the Screen Recording permission. That is how the operating system works: an application is given no other channel to the audio output. The permission sounds more alarming than it is, but it has to be granted, and without it you will hear only yourself. On Windows there is no such step — system audio is captured without a separate permission, and the microphone is enough.
A desktop is also required: the mechanism does not work on a phone or in a web version.
When it beats the others
When the platform is not supported by bots, when IT will not admit them, when the meeting is in person, or when you simply prefer not to announce recording as a third entry in the roster.
Side by side
| Extension | API / bot | OS audio | |
|---|---|---|---|
| Source | Platform captions | Platform data | Real audio |
| Audio available | No | Usually yes | Yes |
| Participant names | Unreliable | Yes, authoritative | Only "me / them" |
| Platforms | Browser only | Closed list | Any |
| In-person meeting | No | No | Yes |
| Visible to participants | Captions are on | Yes, a participant | No |
| Depends on platform IT policy | Partly | Entirely | No |
| Works without your computer | No | Yes | No |
| What breaks it | A markup update | An admin policy | A permission not granted |
Choosing in a minute
Choose by what is impossible in your situation, not by a feature list.
Mechanism 2 — API or bot. If the minutes must state who said what and there are more than two people, no other mechanism will give you that. Just check that your vendor is approved by your security team — otherwise the bot stays in the lobby and you find out at the start of the meeting.
Mechanism 3 — OS audio. A platform policy stops a participant, not the sound in your headphones. The same applies when a bot would technically be admitted but you would rather not announce recording as a separate line in the roster.
Mechanism 3 — OS audio. The only one that does not know which application is playing the sound. A call in a messenger, a conversation in a gaming voice channel, a meeting in a room with no conference — all the same to it.
Mechanism 1 — extension. If a corporate laptop forbids installing applications and meetings happen in the browser anyway, this is the only working option. Remember the price: the text will be approximate, and there will be nothing to re-listen to.
What each one cannot do, in short
"Meeting notes without a bot" — followed by a feature list identical across eight products in a row
"Where do you get the audio from?" The answer to that one question decides everything else — and it is almost never on the product page
Everything follows from the audio source: whether there is a recording at all, where speaker names come from, which platforms it works on, who can see the recording, and what will break at the next update. A feature list shows none of that — there everyone has "AI summaries, action items, integrations". Two products with identical capability pages can behave in opposite ways once IT switches on bot blocking, or once the meeting moves to a messenger.
- An extension gives no audio, no reliable speaker attribution, and does not survive a markup update on the platform.
- An API or bot does not work outside the supported platforms, is useless for an in-person meeting, and depends on an administrator's decision.
- OS audio cannot tell participants apart by name, does not work without your computer, and needs the Screen Recording permission on macOS.
Where Whisperer sits
We use the third mechanism, and so we inherit both its strength and its price.
The client listens to system audio and the microphone separately, which is where the [Me] and [Other party] labels in the transcript come from. There is no integration with video services by design: the app connects no bots, joins no call as a participant and asks for no invite link. Which is why we have no list of supported platforms — anything audible through the speakers works.
The price, stated plainly: on macOS the Screen Recording permission is required, without which the other party is inaudible — that is how the operating system releases system audio. On Windows there is no such step; the microphone is enough. And we do not know participant names: in a meeting of eight the transcript will say "the other party".
For conversations that should not be stored at all there is no-logs mode: the transcript exists only in memory during the meeting and is deleted when it ends.
Frequently asked questions
Will participants see that I am recording?
With OS audio capture nothing appears in the roster — the platform cannot see the recording application. That is the technical side; the legal side is separate. Requirements for announcing a recording vary by country and by company, and that question has to be settled independently of which tool you pick.
Why does macOS ask for Screen Recording just for audio?
That is how macOS is built: an application reaches the system audio output through the same mechanism as screen content. There is no way around it, and any tool doing OS audio capture will ask for exactly the same. On Windows system audio is available without a separate permission.
Can OS audio capture replace a bot in a large meeting?
Partly. It will capture the content in full, but not the names. If your minutes have to attribute statements to individuals, you need the second mechanism or manual attribution afterwards.
What if my employer blocks AI notetakers?
Blocking on the platform side stops a bot participant — that is, the second mechanism. An extension and OS audio capture will technically keep working. But such a ban usually concerns recording conversations rather than a particular method, and technical possibility does not override an internal rule.
Can I transcribe a meeting that has already happened?
Only if a recording file survived — and then it is not a job for the three mechanisms above but ordinary transcription of existing audio. None of them can reconstruct a conversation whose sound was never captured anywhere.
What to do next
Pick the mechanism by its limitation rather than its promises: if you need names, take a bot and clear it with your security team in advance; if meetings drift into messengers or happen in person, take audio capture; if installing software is impossible, an extension and its approximate text is what remains.
If you fall into the second group, one call is enough to test it: create an account, grant the permissions and record your next meeting — the free minutes are enough to see what a transcript with separated sides looks like. After that it is clear whether this is your approach or not.