How to Build a Live Meeting Chat Agent That Listens and Responds in Real Time

Build a meeting chat agent that listens to Zoom, Google Meet, or Teams calls and posts answers straight into the meeting chat, using MeetStream's Hosted Agent (MIA).

A meeting chat agent is a bot that sits in a live call, listens to the conversation, and writes its answer directly into the meeting's chat panel instead of speaking over the mic. Ask it "what are the action items so far" and a few seconds later a message shows up in chat, visible to everyone, without interrupting whoever is talking. This guide walks through building one on top of MeetStream's meeting bot API, using a Hosted Agent (MIA) so you don't have to run your own transcription and language model pipeline.

What you'll Build

You’ll create a Node.js application that sends a MeetStream bot into a Zoom, Google Meet, or Teams call, listens for configured wake phrases, passes the request to a hosted MIA pipeline, and posts the answer into the shared meeting chat.

What Is a Live Meeting Chat Agent?

Most meeting bots on the market are read-only. They join a call, record it, transcribe it, and hand you a file afterward. That covers the "listen" half of a meeting assistant. It doesn't cover the "talk back" half, which is where a chat agent that answers questions live in meeting chat becomes a different kind of product.

A passive recorder captures the meeting and stops there. An interactive chat agent captures the meeting and acts on it while the call is still running, posting a message the moment someone asks a question or says a trigger phrase. That's the practical difference between a passive meeting recorder and an interactive chat agent: one produces an artifact after the fact, the other produces a response during the meeting itself.

MIA, short for MeetStream Infrastructure Agent, is MeetStream's answer to that second column. It's the hosted runtime that handles transcription, wake-word detection, and the LLM call, so an application only has to create the bot and hand it an Agent ID.

How a Live Meeting Chat Agent Decides When to Respond

This is the part most competing meeting bot APIs don't document well, because most of them don't do it: how does a live meeting AI agent decide when to post into chat, instead of reacting to every sentence spoken?

The Hosted Agent listens continuously but stays quiet until it hears a configured wake phrase, something like "hey bot" or "okay assistant." Once it hears one, it opens a short response window, 8 seconds in this configuration, during which the rest of the sentence counts as the actual request. Say the wake phrase and the question together, then pause, and the transcription turn has a chance to complete before the model responds.

That gating step is also the answer to a common due-diligence question: do meeting bot APIs support sending messages back into the call, not just reading them. Some do, but the ones that do still need a trigger mechanism, or every offhand comment in the meeting would generate a chat message. Real-time meeting summarization triggered by chat commands, rather than firing on a timer, is what keeps the agent from becoming noise.

How to Build It: Step by Step

Project Setup

Start with the MIA-chat-bot from MeetStream Labs

git clone https://github.com/meetstream-ai/labs
cd labs/MIA-chat-agent
npm install
cp .env.example .env

MEETSTREAM_API_KEY=your_meetstream_key_here
MEETSTREAM_AGENT_CONFIG_ID=your_agent_config_id_here
NGROK_AUTHTOKEN=your_ngrok_token_here
MEETING_LINK=https://meet.google.com/abc-defg-hij

The Agent itself, meaning the OpenAI model, the wake phrases, and the response type, is configured once in MeetStream Dashboard -> Integrations and referenced here by ID. That's a deliberate split: this repository only needs to know which Agent to attach, not how the Agent thinks.

The Agent used in this example runs in Pipeline mode with chat response enabled, OpenAI gpt-4.1-mini for generation, and Deepgram nova-3 for transcription with boosted recognition on the wake phrases and their common variants.

1. Validate the Local Settings

The app checks only what it needs to deploy the bot. Nothing about the model or the prompts lives here:

const required = [
  'MEETSTREAM_API_KEY',
  'MEETSTREAM_AGENT_CONFIG_ID',
  'MEETING_LINK'
];

const missing = required.filter(
  (name) => !process.env[name]?.trim()
);

2. Start the Webhook Listener

The local server receives lifecycle events for the bot, joining, waiting room, removed, failure:

app.post('/webhooks/meetstream', (request, response) => {
  const event = request.body || {};
  botEvents.handle(event);
  const output = formatWebhookEvent(event);
  if (output) console.log(output);
  response.status(200).send('ok');
});

Routine, non-actionable events stay hidden in the logs. The ones that actually matter, waiting-room, joined, removed, failure, are what get printed.

3. Create a Public Callback

During local development, ngrok exposes that listener so MeetStream's API has somewhere to send events:

tunnel = await startNgrokTunnel(config.port);

config.callbackUrl =
  `${tunnel.url().replace(/\/$/, '')}/webhooks/meetstream`;

A production deployment swaps this for its own public CALLBACK_URL and skips the tunnel entirely.

4. Attach the Hosted Agent and Create the Bot

This is the field that turns a plain recorder bot into a meeting chat agent API call: agent_config_id.

const payload = {
  meeting_link: meetingLink,
  bot_name: 'Meeting Summary Bot',
  video_required: false,
  agent_config_id: agentConfigId,
  callback_url: callbackUrl
};

