Yeah, we’ve noticed this occasionally too, especially right at the start of calls.
Annoying while carrying out a demo for sure.
But in production, it tends to be overlooked.
It tends be like the agent briefly hears its own opening line, treats that audio as caller speech, and then interrupts/restarts itself. In our case it has usually been a low-frequency blemish rather than something that breaks the actual workflow, so we haven’t treated it as a major production blocker — but it is definitely noticeable when it happens.
Very very annoying I do understand.
Especially when clients are expecting perfection. It kind of sounds like malfunction.
This is where the right wording from you comes in 
.
A few things I’d look at:
-
Caller-side echo / speaker bleed
If the caller is testing on a laptop speaker or phone on speaker mode, the mic may be picking up the agent’s own TTS audio. That can look like a “user” interruption even though the user didn’t actually speak.
-
Opening message timing
This seems more likely at the very beginning of the call, when the connection, mic, playback, and interruption detection are all settling in. A slightly shorter opening line can sometimes reduce the chance of self-interruption.
-
Interruption sensitivity
Your interruption threshold at 0.9 seems reasonable if you still want real callers to be able to interrupt. I’d be careful lowering it too much because then the agent may ignore actual caller interruptions.
-
Eagerness
0.8 is fairly eager. If the agent is reacting too quickly to partial/noisy audio, slightly reducing eagerness may help it avoid jumping on false interruptions.
-
Denoising / background speech removal
This can help, but if the agent’s own voice is being picked up clearly through the tester’s mic, denoising may not fully solve it. Echo cancellation is a different problem from general noise removal.
My guess is this is a mix of endpoint echo, interruption detection, and early-call timing rather than a prompt issue.
A practical test would be to reproduce the same call path with headphones or a handset instead of speaker output. If the issue disappears, it is probably speaker-to-mic leakage. If it still happens with clean audio, then it is more likely something in the voice runtime/interruption handling and worth sending Retell the call IDs.
For now, I’d probably try:
-
slightly shorter opening greeting
-
slightly lower eagerness
-
testing with headphones/clean audio
-
collecting call IDs where the transcript shows the agent’s own speech being captured as the user
If it is only happening in a small percentage of calls and not derailing the workflow, I’d treat it as an annoyance to monitor rather than a full architecture issue.
A working agent is nothing short of a tornado of dials and calibrations.
Sometimes looking deep into these types things takes us away from what’s most important…
Deployment!