Real-time AI assist in meetings: useful tool or distraction?

Six months ago, we shipped real-time AI suggestions in our meeting copilot. The feature shows you a side panel of relevant context — past decisions, related documents, similar prior meetings — while you're in the call. As the conversation shifts, the suggestions update.

We were not sure this was a good idea. The internal debate before launch was the closest thing we'd had to a knife fight in a long time. Half of us thought it was the killer feature. The other half thought it would be the most distracting thing we'd ever built and would turn meetings into split-screen chaos.

After a quarter of dogfooding across a dozen different meeting types, we have a more nuanced answer than either of those positions. Real-time AI assist is genuinely useful in some kinds of meetings, distracting in others, and useless in a third category. This is what we learned.

The honest taxonomy

Not all meetings are the same. The mistake of the "always on" camp was treating real-time assist as a universal good. The mistake of the "never on" camp was treating attention as zero-sum. The reality is that meetings sort into roughly three categories, and the AI is suited to one of them, complicated for another, and a clear net negative in the third.

Category 1: question-driven meetings (AI is great here)

These are meetings where someone — usually you — is being asked questions that have factual answers. Customer calls. Investor meetings. Technical interviews (on the interviewer side). Stakeholder reviews where someone asks "how does the X integration handle the edge case?"

In these meetings, the AI is genuinely useful. When a customer asks "does your product support SOC 2?", the side panel surfaces your latest SOC 2 documentation. When an interviewer asks about your architecture decisions, the panel pulls up the relevant ADR. The AI is doing what a great chief of staff would do if you had one: it's keeping the facts at your fingertips.

The internal language we use is "you are being audited." In an audit-flavored meeting, the AI is helping you pass the audit. It's lower the cognitive load of recalling things you technically know but can't access fast enough.

Category 2: collaborative meetings (AI is complicated)

These are meetings where the value is the conversation itself. Brainstorms. Design reviews. Retros. Architecture discussions where the goal is to think out loud together and arrive at something nobody had before the meeting started.

In these meetings, the AI is a mixed bag. The suggestions can be useful — surfacing a prior architecture decision that's relevant to the current discussion. But the same suggestions can short-circuit the thinking. Instead of working through the trade-offs from first principles, someone glances at the AI panel and says "we decided this last month, let's just do that." Sometimes that's right. Sometimes it short-circuits a conversation that needed to happen.

We've learned that the AI is more useful in collaborative meetings when it's set to "passive mode" — it doesn't actively surface things, but you can manually invoke it. The cognitive cost of involuntary suggestions is too high; the cognitive cost of voluntary lookup is much lower because you only do it when you actually want the lookup.

Category 3: relational meetings (AI is a net negative)

These are 1:1s, manager check-ins, skip-levels, sensitive conversations. The value of these meetings is not information transfer; it's the human relationship. The presence of an AI suggestion panel in the corner of your screen is a constant low-grade signal that the meeting is being processed for utility, and that signal corrupts the conversation.

This is the meeting type where we eventually built a "summary-only" mode. The AI listens, transcribes, and produces a recap after the meeting. But during the meeting, nothing appears on screen. The conversation gets the full attention it deserves.

We did not predict this. Our initial assumption was that AI assist was universally a positive — turn it down or off if you don't want it, but on by default. We were wrong. The right default for relational meetings is off. Period.

What the suggestions actually look like in practice

Let's get concrete. Here are three actual moments from real meetings where the AI did something useful, and three where it was a distraction.

Useful moment 1

A senior engineer is being asked by a stakeholder why we chose Postgres over MongoDB for the new service. The engineer was not part of the original architecture decision; the person who made that decision left the company three months ago. The AI panel surfaces the ADR from 18 months ago, with the original trade-off matrix.

The engineer reads it for ten seconds and gives a coherent answer: "We chose Postgres because we needed strong consistency for the billing data, and the original team did a benchmark showing MongoDB's tunable consistency wasn't sufficient for our use case." Stakeholder satisfied. Meeting moves on.

Without the AI, this would have been a 5-minute "let me get back to you" moment, followed by 20 minutes of the engineer searching old docs after the meeting, followed by a Slack message back to the stakeholder. The AI compressed this into ten seconds.

Useful moment 2

A customer call. The customer asks about a feature roadmap item they care about. The AI panel surfaces the most recent internal product update on that feature, including the projected ship date. The salesperson can give a confident, accurate answer without having to context-switch out of the conversation to look it up.

This is the most universally useful pattern. External-facing meetings where you might get asked factual questions about your own product or company are exactly the right environment for real-time AI.

Useful moment 3

