Conversation node's static_text instruction never spoken — else edge fires ~3s after node entry

Support Help
1

Environment

  • Agent: agent_2a6181065f2655ba7e85366277, version 0
  • Conversation flow: conversation_flow_b2581351ebc8

Affected calls (2/2 reproduction)

  • call_d0d371fa756cc1f7cb45cb2d77c — 2026-07-22 02:31:11 UTC
  • call_b25dc8dd8ba81972a0ca9d2ce99 — 2026-07-22 02:47:13 UTC

Issue
The node confirm_lang_en-US is a conversation node with a static_text instruction (a yes/no confirmation question) and speak_during_execution: true. In both calls above, the flow entered this node but the static text was never spoken — there is no agent utterance between node entry and node exit in transcript_with_tool_calls. About 3 seconds after entry, the node’s else edge fired and the flow moved on, so the caller was never asked the question the node exists to ask.

Timeline from transcript_with_tool_calls of call_d0d371fa756cc1f7cb45cb2d77c:

  1. t=17.86s — transition into confirm_lang_en-US
  2. t=17.86s–20.78s — no agent utterance; the caller is finishing a sentence that began before node entry
  3. t=20.78s — else edge transition out of the node

Expected: the node speaks its static_text instruction and edges are evaluated against the caller’s response to it.
Actual: the instruction is skipped and the else edge is evaluated against caller speech from before the node was entered.

Questions

  1. Why does a conversation node with a static_text instruction transition out without speaking the instruction? Is there a race when the caller is mid-utterance at node entry?
  2. Is there a way to guarantee the instruction is spoken and a caller response received before edges are evaluated?

Thanks,
Andrew

2

Hello @andrew3 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.

Thank You

3

Thanks.

It’s continuing to happen.

Static text conversation node skips saying anything and takes its else edge directly to the next node.

call_934373e04863c5c4f4c6303976c
call_a2ebe90b08a86e16a3e9c961986

Any guidance is appreciated.

Thanks,
Andrew

4

Hey @andrew3 The static_text isn’t being silently skipped; it’s losing the race with an in-progress caller turn.

  • Upstream router fires on a partial caller turn. On call_d0d371…, the extract_dynamic_variables branch completes at t≈17.86s (returning detected_language=en-US from “Do you have any room available tomorrow?”) and confirm_lang_en-US is entered at 17.862 — but the caller keeps going (“Website shows no vacancy…”) through ~19s, so the TTS never gets a floor to render on. On call_b25dc8…, the static_text actually did start (word “It” at 16.122s) and was barged by the caller continuing at 16.26s. interruptionSensitivity is 0.65 on the agent, which is moderate and lets the caller’s continued speech barge in.

  • Else edge then evaluates against a caller turn that never answered the language question. Once the caller finally yields, the classifier looks at the last committed caller turn — but that turn was uttered before the confirmation was posed, so it matches neither “agrees” nor “declines”. Else fires → transfer_to_ja-JP, which is why the outcome contradicts the just-detected en-US.

So the failure mode is a floor/barge race, not a static_text rendering bug. static_text on a conversation node does speak deterministically on entry — it just can’t hold the floor against a caller who’s still mid-utterance.

A few directions we’d want to validate together before you change the flow:

  • The highest-leverage change is preventing the upstream router branch from firing on a partial turn. If you can restructure so language detection runs after the caller’s turn is committed (e.g., a gating condition on the preceding node, or moving the extract step behind a short silence gate), the downstream confirmation node will be entered with a clean floor.

  • Broaden the Else on confirm_lang_en-US so a non-answer stays on the node (or routes to a re-prompt) instead of jumping straight to transfer_to_ja-JP. This alone would keep bad routing from happening even if the race recurs.

  • Lowering interruptionSensitivity on this node’s window would make the TTS harder to barge, but it also changes UX broadly — we’d want to test rather than recommend blindly.

  • Moving the confirmation to a function-node static_text is sometimes suggested, but static_text on a conversation node already has speak-on-entry semantics, so this is unlikely to fix the underlying race by itself.

Thank You

5

Thanks for the explanation.

We’ve added “Else” edges on conversation node prior to the confirm_lang_en-US node as well as the confirm_lang_en-US node itself because we noticed that without these edges sometimes we get stuck inside the node and the LLM starts hallucinating answers for topics outside of the main purpose of the node.

Based on your info, I’ve been able to consistently reproduce the issue and I think setting interruption sensitivity to 0 for the confirm_lang_en-US node will achieve more desirable behavior. We’ll test this out.

Andrew