Adaptive Turn Handling Ignores Single Word Answers

Agents
1

Hi there,

I’ve noticed that adaptive turn handling by default doesn’t accept single-word answers like “Yes”, “No” or fuller words like “Chicago”. It filters them out as noise. Is there a way to configure this so it doesn’t ignore one word answers? My use-case here is a questionnaire where I anticipate responders may answer with single-words.

I’m looking at the interruption options here and its not immediately clear which knob is the right one Turn handling options | LiveKit Documentation

2

What you’re describing isn’t an interruption since the agent has finished asking its question. The default settings should serve you well:

turn_detection=MultilingualModel(),

Unless your environment is extremely noisy, I would expect the Agent to be able to pick out what you are saying: Noise & echo cancellation | LiveKit Documentation

I think this is more likely your STT settings, can you share your agent session configuration?

To answer your question however, if you wanted to test your hypothesis, you could disable adaptive turn handling as follows:

session = AgentSession(
    # ... stt, llm, tts, vad
    turn_handling=TurnHandlingOptions(
        turn_detection=MultilingualModel(),
        interruption={
            "mode": "vad", <-- This setting
        },
    ),
)
3

@Ubani_Balogun, Building on @darryncampbell’s STT hypothesis, two specific places single-word answers usually drop:

  • STT endpointing too short. A quick “Yes” lands before the final transcript commits; the framework sees no transcript. Check your STT plugin’s endpointing / utterance-finalization settings (Deepgram, Google, AssemblyAI all expose this).
  • Turn detector waiting for more. MultilingualModel is contextual; a bare “Yes” plus silence can read as “user paused mid-thought.” TurnHandlingOptions.min_endpointing_delay is the knob; if you bumped it for phone use, short answers feel swallowed.

Your AgentSession config will pin which one.

4

@darryncampbell / @Muhammad_Usman_Bashir . Thanks for the comments! This ended up getting resolved by a mix of version updates (bumping to 1.4.1) and turn handling configurations. The config I ended up with is below. It seems to have stabilized now but open to any thoughts you have on my current config. Thanks!

turnHandling: {
      turnDetection: new livekit.turnDetector.MultilingualModel(),
      endpointing: { minDelay: 400, maxDelay: 1500 },
      interruption: { backchannelBoundary: null },
      preemptiveGeneration: { enabled: true },
    },
5

Glad you resolved the issue but I’m confused by your turn handling options

endpointing is defined here: Turn handling options | LiveKit Documentation but you need to specify the mode.

backchannelBoundary does not exist, it is not a supported property.

I assume your coding assistant is hallucinating, I strongly recommend you follow the instructions at Coding agent support and tools | LiveKit Documentation to install our MCP server and update your Agents.md file; the difference in how useful the coding assistant is after these changes is significant.

6

Hey @darryncampbell , Can we double confirm this please and clarify please? I’m looking in the livekit/agent-js repository and backchannelBoundary is documented in the codebase (but not in the livekit documentation). See here

Can we also get clarity on whether Dynamic endpointing is supported in the Agent-js library? The official documentation says its supported in Python only but I see the option available in the Agent-js library here

7

@Ubani_Balogun, Looks reasonable. The endpointing tweaks (minDelay 400ms / maxDelay 1500ms) are tighter than the defaults (500ms / 3000ms) [Turn-taking tuning | LiveKit Documentation], which matches the questionnaire use case where short answers benefit from snappier turn closes. preemptiveGeneration: enabled matches the default explicitly [same page], so no behavior change there.

One thing for the future: backchannelBoundary: null isn’t documented on the turn-handling pages I can find, so the behavior you’re relying on is whatever the current Node implementation does. If the bump to 1.4.1 was specifically what unblocked the short-word case, that’s a signal the backchannel handling changed in that release. If your scenarios broaden to longer multi-clause answers, that’s the flag to revisit.

Glad it stabilized.

8

@Ubani_Balogun thanks for flagging: