I'm trying to implement a multi-tenant system wher...
# ask-ai
s
I'm trying to implement a multi-tenant system where each customer has their own Agent. I can already route different phone requests to different Agents through dispatch rules, but I'm currently manually starting the Agent using cli.run. I'd like to implement an API endpoint where, when a customer initiates a Start Agent request on the front end, the back end starts the Agent worker. I haven't found any documentation on how to do this. Any suggestions? Thanks.
t
Thanks for reaching out, Ty. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Here’s a friendly guide to help you set up an API endpoint for starting an Agent worker programmatically in your multi-tenant system. Let’s walk through it step-by-step: 1. Define the Agent with an
agent_name
in `WorkerOptions`:
This turns off automatic dispatch and lets you control dispatch explicitly through the API. For example:
Copy code
if __name__ == "__main__":
    cli.run_app(
        WorkerOptions(
            entrypoint_fnc=entrypoint,
            agent_name="outbound-caller",  # This enables explicit dispatch
        )
    )
1. Use the
AgentDispatchService
API to dispatch the Agent:
Once your worker is up and running, you can programmatically dispatch it to a specific room like this:
Copy code
import asyncio
from livekit import api

room_name = "my-room"
agent_name = "outbound-caller"

async def create_explicit_dispatch():
    lkapi = api.LiveKitAPI()
    dispatch = await lkapi.agent_dispatch.create_dispatch(
        api.CreateAgentDispatchRequest(
            agent_name=agent_name,
            room=room_name,
            metadata="my_job_metadata"
        )
    )
    print("created dispatch", dispatch)
1. Make sure the Agent worker is running: Simply start the worker script so it connects to the LiveKit server, like this:
Copy code
python agent_worker.py dev
1. Handle multi-tenancy: Keep things isolated by using room isolation and pass any tenant-specific info through the
metadata
field in
CreateAgentDispatchRequest
. 2. (Optional) Build a dispatcher service: If you want, you can create a custom service (maybe with FastAPI) to manage your worker processes dynamically. This method lets you activate Agents on demand, perfectly tailored for your multi-tenant setup. If you have any questions or want to dive deeper, just let me know—I’m here to help! Sources: Making calls using SIP | LiveKit Docs | Making calls using SIP | LiveKit Docs | Dispatching agents | LiveKit Docs | examples/avatar_agents/audio_wave/dispatcher.py
s
I'm not talking about dispatching a registered agent to make an outbound call, but rather about initiating a request on the frontend and then registering an agent on the backend API endpoint. if name == "__main__": cli.run_app( WorkerOptions( entrypoint_fnc=entrypoint, prewarm_fnc=prewarm, agent_name="inbound-agent", ) )
t
Just to make sure I’m on the same page—are you asking about how to dynamically start the agent worker process itself (like launching a new process for the agent) when a frontend request comes in? Or are you wondering about how to register an agent that’s already running with LiveKit through the backend API? Getting this clear will help me give you the best advice tailored to what you need. Sources: Agent dispatch | LiveKit Docs | src/pages/api/token.ts | examples/agent-dispatch/index.ts | examples/agent_dispatch.py | protobufs/livekit_cloud_agent.proto
s
are you asking about how to dynamically start the agent worker process itself (like launching a new process for the agent) when a frontend request comes in ? YES
t
If you want to dynamically start an agent worker process whenever the frontend sends a request, a great way to do this is by creating a dispatcher service that launches agent workers as subprocesses. Here’s a friendly step-by-step on how you can make this happen: 1. Set up a dispatcher server: You can use something like FastAPI to create an HTTP endpoint that listens for requests to start agents. 2. Get the connection details: The frontend can send over parameters like the room name, LiveKit URL, and authentication token via a POST request. 3. Start a new agent worker subprocess: Use
subprocess.Popen
to spin up a new Python process for the agent worker. Just pass the needed environment variables (like
LIVEKIT_URL
,
LIVEKIT_TOKEN
, and
LIVEKIT_ROOM
) so the agent connects properly to LiveKit. 4. Keep an eye on the workers: It’s a good idea to monitor and clean up these subprocesses when they’re done to keep things running smoothly. Here’s an example of what the POST request payload might look like when the frontend talks to the dispatcher server:
Copy code
{
  "room_name": "test-room",
  "url": "<wss://your-livekit-server>",
  "token": "your-agent-token"
}
For a hands-on example, check out the
dispatcher.py
file in the LiveKit Agents repo. It shows exactly how to spin up agent workers dynamically using FastAPI and
subprocess.Popen
. If you want, I’m here to help with more details or code snippets to get your dispatcher service up and running! Sources: examples/other/translation/multi-user-translator.py | LiveKit Docs | Worker lifecycle | LiveKit Docs | Anatomy of an Agent | LiveKit Docs | Worker options | LiveKit Docs