Thanks — this is a great question and I hear the concern: you implemented a 30-question survey as a TaskGroup, started seeing duplicate STT streams and resource cleanup issues mid-survey, and want to know whether TaskGroup is the right primitive for long surveys. Short answer • TaskGroup can work for short, structured multi-step flows, but it is experimental and not ideal for very long surveys. • For 20+ questions, the recommended pattern is a tool-driven loop (your current workaround). It’s more scalable and avoids repeatedly creating/tearing down media pipelines. Why the tool-driven loop is preferable for long surveys • Single persistent session/pipeline: A tool-driven loop lets you keep one persistent agent session and one STT/TTS pipeline instead of spawning many short-lived pipelines per task. That avoids duplicate STT streams and the cleanup problems you observed. • Better resource control: You manage when to open/close media resources explicitly rather than relying on internal task transitions that may create temporary pipelines. • Flexibility for conditional flows: It’s easy to branch, skip, or repeat questions based on prior answers without needing to restructure TaskGroup items. • State persistence: You can incrementally store answers in

session.userdata

(or equivalent) so you don’t rely on TaskGroup merging behavior. • Production-ready: TaskGroup is marked experimental and its API could change; tools + loop are a more stable, explicit pattern for production workloads. When TaskGroup might still make sense • Short surveys (a handful of questions) where you want clearly separated tasks, built-in regression/navigation, and automatic merging of task contexts. • Prototyping where TaskGroup’s ordering/regression features speed development and resource usage isn’t a concern. Practical suggestions to move forward 1. Continue with your tool-driven loop but standardize the pattern: ◦ Keep a single STT/TTS pipeline for the whole survey session. ◦ Use a single AskQuestion tool that you call repeatedly with different question parameters. ◦ Store answers as you go in

session.userdata

(or your session store). 1. Add checkpoints and resumability: ◦ Persist progress periodically so long surveys can resume if a session disconnects. 1. Monitor and ensure cleanup: ◦ Explicitly open the STT stream at survey start and close it at the end (or on error), rather than relying on per-question teardown. 1. If you need TaskGroup features (e.g., regression), consider a hybrid: ◦ Implement the main flow as a tool loop, and only use TaskGroup for sub-flows of a few related questions where regression is required. 1. If you want, I can help with: ◦ A minimal code sketch of a tool-driven loop pattern (AskQuestion tool + state handling). ◦ A checklist for opening/closing STT/TTS pipelines to avoid leaks. ◦ A hybrid design showing where TaskGroup could fit safely. Would you like a short code sketch for the tool-driven loop (with session state and explicit STT handling) or a checklist for pipeline lifecycle management? Sources: Tasks and task groups | LiveKit Documentation | Building multi-agent architectures with LiveKit agents | LiveKit, with interactive elements