Recording Without Bots: The Post-Bot Era Begins

For the past five years, nearly every meeting recording tool worked the same way: a bot joined your call as a participant, captured the audio, and sent it somewhere for processing. It was a clever hack. It worked across platforms. And now the platforms are fencing it in.

Updated October 3, 2026. We first published this in April 2026, before the Teams rollout. This version updates the Teams, Google Meet and vendor passages to what happened since, corrects our earlier claim that Google had no RTMS equivalent, and replaces a quote we had attributed to Zoom with Zoom's documented guidance. Details on the corrections page.

Microsoft Teams began detecting third-party bots and holding them in the lobby for organizer approval in May 2026, with general availability due to finish by the end of October 2026. Zoom shipped its Real-Time Media Streams (RTMS) API in 2025, giving developers a native path that makes bots unnecessary. Fathom, which still relies on a bot, added a beta bot-free mode to its Mac desktop app in April 2026. Google Meet added a second, deny-by-default join queue in March 2026, and its own media API is a developer preview closed to new signups.

The recording architecture that built a billion-dollar category is being dismantled, platform by platform. If your recording vendor has no bot-free path by now, ask why. The tools that recognized this shift early will survive. The ones that did not will spend the next year apologizing for broken recordings.

How bots work (and why platforms hate them)

A recording bot is a headless application that joins a meeting as if it were a human participant. It authenticates with the meeting platform, enters the call, captures the audio and video streams, then pipes that media to an external server for transcription and analysis.

This model worked because meeting platforms treated bots the same as any other participant. A bot could join via a meeting link, just like a person. Platforms had no reliable way to distinguish a headless Chrome instance running a recording script from a real user on a laptop.

Platforms hate this for three reasons. First, it is a privacy problem. A bot silently recording a meeting violates the spirit (and sometimes the letter) of consent laws, mainly privacy and wiretap rules such as GDPR in the EU and all-party consent statutes in several US states. Second, it is a revenue problem. Every tool that records through a bot is competing with the platform's own paid recording features. Teams Premium costs $10/user/month and includes transcription, summaries, and meeting recap. Third, it is a control problem. IT administrators have no visibility into which bots are joining which meetings. Shadow recording is a data governance headache.

The platform crackdown

Microsoft Teams (from May 2026): Under MC1251206, Teams detects external meeting bots joining meetings hosted by your organization, labels them in the lobby, and requires the organizer to approve them. Detection is on by default for all tenants; admins can turn it off. General availability is due to finish by the end of October 2026. This is not a ban, but the friction is significant: for organizations recording hundreds of calls per week, approving bots meeting by meeting slows the workflow. A separate admin policy that blocks identified external bots outright (MC1459141) rolls out in October 2026 and is off by default. Microsoft's sanctioned route for vendors, the Teams Bot Identification Program, lets registered bots identify themselves, but it "has reached its current bot provider capacity."

Zoom RTMS (generally available June 2025): Zoom took a different approach. Instead of just blocking bots, they built a replacement. The Real-Time Media Streams API lets authorized applications receive meeting audio and video directly from Zoom's servers. No bot joins the meeting. No extra participant appears. The application gets the media stream through an API, processes it externally, and the meeting participants never know the difference (beyond the required consent notification).

RTMS is not just a policy change. It is an architectural shift. Zoom's own SDK guidance now says: "For continuous or automated recording, use RTMS." For developers, RTMS removes the bot: media comes straight from Zoom, and there is nothing to get kicked or blocked. The catch: RTMS is paid by usage (Zoom staff quote $0.01 per streaming minute without transcription), and Zoom controls the terms. Since March 2, 2026, Zoom also requires an On Behalf Of token for Meeting SDK apps joining externally hosted meetings, and points automated recording to RTMS.

Google Meet: Google does have an RTMS equivalent: the Meet Media API gives apps real-time audio and video from a meeting. It is still a developer preview, and Google says it "is no longer accepting new signups." Apps also need someone in the call who can consent on behalf of the meeting. On the bot side, Google added a second join queue in March 2026 for requests the host "is more likely to need a closer look" at, where the default action is to deny entry. Google's post does not mention bots, but bot vendors report their bots landing in that queue.

Three paths forward

The bot-based recording model is not dead overnight. But any tool relying solely on bots is building on a shrinking foundation. Three alternative paths are emerging, and they are not equal.

