Scaling Recording Bots Across Concurrent Meetings

Bots don't fail in a straight line as load goes up. A single bot joining a single call is a solved problem, buildable in an afternoon with a headless browser and a webhook. Run a thousand of them at once, across four platforms, during the same three-hour stretch of business hours, and the failure modes multiply instead of scale. Most teams underestimate that gap badly, and the underestimate is the actual subject here.

Zoom, Microsoft Teams, Google Meet, and Slack each bring their own join logic, their own audio capture path, their own recording lifecycle, and their own way of deciding whether a bot looks suspicious. Four platforms means four separate systems that all have to keep working at once, and any one of them can break on a schedule nobody announced ahead of time. Add in resource contention, CPU, memory, network I/O that costs nothing per bot but adds up fast across a few hundred of them, and treating this as an infrastructure problem rather than a scripting exercise stops being debatable.

The failure math has no slack in it, either. Miss a live meeting and there's no second take. Once the call ends, whatever the bot didn't capture is gone for good. Fellow.ai's 2025 research put usage of AI meeting assistants at 75% of professionals, and most market estimates place the category's growth near a 25% compound annual rate. More teams are building critical workflows on top of bot infrastructure that has to hold up in production, not just work in a demo.

What a bot actually does per meeting, and where each step can break under load

Strip a bot's job down and it looks simple enough on paper: detect the meeting through a calendar trigger or an API call, send the join request, authenticate against the platform, capture audio and video once inside, deliver the transcript (live or after the fact), fire a webhook, then tear down the instance. Six or seven steps, depending on how you count. Each one is a place things go wrong, and at scale, a failure rate that looked negligible for one bot starts showing up as a real number of lost meetings once a few hundred run at the same time.

What makes each step heavier than it looks is the volume of data moving through a single bot at once: participant names and IDs, live transcripts, post-call transcripts, diarized audio (split by speaker, or mixed together), video in both live and MP4 form, screenshare content, chat logs, meeting metadata, join and leave events, speaker-change events. None of that is exotic in isolation. Managing all of it reliably, for every bot, every time, under load, is the actual engineering problem, and it's the part most demos never touch.

Platform quirks only surface once volume gets high enough to hit them repeatedly. Joining a meeting without host permission, or without the meeting owner ever explicitly inviting the bot, isn't handled the same way across platforms, so workarounds differ by vendor and change without warning. Different account configurations across platforms can carry different recording permissions, so a bot can't safely assume a uniform environment. Platforms actively hunt for automated participants and update their detection logic on their own timeline, so join logic that worked reliably can fail after a platform update with no public changelog to explain the change.

Live use cases stack a latency constraint on top of all that. A transcript delivered ten seconds late is fine for an archive. It's dead weight for a live captioning or coaching tool that needs sub-second delivery over a webhook, and that requirement pushes the whole stack toward real-time systems design rather than batch processing.

The infrastructure layer: VMs, orchestration, and what "concurrent at scale" actually requires

Each bot usually runs in its own container, some setups use full VMs instead, because it has to behave like a full meeting client: camera feed, audio stream, all of it. That's resource-heavy by design, not by accident, and it's why concurrency turns into an orchestration problem rather than a bigger version of the same script.

Running a fleet means solving four things at once, and none of them are optional. Scheduling has to map meeting start times to bot spin-up so a VM is warm before the join window opens, not after. Burst handling matters because meetings cluster hard around business hours, so the fleet needs to absorb sharp spikes rather than handle a steady average load. Health monitoring has to catch a bot that's hung or crashed mid-meeting and attempt recovery before the recording is gone. Teardown has to reclaim VM resources right after a meeting ends, since idle compute at scale is a real cost line, not a rounding error.

The open-source MeetingBot framework, maintained under the screenappai GitHub organization, handles the throughput problem with a Redis queue for asynchronous processing, on the reasoning that handling join requests synchronously falls over the moment concurrent load gets real. That same project ships Prometheus metrics out of the box, which matters more than it sounds like it should: without per-bot telemetry, figuring out why forty meetings failed to record last Tuesday afternoon turns into a manual audit instead of a five-minute dashboard check.

Managed providers take the VM fleet off a team's plate entirely, and this is where the build-versus-buy math starts to tilt hard toward buy. Recall.ai runs thousands of concurrent VMs daily under a 99.9% uptime SLA and processes billions of minutes of meeting data a year. Per Recall.ai's own customer accounts, teams that go this route report saving around nine months of engineering time versus building the equivalent in-house. Nine months is most of a year of engineering headcount freed up for something other than VM plumbing. Building this in-house means months of up-front work plus a standing maintenance burden for as long as the system runs, a cost structurally different from a per-minute API bill, not just a bigger version of it. Teams that assume in-house control is worth that cost are, in most cases, simply wrong about what they're buying with it.

Platform rate limits and anti-bot detection as external constraints on throughput

Rate limits are set by each platform on its own terms, and there's no shared standard across Zoom, Teams, Google Meet, and Slack that a team can design against once and reuse. What clears fine on one platform throttles hard on another, with no consistent logic tying the two together.

