A message never spoken was sent to our end

Support Help
1

Hey I wanted to share a bug that we found that was pretty messy and it impacted in our production environment: In this call: call_d279558ba730cab02b9b864698a We received a “yes” message that if you hear the conversation it was never said and it triggered a a series of tools and actions that led to booking a real appointment. Here is the log:
2026-04-29 14:59:29.068 call_d279558ba730cab02b9b864698a verbose: Sending updates (transcript trimmed to last 2 utterances): {
transcript: [
{
role: 'agent',
content: 'No problem, I will register you without the insurance information now. Before your appointment, please either log into your Ognomy account to add it, or send it by email to support@ognomy.com so the team can verify your coverage in time. - - - - - I have registered you successfully. The soonest opening I have is Wednesday, May 6 at 7:40 AM with Joseph Matias. Does that work for you?',
words: [Array],
metadata: [Object]
},
{ role: 'user', content: 'Yes. ', words: [Array] }
],
interaction_type: 'update_only'
}
After the agent message that you can see there, we received a single “yes” that was never said. Looking forward to your reply as this is an urgent matter on our side. Thank you.

2

Hello @emilia

Thank you for the details. I’ve forwarded them to our team for review.

We’ll get back to you as soon as we have an update.

Best regards

3

Hello @emilia

Team checked and this seems like an interim asr result (transcribed to “yes”) was sent to the custom LLM and triggered a series of tools and actions on your backend. A few mitigations that will fully prevent this:

  1. Make booking require explicit, specific re-confirmation in your LLM prompt. Don’t let a single “yes/yeah” book — have the LLM ask “Confirming Wednesday, May 6 at 7:40 AM with Joseph Matias — should I book it?” and only then call the tool. This is the most reliable fix because it removes the one-word-affirmative ambiguity entirely.
  2. Lower responsiveness on the agent (currently 0.93, very aggressive).
  3. Make booking idempotent on your side, keyed on call_id + slot, so if a turn gets canceled you can detect and roll it back. (You already cancel on the next user turn, which is great — the goal is to not commit on a discarded turn at all.)

Thank You