A technical debugging session. Three engineers on a call working through a production incident. The AI surfaces a prior incident from six weeks ago with similar symptoms, plus the postmortem of how it was fixed. One of the engineers had been on that prior incident but had partially forgotten the details. The reminder saves them 15 minutes of re-deriving the diagnosis.

Incident response is a great environment for real-time AI. The stakes are high, the questions are concrete, and the historical context is genuinely useful.

Distraction moment 1

A design review. Four engineers and a designer working through a new feature. The AI panel keeps surfacing past design decisions from adjacent features, some of which are relevant and some of which are tangentially related. The lead designer keeps glancing at the panel mid-sentence. The conversation loses flow.

Eventually the designer turns the panel off. The conversation gets better immediately. The right move here is passive mode — the suggestions are available if anyone wants them, but they don't compete for attention during the discussion.

Distraction moment 2

A 1:1 between a manager and her report. Halfway through, the report mentions feeling burned out. The AI panel helpfully surfaces an article about burnout in engineers. This is profoundly not what the moment needed. The report sees the suggestion on the screen and the conversation gets stilted.

This is the failure mode of relational meetings. The presence of the AI signals "you are being processed", and in a moment that should be human, that signal hurts.

Distraction moment 3

A brainstorm about a new product direction. The AI keeps surfacing related products that already exist. Half the suggestions are accurate competitors; half are tangentially related. The team starts orienting their ideas around what the AI shows them, instead of generating fresh thinking.

This is the convergence problem. Real-time AI is biased toward what already exists, because that's what it can retrieve. In creative work, this is exactly the wrong bias.

The UI matters as much as the model

A non-obvious finding: the same AI suggestions are useful or distracting depending entirely on how they're presented.

The first version of our real-time panel was a sidebar that updated continuously. New suggestions popped in. The icon flashed when something appeared. We thought this was good — we wanted to make sure users knew there was new context available.

It was awful. The visual change in the user's peripheral vision was, on its own, distracting. Even if the suggestion was relevant, the way it announced itself broke focus.

The second version was much quieter. The panel updates without animation. There's no notification. If you glance at it, the latest suggestion is there. If you don't glance, nothing demands your attention. This version is dramatically more usable, with the same underlying suggestions.

The lesson: real-time AI is a UX problem at least as much as it's a model problem. The model has to be good — irrelevant suggestions undermine the whole feature — but a good model with bad UX is worse than no AI at all.

The mode-switching rule

What we've landed on, after six months, is a per-meeting-type default with easy overrides:

• Question-driven external meetings (sales calls, customer calls, investor meetings): real-time assist on by default
• Question-driven internal meetings (stakeholder reviews, architecture sign-offs): real-time assist on by default, passive mode
• Collaborative meetings (design reviews, retros, brainstorms): passive mode (available on demand)
• Relational meetings (1:1s, manager check-ins, skip-levels): summary-only mode (no in-meeting panel)
• Recurring sync meetings (standups, planning): summary-only mode (no in-meeting panel)

The default for a meeting is inferred from the calendar metadata — title, attendee count, organizer-attendee relationship. Users can override per-meeting.

The override rate is low — about 15% of meetings — which suggests our defaults are roughly right. The most common override is turning real-time off for a meeting the calendar thinks is question-driven but the user knows is actually collaborative. That's a model improvement we're working on.

Who real-time AI is for

A more honest version of the value proposition: real-time AI is for the moments when you're going to be asked a factual question and your professional credibility depends on having a smooth, accurate answer. It's not a generalized productivity tool. It's a specific tool for a specific kind of moment.

If you're a senior engineer who frequently gets pulled into stakeholder meetings about parts of the codebase you don't actively work on — real-time AI is for you.

If you're a customer-facing engineer or a salesperson who gets asked about your own product — real-time AI is for you.

If you're an EM who walks into a planning meeting and needs to remember what was decided in the last three planning meetings — real-time AI is for you.

If your work is mostly brainstorming, creative collaboration, or building human relationships — real-time AI is probably not for you, at least not in the always-on mode. You might still want the post-meeting recap. You probably don't want the live panel.

The bigger lesson

The "is real-time AI good or bad?" question is the wrong framing. It's like asking "are interruptions good or bad?" The answer is: it depends on what's being interrupted, what's interrupting it, and how the interruption is presented.

What we've learned is that the right default is not "always on" or "always off" — it's "thoughtful, with per-meeting-type defaults." Real-time AI deserves the same care we'd give to any other intrusion into someone's attention. Get the placement right, get the timing right, get the mode right — and it becomes genuinely valuable. Get any of those wrong, and it's worse than not having it at all.

For us, that meant rewriting our own assumptions about when to enable the feature. The most surprising thing was how often "off" was the right answer.