How AI should behave in a real meeting: a design guide

The behavior question is the product question

The hardest part of building a meeting AI is not transcription, not search, not even speech. It is deciding when the AI should open its mouth. A model that nails accuracy but barges in mid-sentence will get muted within a week. A model that listens politely but never moves the room forward will get forgotten within two.

Every other design choice flows from this. Latency targets, tool wiring, memory shape, even the voice itself. If you get the behavior model right, the team forgets the AI is there until it earns its turn. That is the goal.

Rule 1: silence is the default

Most of a meeting does not need AI input. Two people are working out a tradeoff, the team is venting, someone is thinking out loud. None of these moments call for a third voice. The AI should be present, listening, indexing, but not talking.

This sounds obvious until you watch a chatty assistant try to be helpful. Every reframe, every clarification, every "did you mean" is a small interruption. They add up to a meeting that feels managed by software. Teams hate that, and they should.

The right defaults: AI is muted unless explicitly addressed, unless a clear ask is on the table, or unless the team is about to make a decision based on a fact that is wrong. That last one is rare and important. We will come back to it.

Rule 2: speak only when the room would thank you

The bar for speech is one question: would a sharp, well-read teammate jump in here? Not a know-it-all, not a yes-person, but the kind of colleague the room respects. If yes, the AI should speak. If no, it should not.

In practice that means three speech triggers:

• Direct address. Someone says the AI's name and asks something. Easy case.
• Open ask. The team says "I wish we had the Q3 churn number" or "does anyone have last quarter's slide on this?" The AI has it and offers, briefly.
• Decision risk. The team is about to commit to something based on a stated fact, and the AI knows the fact is wrong or out of date. The AI flags it, with a source, in one sentence.

Outside those triggers, the AI listens. We treat any other interjection as a bug.

Rule 3: short, sourced, and one beat at a time

When the AI does speak, it speaks like a teammate who knows the team's time is expensive. One sentence answers, with a citation, in a calm tone. No preamble. No "great question." No "as a meeting AI, I think..."

The voice should sound like the smartest person in the room who is also the most economical with their words. That is the texture good teams already prefer in each other.

Sourcing matters more than length. If the AI says "Q3 retention was 91%," it should be ready to say where that number came from, in the same breath, without being asked. The team should be able to trust an AI fact at the same level they trust a teammate quoting a doc.

This is a design decision, not a technical one. Many systems can ground answers in sources. Few make the source visible by default. We think it should always be visible.

Rule 4: act in parallel, not in series

Most of what AI does in a meeting is not speech. It is work. Pulling the document someone referenced. Drafting the follow-up email. Logging the decision into the team's tracker. Generating a comp the design team mentioned. None of this should require pausing the meeting to request.

The good pattern is parallel and ambient: the conversation continues, the work happens in the background, and the artifacts are ready by the time the team needs them. The bad pattern is the prompt loop, where someone has to type or speak a request, wait, and check.

Compare with a chatbot in the same situation, which we wrote about in voice AI vs chatbot. The chatbot is structurally serial. A meeting AI must be structurally parallel, or it adds friction every time it tries to help.

Rule 5: never ask the team to manage you

The single biggest failure mode is putting the team in charge of the AI's attention. "Should I take notes?" "Want me to summarize this?" "Should I send the recap?" Every one of these is a tiny tax on the meeting. Ten of them and the AI feels like a needy intern.

Good defaults eliminate the question. Notes are always taken. Decisions are always logged. Summaries are always produced. The team should never have to remember to enable a feature mid-meeting. The settings get tuned once, by the team admin, and then the AI does its job without check-ins.

The reverse is also true: if a team explicitly says "stop doing X," the AI should remember that across meetings, not just the current one. Memory is a behavior question, not a storage question.

The hardest case: when AI knows something the room is wrong about

This is where rules collide. Rule 1 says default to silence. Rule 2 says speak when a decision is at risk. Rule 3 says be brief and sourced. What does that look like in practice?

Our pattern: the AI flags the conflict in one sentence, with the source, and then steps back. No lecture, no debate. The team decides what to do with it. Something like: "Quick flag, Q3 retention was 87%, not 91%, per the Looker dashboard from last Friday. Up to you whether that changes the call." Then silence.

The AI should not push. It should not repeat. If the team chooses to override, it logs the override and moves on. The point is not to win. The point is to make the team's information complete enough to decide well.

What good behavior feels like to the team

You can tell a meeting AI is well-designed when the team forgets it is there until it earns its turn, and then is glad it did. The dynamic looks like this:

1. The meeting opens. The AI says nothing.
2. Five minutes in, someone asks for a number. The AI gives it, with a source, in one sentence. The meeting continues.
3. Twenty minutes in, the team is about to commit to a date. The AI flags a calendar conflict for two attendees. They reschedule.
4. The meeting ends. The recap is in Slack, decisions are in Linear, the action items are tagged to owners with deadlines. Nobody had to ask for any of it.

That is the shape of trust. The team did not have to think about the AI, but the AI made the meeting better.

Anti-patterns we actively design against

A short list of behaviors that look helpful and are not:

• Live transcript on screen. It pulls eyes away from the people in the room. Good for accessibility, never as default decoration.
• Auto-summarize every five minutes. The team is in the middle of a thought. Stop interrupting it.
• Suggested next questions. The team knows what to ask next. Implying otherwise is condescending.
• Sentiment scores. Real human dynamics do not get better when reduced to a graph. They get worse.
• Reminders to "engage the AI." If the AI has to nag, it has lost. Quiet utility wins.

Each of these tests well in isolation and fails in real meetings. The lesson is to evaluate AI behavior across a full meeting, not a single utterance.

Behavior is a settings problem, not a magic problem

None of this requires a smarter model. It requires sharper defaults. Most of the design work is choosing what the AI does without asking, what it asks once and remembers, and what it never does at all.

Teams that adopt meeting AI well treat it like hiring a junior teammate. They tell it the house rules early, correct it once when it crosses a line, and expect it to remember. They do not tolerate a teammate who needs to be told the same thing every Monday, and they should not tolerate it from software either.

Where relly sits

relly is built around exactly this design model. Default silent. Sourced when it speaks. Parallel work in the background. Memory across meetings, not within one. We treat every interruption as a bug to be designed out, and every "should I..." question as a setting we should have made for the team.

If you are evaluating meeting AI for a team that already moves fast, early access gets you in before public launch with 50% off your first year. We will not make your team manage us.