Thanks — this is a great, clear question. I’m responding to your four specific asks about reliably pushing option chips after each agent utterance (so the LLM doesn’t need to call show_options). Short answer • Use the AgentSession event conversation_item_added. It fires after each message (including the assistant’s completed reply), so you can inspect the final text and then call your RPC (e.g., agent.displayUI) to push chips. This makes the UI deterministic and server-controlled. What to hook into (Q1) • Use session.on("conversation_item_added"). This event is triggered when any conversation item (user or assistant) is added to the session. It runs after the agent’s reply text is available, so it’s the reliable post-generation hook you want. Can you inspect text and call RPC there? (Q2) • Yes. In that handler, filter items where role == "assistant", extract the text, run your logic to determine chip options, then call your RPC to the frontend (for example, via ctx.room.local_participant.rpc.invoke or whatever RPC mechanism you already use). That will push chips regardless of whether the LLM invoked show_options. Recommended pattern and example (Q3) • Pattern: subscribe to conversation_item_added → detect question type from assistant text → call RPC to display chips. • Key points: ◦ Do not rely on the LLM to call show_options for deterministic UI. ◦ Keep the detection logic server-side (simple heuristics or a small classifier). ◦ Optionally, disable or deprioritize the show_options tool in prompts to avoid tool loops. Minimal example (Python-like pseudocode)

@session.on("conversation_item_added")
async def on_conversation_item(item: ChatItem):
    if item.role != "assistant":
        return

    text = item.text_content()
    options = detect_question_type(text)  # your heuristic/classifier
    if not options:
        return

    await ctx.room.local_participant.rpc.invoke(
        method="agent.displayUI",
        data={"type": "options", "options": options}
    )

detect_question_type suggestions • yes/no: if text contains phrases like "yes or no", leading question verbs, or ends with a yes/no prompt → return ["Yes","No"] • year/date: detect tokens like "what year", "when", or pattern matching for numbers → return plausible years/options • condition/choices: parse enumerations or known catalog keys when present Notes on tool_choice and avoiding loops • Setting tool_choice="required" leads to tool loops or suppressed speech as you observed. With the server-side event approach, you can: ◦ Keep show_options as an optional tool (for when the model intentionally wants to call it). ◦ Rely on conversation_item_added for deterministic chip pushes. ◦ Optionally remove or temporarily hide the show_options tool in the agent’s toolset if you want to fully prevent the model from calling it. Other hooks (when you might use them) • Speech playback callbacks (e.g., SpeechHandle callbacks) exist if you need to run something strictly after audio playout finishes (visual feedback tied to TTS end). But for getting the final text and pushing UI, conversation_item_added is simpler and more reliable. Examples & references (useful) • conversation_item_added is part of the AgentSession lifecycle and is the right post-generation hook for this use case. • You can combine this with small server-side state (a short state machine) to ensure the correct chip set for multi-step flows. If you’d like, I can: • Provide a complete working agent template (full file) with a robust detect_question_type implementation. • Show a version that also waits for TTS end before showing chips, if you need chips to appear exactly after audio completes. Which would you like next: the full template, or a focused detect_question_type implementation tuned to your catalog + dynamic questions? Sources: Agent session | LiveKit Documentation | Turns overview | LiveKit Documentation | Pipeline nodes and hooks | LiveKit Documentation