Anti-bot detection makes this worse, since the detection logic itself isn't published anywhere. Platforms actively work to spot and block automated participants, and because the mechanisms are undocumented, they change without notice and can break a join flow across an entire fleet in a single afternoon. The usual mitigations involve making a bot appear less conspicuous to platform detection systems. None of these approaches are guarantees. They cut the odds of getting flagged. They don't eliminate the risk.

Run bots across more than one platform in the same workflow and the exposure compounds, since a team is now subject to two or more independent sets of policies that can each change on their own schedule with no coordination between them. Managed API providers treat maintaining these integrations as core product work, so when Zoom or Teams shifts its detection logic, managed providers can push fixes across their platform integrations centrally. Self-hosted teams don't get that for free. They have to notice the break themselves and patch it, which usually means the fix arrives after several meetings have already failed silently.

Throughput ceilings aren't fully in an engineering team's control, and treating them as if they were is the actual mistake here. Designing for external throttling as a permanent condition, not an occasional edge case, is what separates a fleet that survives a detection update from one that loses meetings when platform policies shift.

Build vs. buy: what the decision actually trades off at each concurrency tier

Building in-house buys full control over data routing, bot behavior, and exactly how each platform integration works. It also means building and maintaining separate join logic, audio paths, and recording lifecycles for every platform on the list, with engineering cost front-loaded into months of initial build and then never really going away, since platforms keep changing and the code has to keep up. Open-source frameworks like MeetingBot offer a real head start, with a containerized runtime, a Redis queue, Prometheus metrics, and support for Google Meet, Teams, and Zoom already wired in. But "head start" is the accurate description, not "finished product." Hardening any of that for production is still work the team owns, and most teams that go this route underestimate how much of that work never ends.

The managed side of the market has taken different shapes depending on what a team actually needs. Recall.ai offers one API across Zoom, Teams, Google Meet, Slack, and other platforms, with unlimited concurrent bots for scheduled meetings (ad-hoc bots are capped at 30), a 99.9% uptime SLA, and compliance coverage across SOC 2, ISO 27001, GDPR, CCPA, and HIPAA. Its customer list includes DataDog, Calendly, Instacart, Rippling, and ClickUp, and the company reports growth of 12x in 2023 and 3x in 2024, alongside recent product launches covering a Desktop Recording SDK, calendar integration, and storage and playback tools, with a mobile SDK on the way. MeetStream.ai takes a similar single-API approach across Google Meet, Teams, and Zoom, with region-based data routing built in, useful for teams that need to keep EU meeting data inside EU infrastructure for GDPR reasons. Meeting BaaS, built by a company operating under the name SAS SPOKE, runs a hybrid hosted and self-hosted model with multi-zonal data residency on its Enterprise tier; its interaction model sits close to bare metal, one POST request with a meeting URL, a bot name, and a webhook, no SDK involved, with its bots and SDKs published openly. Vexa sits furthest toward the self-hosted end: Apache 2.0 licensed, deployable via Docker Compose, Kubernetes, or OpenShift on infrastructure a team already controls, with full data sovereignty.