Path 1: Native platform APIs (the winner). This is the cleanest path and the one that will dominate. Zoom's RTMS is the template. The recording tool gets authorized by the platform, receives media streams through an official API, and processes them externally. No bot, no friction, no risk of platform blocks. The downside: each platform controls access. If Zoom changes RTMS terms or pricing, every tool built on it is affected. And not every platform offers this yet. Teams offers third parties only restricted, bot-based media access (its real-time media platform and certified compliance recording), not an RTMS-style stream. Google Meet's Media API exists but is closed to new developers. You are at the platform's mercy, but you are building on solid ground.

Path 2: Desktop/OS-level capture (the fallback). Instead of joining the meeting as a participant, record from the user's machine. A lightweight agent runs on the desktop, captures the system audio (and optionally the screen), and sends it for processing. This works across every meeting platform because it operates below the platform layer. Recall.ai's Desktop Recording SDK is the most developed version of this approach. The downside: you need software installed on every user's machine. That is a harder sell than a bot that just works. IT teams may push back. And you may lose some data quality compared to native APIs. This path survives, but as a secondary option.

Path 3: Hybrid (the most resilient, if you can build it). Use native APIs where available, desktop capture as a fallback, and bots only where they still work without friction. This is the most resilient approach, but also the most complex to build and maintain. You are maintaining three recording pipelines in parallel. Only well-funded infrastructure players like Recall.ai can pull this off. For everyone else, pick a lane.

Native APIs win because they align with what the platforms want. Every other path is either fighting the platform or working around it. The tools that ship native integrations first will lock in their positions while competitors scramble.

Who adapts, who scrambles

Best positioned:

• Fathom joins calls with a bot on Zoom, Meet, and Teams. In April 2026 it shipped a second path, still labeled beta: its Mac desktop app records audio plus transcript, or transcript only, without a bot, chosen meeting by meeting, and bot-free video is in a limited Zoom beta. (An earlier version of this article said Fathom ran natively on Zoom with no bot; that was wrong.) A desktop fallback is the right hedge if platforms keep gating bots. That said, Fathom's team features are thin compared to Fireflies, which limits its appeal for organizations that need admin controls and team-wide analytics alongside their recording.
• Recall.ai powers recording infrastructure for many tools (it claims 3,000+ customers). It is an official Zoom RTMS reseller, supports the Meet Media API, is one of the partners Microsoft named for Teams bot registration, and its Desktop Recording SDK gives customers a bot-free fallback on the major platforms. If you are a developer building on Recall, you have options. That is the right position to be in.
• Bluedot and Krisp use desktop-level capture. They never relied on bots, so the platform crackdown does not affect them directly. Their challenge is different: scaling desktop agents across enterprise deployments.

Most at risk:

• Fireflies.ai, tl;dv, MeetGeek, and Avoma relied heavily on bot-based recording when we published this. Update, October 2026: Fireflies, tl;dv and MeetGeek now offer bot-free desktop recording, which is Path 2 above. We did not find a bot-free option on Avoma's site. Their bots still face the Teams lobby and Meet's second queue.
• Gong and Chorus.ai use bots for recording, but they have enterprise contracts and deeper platform partnerships that may give them priority access to native APIs. The risk is lower, but it is not zero. Gong has the resources to build multiple recording paths; the question is whether they move fast enough.
• MeetingBaaS and smaller recording API providers face the same infrastructure challenge as Recall.ai but with fewer resources. If they cannot offer RTMS and desktop capture alongside bots, their customers will migrate to providers that can.

The split: tools with a second capture path keep working as platforms tighten; tools that rely on bots alone absorb the friction. As we detail in our Teams breakdown, the change that began in May 2026 is a lobby approval step by default, with outright blocking left to admins.

If your notetaker switches from bot to native API, you probably will not notice. The bot icon disappears from the participant list. Everything else works the same. The change is invisible to end users but existential for vendors.

The timeline

The pattern is visible. Zoom built the alternative first, then tightened SDK access. Microsoft is applying pressure while offering third parties only restricted, bot-based media access, not an RTMS-style stream, and its registration program is full (which puts Teams-focused tools in a tough spot). Google built a media API, then closed it to new developers while gating joins.

For product teams and ops leads evaluating recording tools today, the question to ask is simple: "What happens to your recording when bots stop working?" If the answer involves phrases like "we are exploring options" or "we plan to support native APIs," that is a warning sign. The tools that already have multiple recording paths (native APIs, desktop capture, or both) are the ones that will keep working when the next platform tightens the screws.

Bots have not disappeared: under the default settings on Teams and Meet, a host can still let them in. But every major platform now makes them wait, identify themselves, or move to a sanctioned path. The tools that built a second path early are the ones with room to spare.