A meeting recorder without a bot sounds vaguely like a magic trick the first time you see one: the app sits in your Mac's menu bar, nothing joins your Zoom call, no "Recording" pill appears for anyone else — and afterwards you have a transcript of both sides of the conversation. No magic is involved, and understanding the actual mechanics is the best way to evaluate these tools, because the engineering choices map directly onto the privacy properties. Here's how botless capture works, from someone who builds one (Speechmark — bias declared).
Two architectures for hearing a meeting
Every meeting-notes tool has to solve the same problem: get the audio. There are exactly two places to get it.
In the meeting (the bot). A cloud service can't hear your call, so it sends a client into it: a headless participant that joins the Zoom/Meet/Teams session like any attendee and streams what it hears back to the vendor's servers. That's why Otter's Notetaker shows up in your participant list — joining is how a cloud service gets in. Bots are platform-blessed, can capture full video, and work no matter what device the user is on. They're also visible, occasionally awkward in front of clients, removable by any participant, and increasingly blocked outright — Zoom admins can ban them org-wide, and Microsoft Teams is moving to block external AI notetaker bots automatically from August 2026. We cover the user-facing side in our piece on bot-free Otter alternatives.
On the device (botless). From your Mac's point of view, a meeting is just two audio streams: the microphone (you) and the system audio output (everyone else, coming out of your speakers or headphones). Capture both locally and you've recorded the meeting without touching the meeting platform at all. Zoom doesn't know, can't show anything, and can't block anything — the recording happens below it, at the operating-system level. This is how Granola, Speechmark, BB Recorder, and OpenWhispr all work.
The mic half is trivial — standard audio APIs, same as any voice memo app. The interesting half is system audio, which macOS spent years making hard.
A short history of capturing system audio on macOS
Era 1: virtual audio drivers. For a long time the only way was to install a virtual audio device — Soundflower, later BlackHole, or commercial tools like Loopback — and route the Mac's output through it so an app could read the stream back. It worked, but it meant installing an audio driver, fiddling with output routing, and breaking whenever the user changed audio devices mid-call. Fine for audio engineers; hostile for a note-taking app's onboarding.
Era 2: ScreenCaptureKit (macOS 13). Apple's modern screen-recording framework grew audio capture in macOS 13: ask for a display capture stream, set capturesAudio, and you get the system mix without any driver. This is what several recorders use today — BB Recorder, for one, says it captures "system audio directly through macOS ScreenCaptureKit". The wrinkle is that it's a screen-capture API being used for audio, with permission framing to match.
Era 3: Core Audio process taps (macOS 14.2). With macOS 14.2, Core Audio finally shipped a first-class API for exactly this job: describe what you want with CATapDescription, call AudioHardwareCreateProcessTap, and wrap the tap in an aggregate device you can read like any input. A tap can target specific processes or the whole system mix — excluding your own app's output, so you don't record yourself. No driver, no screen-capture machinery, real-time and format-stable.
This is what Speechmark uses: a global process tap (our own audio excluded) feeding the same on-device pipeline as the microphone. It's also why the app requires macOS 14.2+ — the minimum version is the API, not vanity.
Permissions, and who gets told
Botless capture is gated by the OS, not the meeting platform. macOS requires the user to grant microphone access and system-audio recording — the latter lives in System Settings under Privacy & Security → Screen & System Audio Recording. You get asked once, explicitly.
The other participants are not told. Nothing appears in the call, and no API reports that audio left the speakers into a file. That asymmetry is worth sitting with: it's precisely what makes botless recording robust and unobtrusive, and it's also why the consent burden shifts to you. Recording-consent law varies — some US states and many countries require all parties to consent, others just one — and none of it is a software feature. Disclose that you're recording when the law requires it, and consider disclosing even when it doesn't; the recorder being invisible doesn't make the recording less real.
The part vendors mumble: captured locally ≠ processed locally
Here's the trap in the phrase "no bot": it describes the capture, and says nothing about what happens next. Several cloud services now offer bot-free modes that capture audio on your device — and then upload it anyway. Fireflies is at least candid about its desktop mode: "your computer captures the audio locally and sends it to Fireflies for processing". Otter's desktop app likewise records bot-free into Otter's cloud account. The bot is gone; the data flow is unchanged.
So when a tool says "no bot," ask three more questions:
- Where does transcription run? On the device (Whisper/Parakeet-class models run fine on Apple silicon) or on the vendor's servers?
- Where do the audio, transcript, and notes live afterwards? Local files you can point at, or an account in someone's cloud?
- What's the training policy? If content reaches vendor infrastructure, does it improve their models by default?
Fully local tools make those questions boring: transcription on-device, files on disk, nothing to train on. That's the architecture Speechmark commits to — capture via process taps, transcription and diarization on the Mac, notes as Markdown/JSON/SQLite you own, original audio retained. Our privacy-graded roundup applies these questions to the whole field, cloud tools included, and Speechmark vs Granola digs into the subtler case of a tool that captures locally but syncs notes to its cloud.
The bottom line
A botless meeting recorder isn't a trick — it's just audio engineering at the OS layer: microphone plus system audio, captured where they already exist, with modern macOS APIs (ScreenCaptureKit since 13, Core Audio process taps since 14.2) finally making it clean. The bot's disappearance from your participant list tells you where capture happens; it tells you nothing about where your words go afterwards. That second question is the one worth asking.