Build real-time meeting agents that hear, think, and respond

What a live agent actually needs

Most meeting infrastructure hands you a recording after the fact, which is useless for an agent that answers questions mid-call. A real-time agent needs three things: low-latency audio so it hears the conversation as it happens, live transcripts so its language model has text to reason over, and a way to act inside the meeting so its output reaches the participants.

MeetStream provides all three through one bot, so your agent's architecture stays a single loop instead of a patchwork of vendors.

Live audio, one stream per speaker

Audio and video stream over secure WebSocket at around 200ms latency, with a separate stream per participant. Per-speaker streams matter more for agents than anywhere else: your agent knows who is talking without running source separation, can react only when the host addresses it, and can maintain per-person context through the conversation.

Feed the streams to your own streaming speech-to-text or a speech-native model, or skip that layer entirely and consume real-time transcripts with speaker identification delivered to your webhook.

Act inside the meeting

MeetStream bots can read the meeting chat, send chat messages, and display images and GIFs in the meeting itself. That is enough surface for genuinely useful agents: answer a question in chat with a link to the doc, post the relevant chart when someone asks about last quarter, react to a decision with a confirmation everyone can see.

Reading chat also gives your agent a second input channel, since participants often direct requests to a bot in writing rather than out loud.

Put an agent in the room with one call

Deploying the agent is a POST request with the meeting URL. The bot joins Zoom, Google Meet, or Microsoft Teams within seconds, no host permission or paid meeting plan required, and webhook lifecycle events let your backend manage the agent session from join to teardown.

Designing the response loop

A responsive agent is a latency budget problem. With transport at around 200ms, you have real headroom for streaming transcription and a fast model pass while the moment is still live. A pattern that works well: acknowledge in chat immediately, then follow with the substantive answer once your pipeline finishes.

Per-participant streams also let you cut inference cost by triggering the full pipeline only on relevant speakers or on wake phrases, rather than processing every second of every voice. More than 30 AI products run on this infrastructure in production, including live agent workloads.

How it works

1. Send a POST with the meeting URL and your agent's bot joins the live call.
2. Consume per-participant audio over WebSocket, or diarized transcripts via webhook, in real time.
3. Run your reasoning pipeline on the live conversation as it unfolds.
4. Respond in the meeting through chat messages, images, and GIFs.

Frequently asked questions