Intent-of-address gating for meeting and room-audio AI
Stop Side Conversations From Polluting Your Meeting Summary
Selective Auditory Attention (SAA) gates each turn before it reaches your meeting AI, so only addressed speech makes the recap.
The failure
Two participants hold an aside. The meeting AI writes it up as an action item.
In a many-to-many meeting, people address each other as often as they address the assistant. Nothing in a typical stack decides which is which before the assistant acts.
SAA (Selective Auditory Attention) closes that gap: it decides intent of address before the assistant acts, so side conversations stay out of the summary.
false inclusion
Side conversations pollute the recap
A brief aside between two participants becomes a bullet point in the summary, with a follow-up nobody owns.
wrong attribution
Action items land under the wrong name
The system knows who spoke, not who they were speaking to, so follow-ups get assigned to people who were only talking to each other.
The fix
A hosted gate that decides intent of address before the assistant ever acts.
SAA is a hosted, pre-ASR layer that decides whether speech in a meeting room is addressed to the AI assistant or to another participant. It routes only addressed audio to the model stack you already run, fails closed when it is unsure, and needs no wake word and no GPU.
Research foundation
Published on multi-party sessions.
SAA reliably decides who is being addressed on held-out multi-party sessions, the same structure meeting rooms produce (arXiv:2604.08412).
Two caveats apply: it fails closed under distribution shift, and cross-lingual recall is a known limitation under active work.
input modality
Works with or without a camera
Uses the room's camera feed alongside audio when one is present, and falls back to audio alone when it is not.
latency
Decision in real time, before STT
The intent-of-address decision returns before ASR begins, inside a live meeting turn budget.
design principle
Fails closed by design
Ambiguous speech is not forwarded. Under uncertainty, SAA stays silent rather than risk including the wrong turn.
How it integrates
One stage before your ASR. No hardware change.
SAA sits between your room audio and your ASR, deciding intent of address before speech-to-text. Only addressed turns reach your meeting-intelligence model.
Your transcription stack, your ASR vendor, and your room hardware stay exactly as they are.
Stream audio to SAA
Audio from the room microphone or meeting-agent audio track streams to the hosted SAA service through a thin client SDK in JavaScript/TypeScript or Python.
No model runs on your hardware. No wake word. No GPU required.
Intent-of-address decision
SAA analyzes acoustic and prosodic patterns before ASR runs, without parsing language content. It is language-agnostic at the acoustic level.
Before speech-to-text, it returns a decision: was this turn addressed to the assistant, or was it an exchange between participants?
Forward only addressed turns
Turns addressed to the assistant are forwarded to your ASR and meeting-intelligence model.
Participant-to-participant speech and ambient room noise are suppressed. Under uncertainty, SAA forwards nothing.
Hosted, per-device, DPA available
SAA runs as a hosted service on GCP at server.attentionlabs.ai, model-agnostic in front of any ASR and meeting-intelligence stack you already license.
Licensing is per device. A DPA is available on request.
integration path
Software layer only, no hardware change
One thin SDK stage in front of your existing pipeline. Your room hardware, microphone array, and ASR vendor stay unchanged.
access
Eval tier is free. Licensing is per device.
Or try the Cloud SDK first to get a feel for the integration.
Request an evalWhy the existing stack misses it
Diarization knows who spoke. It does not know whether they were talking to you.
Every layer your meeting stack runs today solves a real problem. VAD catches speech. Diarization labels the speaker. Beamforming cleans the signal.
None of them decides whether the assistant is the one being addressed. That is why side conversations still reach the summary.
| Layer | What it answers | When it runs | Decides intent of address? |
|---|---|---|---|
| Voice activity detection (VAD) | Is someone speaking? | Pre-ASR | No |
| Beamforming and AEC | Is the audio cleaner or spatially filtered? | Pre-ASR | No |
| Speaker diarization | Who spoke, and when? | Typically post-ASR | No |
| Speaker ID | Is this a known voice? | Typically post-ASR | No |
| Wake word | Was a trigger phrase said? | Pre-ASR | Phrase only, not intent |
| SAA addressee detection | Is the assistant being addressed right now? | Pre-ASR, before STT | Yes |
Meeting-agent and room-audio teams whose product promise is a clean, trustworthy recap.
Common questions
What meeting-platform and hardware teams ask before integrating.
Why do side conversations end up in my meeting summary?
VAD and diarization tell your meeting AI that someone spoke and who spoke, not whether they were addressing the assistant. When two people hold a side conversation in the corner of the room, the assistant has no principled way to exclude it, so the aside lands in the summary anyway.
Is diarization enough to fix attribution?
No. Diarization tells you who spoke, usually after transcription, not whether they were addressing the assistant. SAA adds that intent-of-address decision upstream, before the assistant acts on any turn.
How does SAA decide intent of address in a meeting room?
SAA analyzes acoustic and prosodic signals in the audio stream, no wake word, no language parsing, no GPU required. It decides in real time, before speech-to-text, and fails closed when uncertain, meaning it does not forward the audio or trigger a summary entry.
Does SAA integrate at the hardware level or through the meeting agent?
Through the meeting-agent or room-audio software layer, not hardware. A thin SDK gates which turns reach the assistant, no firmware change needed, and SAA is model-agnostic in front of whichever ASR and meeting-intelligence stack you already run.
How do we evaluate SAA on our own meeting audio?
The evaluation tier is free. Request an eval and we provide API keys, an eval kit, and the client SDK so you can run SAA against audio representative of your own meeting rooms.
How is SAA licensed, and what does it cost?
SAA is licensed per device, not by usage or call volume. The evaluation tier is free; request an eval to run it on your own meeting audio, or book a call for commercial terms.
Get in touch
A clean summary starts with knowing who was talking to the assistant.
Tell us about your meeting platform or room-audio hardware and what you are trying to improve. We will follow up with next steps for a free evaluation on audio from your own environment.
Last updated June 26, 2026