await fetch(
  'https://api.meetstream.ai/api/v1/bots/create_bot',
  {
    method: 'POST',
    headers: {
      Authorization: `Token ${apiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(payload)
  }
);

Setting agent_config_id is what tells MeetStream to wire in the Hosted Agent runtime for this bot. There's no separate flag for "send messages back into chat"; it's built into the Agent configuration itself, which is one reason a two-way meeting chat integration API for developers is a different build than a standard recorder, even though the bot creation call looks almost identical.

5. Let MeetStream Run the Pipeline

Once the bot is in the call, MeetStream owns the rest of the chain:

Meeting audio
  -> Deepgram nova-3 transcription
  -> wake-word gate (8s window)
  -> OpenAI gpt-4.1-mini
  -> meeting chat

There's no local audio decoder, no transcription socket, no OpenAI request, and no chat-posting code to write. Someone in the meeting can say:

Hey bot, what are the action items?
Okay assistant, summarize the meeting.

and the reply appears in chat within the response window. Editing the Agent in the dashboard changes behavior for new deployments without touching this repository at all, which is the same reason a live meeting chat bot architecture for AI coaching and sales platforms can reuse this exact setup: swap the prompt and wake phrases in the dashboard, and the coaching version or the sales-intelligence version comes from the same bot creation code.

6. Remove the Bot Safely

The program listens for shutdown signals and removes the exact bot it created:

process.on('SIGINT', stop);
process.on('SIGTERM', stop);

if (activeBot) {
  await removeBot(
    activeBot.apiKey,
    activeBot.id,
    botEvents.waitForTerminal
  );
  activeBot = null;
}

A bot that's still joining can get requeued, so the stop signal retries through that transition. Removal only counts as done once a terminal webhook for that specific bot ID arrives, or a terminal detail state is confirmed directly. After that, the webhook server and the ngrok tunnel close.

Sending Chat Messages via API vs. Native Chat Features

It's a fair question when scoping a build: how do I make an AI agent post a summary into meeting chat when someone asks for it, versus just turning on a platform's built-in bot features. Zoom, Meet, and Teams all have their own in-app assistants, but none of them let you plug in your own model, your own prompt, or your own trigger logic. A bot-based approach built on send automated chat messages during a live Zoom call via API gives you that control on any of the three platforms with the same integration, instead of three separate native SDKs with three different capability sets.

That's also the gap in most existing documentation. Some meeting assistants now support live Q&A, including Otter AI Chat and Talk to Fireflies. MeetStream is aimed at a different layer: developers can configure the model, system prompt, wake phrases, response type, and downstream tools, then deploy that behavior through a unified meeting bot API.

What is the best API for building an AI agent that listens to and responds in meeting chat is a question with very few direct answers right now, mostly because two-way interaction is still a newer capability than transcription.

Where This Fits: Sales and Coaching Platforms

How do sales and coaching tools trigger live AI responses inside meeting chat is really a question about the trigger layer sitting on top of an existing feedback pipeline. A coaching platform that already scores talk time or objection handling can use the same wake-word gate described above to let a rep ask "how am I doing on talk-to-listen ratio" mid-call and get an answer without switching apps. A sales intelligence tool can do the same for competitor mentions or pricing objections, posting a prompt into chat the moment a rep needs it rather than waiting for a post-call report.

Building an in-call AI copilot that responds to participant requests works the same way for internal meetings: nobody wants a bot narrating every few minutes, but almost everyone wants an answer on demand when they ask for one.

Common Issues

The bot joins but the Agent doesn't respond

Confirm MEETSTREAM_AGENT_CONFIG_ID matches the saved Agent. MeetStream auto-wires the hosted bridge from that ID alone.

The wake phrase gets no response

Say the wake phrase and the request in one sentence, then pause. The transcription turn needs to complete before the gate opens.

The Agent speaks instead of posting to chat

Set both the response type and response modality to Chat in the dashboard, save, and deploy a new bot. Configuration changes apply to new deployments, not bots already in a call.

A provider error appears

Check the OpenAI connection under MeetStream Dashboard > Integrations. Local provider keys in .env aren't used for the Hosted Agent path.

Best Practices for Logging and Syncing Chat Agent Sessions

Give every bot run its own log file keyed by bot_id, so webhook events and chat replies from different meetings never end up mixed together. Save each event type, joining, wake-word trigger, chat reply, under a clear label instead of a raw event code. Writing the full webhook payload to disk alongside that log, the same way you'd debug a missing recording, makes it far faster to work out why a reply never made it into chat.

FAQ

Can a meeting bot read chat messages and reply automatically during a call?

Yes, if the bot API supports a hosted agent or pipeline mode with a configured LLM and a trigger mechanism. Without that, most meeting bots only capture chat and audio for later review; they don't generate or send a reply while the meeting is running.

Is it possible to build an AI meeting assistant that both listens and talks back in the same call?

Yes. The bot joins like a normal participant, MeetStream transcribes the audio continuously, and a wake-word gate decides when a segment of that transcript should go to the language model for a response, which then gets posted back into the meeting's chat panel.

What's the difference between a passive meeting recorder and an interactive chat agent?

A passive recorder produces a transcript or recording after the meeting ends. An interactive chat agent produces a response during the meeting, tied to a specific question or trigger phrase, without needing anyone to open a separate app afterward.

How does real-time transcript data get turned into an in-chat response?

The transcript stream passes through a wake-word gate. Once a trigger phrase is detected, the following segment of speech gets sent to the language model along with recent context, and the model's reply is posted into the meeting chat rather than spoken aloud.

Do meeting bot APIs support sending messages back into the call, not just reading them?

Some do, though it's worth checking the specific docs, since most publicly documented meeting bot APIs are still built around one-way chat and transcript capture. A dedicated Agent or pipeline mode, with its own configuration for response type, is usually what separates read-only capture from a bot that can post replies.

Next Step

Ready to try it. Explore MeetStream's meeting bot API and read the full MIA documentation to deploy a live meeting chat agent for Zoom, Google Meet, or Microsoft Teams.

Full source is in MeetStream Labs under MIA-chat-agent . Clone it, fill in two keys, run npm start.

Built with the MeetStream API. Supports Google Meet, Zoom, and Microsoft Teams.