Category definition · Engagement control
Addressee detection: the layer the voice stack was missing.
The pre-ASR layer that decides whether speech is addressed to your device.
Definition
What addressee detection is and what it is not.
Addressee detection classifies whether speech is directed at the device or at someone else, in real time.
It is a pre-ASR gate: raw audio is classified before transcription, and only addressed speech moves downstream.
Most speech near a voice AI is not meant for it: a drive-thru lane, an open office, an exam room, a home with several people. Without this gate, all of it reaches the ASR engine and the model.
The decision draws on acoustic signals present in raw audio and gone once transcribed. That is what makes it pre-ASR.
VAD detects speech. Wake words detect a phrase. Beamforming finds direction. Diarization labels the speaker later.
None of them answer is the device the intended recipient?
The gap
Voice AI hears everything in the room. Nothing decides who is being addressed.
A microphone in a real room is not a phone line. It captures bystanders, background media, and ambient noise alongside whoever is actually addressing the device.
environment mismatch
A single-user stack deployed in a multi-party world
VAD and wake words assume one user at a time. Voice AI now runs in lanes, lobbies, and vehicles with many speakers.
cost
Every unaddressed utterance generates real ASR and model spend
Voice agents pay for STT, LLM, and TTS on every second that enters the pipeline, addressed or not. SAA drops it first.
high-stakes settings
Wrong-person responses carry real consequences
A wrong drive-thru order costs margin. A wrong exam-room attribution is a documentation error. A false activation in a vehicle is a safety event.
How addressee detection works
A hosted pre-ASR gate. Additive to any existing stack. No ASR swap required.
SAA is a hosted, pre-ASR engagement-control layer. It streams audio, returns a routing decision before ASR runs, and forwards only addressed speech. Uncertain cases fail closed.
Signal in
Audio, and optional video, streams to the hosted SAA service through a thin JavaScript or Python client SDK.
No model runs on the device. No wake word. No GPU required.
Addressee decision
SAA analyzes acoustic patterns in the raw audio. It does not transcribe speech or parse language content.
Before speech-to-text runs, it returns a routing decision: addressed to the device, or to someone else in the room.
Route only addressed audio
Only audio addressed to the device reaches your existing ASR and model stack. Everything else is dropped.
When SAA is uncertain it fails closed and forwards nothing. The rest of the pipeline is unchanged.
architecture
Works in front of any ASR and model
SAA is model-agnostic. Drop it in front of any ASR and language model you already license.
No integration swap required. A DPA is available for regulated deployments.
try it first
The Cloud SDK is self-serve
JavaScript, Python, and REST, live now, so you can get a feel for the routing decision before requesting an eval.
Explore the Cloud SDKComparison
The standard stack answers other questions, not who is being addressed.
These techniques get conflated because they all analyze audio in multi-speaker environments. None of them determine whether the device is being addressed. That is the specific job of addressee detection.
| Technique | Question answered | Runs before ASR? | Requires wake word? | Addressee signal? |
|---|---|---|---|---|
| SAA addressee detection | Is this speech directed at the device right now? | Yes | No | Yes |
| Voice activity detection (VAD) | Is someone speaking? | Yes | No | No |
| Beamforming and AEC | Is the signal clean or directional? | Yes | No | No |
| Wake word detection | Was the trigger phrase said? | Yes | Yes, it is the mechanism | Phrase only |
| Speaker diarization | Who spoke, and when? | No, typically post-ASR | No | No |
Where the gap shows
The same addressee gap shows up everywhere. Only the failure mode changes.
The problem is the same in every multi-party deployment. The failure mode and stakes differ by environment.
Comparison cluster
Deep dives on the specific distinctions:
Performance
Measured performance, caveats included.
SAA reliably decides whether speech is addressed to the device, using audio-video fusion or audio alone (arXiv:2604.08412).
Two caveats apply: the system fails closed under distribution shift; cross-lingual recall is a known limitation under active work.
performance
Accurate on audio alone, or with video
The same addressee decision holds on audio only, or on audio and video fusion when a camera is available. No video stream is required.
latency
Real-time decision
Returned before ASR begins processing the utterance. No GPU required on the device side.
design principle
Fails closed by design
Ambiguous speech is suppressed: under uncertainty, the default is silence, not a false response.
A well-calibrated addressee detector would rather miss an intended utterance than act on an unintended one.
VAD tells you someone spoke. Addressee detection tells you who they were speaking to.
Common questions
What OEMs and developers ask about the addressee layer.
What is addressee detection for voice AI?
Addressee detection is the pre-ASR classification of whether a spoken utterance is directed at the device or at another person. VAD, wake words, and diarization each answer something different; none of them determine whether the device is the intended recipient. Addressee detection is the decision that fills that gap. SAA performs it in real time, before ASR runs, and fails closed when uncertain.
How is addressee detection different from voice activity detection (VAD)?
VAD tells you that someone is speaking. It fires on background conversation, hold music, and bystanders equally. Addressee detection answers the question VAD cannot: is this speech directed at the device. SAA makes that call in real time, before ASR, and fails closed when uncertain.
How is addressee detection different from a wake word?
Wake words require a fixed trigger phrase before every interaction and still misfire when background speech contains the phrase. Addressee detection requires no trigger phrase, uses acoustic signals, needs no GPU, and fails closed when uncertain.
How is addressee detection different from speaker diarization?
Diarization tells you who spoke and when, after transcription. Addressee detection answers a different question: whether the utterance was directed at the device. Knowing the speaker label does not tell a system whether to act. SAA is complementary to diarization, not a replacement.
Why does addressee detection have to run before ASR?
The addressee signal lives in acoustic features present in raw audio, such as pitch, energy, and turn-taking cues. Once speech is transcribed that signal is gone. Running the gate pre-ASR is the only way to prevent unaddressed audio from entering the pipeline and generating spurious model calls.
Where is addressee detection used in production?
Any multi-party voice AI deployment needs addressee detection. Current deployments include drive-thru ordering AI where lane microphones pick up backseat passengers, car radios, and crew crosstalk; service robots and kiosks in public spaces; ambient clinical AI in exam rooms; in-cabin automotive assistants; and wearable or always-on AI in social settings. The problem is the same in each: the microphone hears more people than the device should answer.
Get in touch
Run SAA on your own audio before any commitment.
Evaluations are free. Tell us what you are building; we will send API keys, an eval kit, and the client SDK. Licensing is per device.
Last updated June 30, 2026