The concurrency tier a team sits at should do most of the deciding, and past a certain point, building in-house is the wrong call no matter how appealing full control sounds. Low concurrency on a single platform makes building in-house, or leaning on an open-source base like MeetingBot, defensible if the team already has spare infrastructure capacity. Once concurrency climbs and more than one platform enters the picture, though, the math tilts hard toward a managed API: the engineering time saved (that nine-month figure from Recall.ai's customers) reliably outweighs what gets spent on API fees. Teams that keep building in-house past that point are usually paying for control they aren't using. For enterprise deployments with strict data residency rules, the decision often gets made by compliance requirements before cost enters the conversation at all, pointing either toward a managed provider with explicit regional routing, like MeetStream.ai or Meeting BaaS's Enterprise tier, or toward a fully self-hosted setup like Vexa.

Agencies running bots across a roster of client accounts face a version of this decision that goes beyond infrastructure. Capturing meetings across a portfolio of brands is only half the job. Knowing how those brands actually show up across the surfaces shaped by one model or another, in the conversations the bots are capturing, is a separate analytical question, and treating a recording pipeline as though it answers that question on its own leaves real gaps in what an agency can tell a client.

Compliance obligations that change character when bots run at volume across multiple organizations

Compliance exposure grows with concurrency in a way that's easy to underestimate. Every additional meeting adds participants, and each participant potentially brings a different jurisdiction's law with them, one that governs that specific call whether the operator planned for it or not.

GDPR sets the baseline for anyone dealing with EU participants. Recordings, transcripts, and AI-generated summaries routinely carry names, voices, job titles, and stated opinions, all of which qualify as personal data under the regulation. Recording an EU data subject requires a lawful basis and clear, transparent notice, and in a lot of cases explicit consent has to be secured before recording starts, not after. The financial exposure for getting this wrong runs up to €20 million or 4% of global annual turnover, whichever number turns out larger. Clearing the GDPR bar doesn't clear every bar, either: Some EU member states carry additional national-level statutes covering unauthorized recording that sit apart from data protection law.

Thirteen entities within a single country. states, including California, Illinois, and Florida, require all-party consent for recording. A single participant dialing in from one of those states makes that state's law the operative standard for the entire call, regardless of where the meeting was scheduled from or where most other participants sit. No jurisdiction treats a bot merely showing up on a participant list as adequate notice or consent on its own. Affirmative disclosure still has to happen, every time.

Agencies carry an added layer of risk here that's easy to miss. Individual client stakeholders may be running their own bots, entirely outside any governance the agency has set up, alongside whatever the agency itself deployed. If a data deletion request comes in, tracking down every record across both sets of tools can turn out to be practically impossible, a shadow IT gap that most agencies haven't mapped, let alone closed.

The fix has to be built into the bot's behavior, not left as a policy document nobody reads. MeetStream.ai's guidance calls for the bot to post a text message announcing its presence, with a link to the relevant privacy notice, within the first 30 seconds of joining. Spinach AI takes a more elaborate version of the same idea in its enterprise product: the bot gets renamed to match the organization's own branding (something like "Acme Notetaker" rather than a generic label), the in-meeting notification text goes through legal review before deployment, and any participant on the call can pause, resume, or remove the bot mid-meeting. That's consent built into the product, not a checkbox buried in a terms-of-service page, and it's the standard every team running bots at volume should be measured against.

The legal stakes here aren't abstract. A federal class-action lawsuit filed against Otter.ai in August 2025 alleges the company "deceptively and surreptitiously" recorded private conversations without consent. That case is still working through the courts, but it's a live example of what happens when consent handling gets treated as an afterthought rather than as part of the system architecture from day one.

SOC 2 Type II certification, which audits whether a company's controls actually held up over a period of time rather than just checking whether they were designed correctly on paper (that's Type I), tends to be a hard requirement for enterprise sales. Any team scaling bot deployments across enterprise clients should expect to run into this requirement, not be surprised by it.

Consent isn't purely a legal box to check, either. Fellow.ai's 2025 research found that 84% of professionals say they change how they speak when they know an AI note-taker is in the room. That's a data quality problem sitting on top of the legal one: the presence of a bot changes the conversation it's recording, which means consent handling shapes the accuracy of the very data the system exists to capture.

Operational patterns that keep a concurrent bot fleet reliable in production

A few patterns show up repeatedly in bot fleets that hold up under real load, and most of them are less about clever engineering than about closing off the specific ways things quietly break at scale.

Join requests need to be idempotent. Retry logic is automatic in most systems, which means the same join request can fire twice, and without deduplication at the queue level, that turns into two bots sitting in the same meeting, doubling storage costs and confusing whoever reviews the transcript afterward. Pre-warming a pool of VMs, keeping a set of instances ready rather than spinning them up the moment a meeting starts, cuts join latency at the cost of some idle compute sitting around unused, a trade that's usually worth making given how tight the join window can be. Failures need to be visible rather than silent. When a bot can't get into a meeting because of platform detection, a rate limit, or a network fault, the system needs to log it, alert someone, and never just quietly drop the recording with no trace. That kind of visibility is a product requirement here, not an operations nicety.

Webhooks need the same care, given how much downstream work depends on them landing correctly. Transcript storage and analytics pipelines are only as reliable as the webhook deliveries feeding them, which means delivery confirmation, a dead-letter queue for anything that fails to land, and the ability to replay a delivery all need to be part of the design from the start, not bolted on after the first outage.

Per-participant audio tracks, where the API config allows it, produce meaningfully better transcription accuracy and cleaner speaker attribution than a single mixed-down feed, and that's worth the added storage and processing cost once volume justifies it. Configuration drift is its own quiet failure mode: platform-specific settings fall out of sync as one provider changes its API, and a single config layer that applies consistently across all platforms (Recall.ai's approach) cuts down on that risk considerably. Self-hosted teams don't get that for free and need explicit version control on their config, per platform, or the same drift creeps in unnoticed.

None of this works without an observability layer that produces per-bot metrics on join success, capture duration, and transcript delivery latency, rolled up into fleet-level dashboards with alerts on anomalous failure rates. Without that, figuring out which meetings got lost and why turns into a manual, error-prone process every time something breaks.

Capacity planning has to account for the shape of real demand, not an average. Business-hours clustering can push peak concurrency to somewhere between three and five times the average load, so a fleet sized for the average gets overwhelmed right when it matters most. Sizing for peak, or building dynamic scaling with a ramp time actually tested to fit inside the pre-meeting window, is the difference between a system that holds up under real traffic and one that only works in the demo.

What teams running bots at scale should actually measure to know the system is working

Recording reliability rate, the share of scheduled bot joins that captured a full recording without a gap, is the single number that matters most here. It's the first place a platform change or an infrastructure problem shows up, and it should get watched the way a payments company watches transaction success rate: closely, constantly, with alerts set on even small drops. A small drop today is usually the early signal of a bigger failure tomorrow, and teams that only check this number after a client complains have already built the fleet wrong.