do i need to start a sesssion and call .say() method inside an agent or can i directly call it by creating a session and not starting it

Thanks for reaching out, Kushagra. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

if i call await session.say(msg). then will the execution wait for it to complete (for agent to say the whole msg) or move to the next code block.

Good question — thanks for clarifying. When you call

await session.say(msg)

, execution will wait until the agent finishes speaking the entire message (or the playback is interrupted) before moving on to the next line of code. Internally,

session.say()

returns a speech handle and awaiting it is equivalent to waiting for the play-out to complete, so your code will be paused until speech playback finishes. If you want non-blocking behavior, tell me which language/runtime you’re using and I can show an example pattern (for example, start the speech without awaiting the handle or run it in a background task) so the rest of your code can continue while audio plays. Sources: Agent speech and audio | LiveKit Documentation | How to detect when an agent has finished speaking | LiveKit, with interactive elements

can i use api.LiveKitAPI in any function or do i need to reference session or pass it as parameter

Thanks — good question. You're asking whether

api.LiveKitAPI

needs to be referenced from a session or passed around, or if you can just use it directly in any function. Short answer • You can instantiate and use

api.LiveKitAPI

in any function — it does not need to be tied to an

AgentSession

or passed through a session object. Key details and best practices •

LiveKitAPI

is a server-side client for LiveKit APIs (room/participant/SIP/dispatch management). It operates independently of a session/room connection. • You must provide the required credentials (URL, API key, secret) when creating the client. • Call

await lkapi.aclose()

(or the language-equivalent close) when you’re done to free resources. • For performance and simplicity, prefer reusing or caching a client instance rather than creating a new one on every call—especially inside hot paths or worker loops. When you might pass it around • If your function already has lifetime-managed resources (for example, a long-running worker, an agent process, or request-scoped objects), you may pass the

LiveKitAPI

instance as a parameter to avoid re-instantiation. • Passing the same client also makes testing easier (you can inject a mock). If you’d like, I can: • Show an example in the language you’re using (Python, Node, etc.). • Suggest a reuse/caching pattern appropriate for your architecture (singleton in server, dependency injection, or request-scoped client). Which language or code structure are you using? Sources: Python SDKs | livekit/livekit_composite | DeepWiki | Outbound Calling Script | LiveKit Documentation | Python Agents: Handling exceptions in your entrypoint | LiveKit, with interactive elements