How to structure a Python project with multiple agents sharing code

This question originally came up in our Slack community and the thread has been consolidated here for long-term reference.

What’s the right way to structure a Python project to deploy multiple agents while sharing some code and using a single pyproject.toml between them?

One common approach is to have a single agent entry point for all your agents, then determine which agent logic to invoke when the entrypoint gets called. You can use dispatch metadata to customize behavior within the entrypoint.

Note that with this approach, all agents would share the same agent name - this applies to both self-hosted and LiveKit Cloud deployments. The agent name is defined before the entrypoint, so you can’t have different agent names while sharing a single entry point.

What if it’s absolutely necessary for agents to not share a name? In general, is there a way to just push a docker image to livekit cloud that we build ourselves?

You can have many agents each with their own names. Just is shared code if you want to share code.

I am not sure what your question is

I’m trying to use uv workspaces to have several agents and share code between them. The issue is that lk agent deploy has to be run from the subdir with a dockerfile, but the build context then doesn’t include the full project and required dependencies.

I was referencing the “single entry point for all agents” and “all agents would have the same name” answer above, where I would like different entrypoints for different agents that share code within a uv workspaces project. Just wondering what people are doing, or if this is an unsupported use case.

I hadn’t come across uv workspaces before, I had assumed you were referencing some shared code path between two agents.

From a quick read, since lk agent deploy doesn’t allow you to specify the dockerfile, if you wanted multiple agents in the same project with uv workspaces, you would need to swap in and out the required dockerfile before calling lk agent deploy.

For now, I think your options are:

  • Use uv workspaces but with logic before your deploy step to copy files around
  • Use separate projects for your agents, with shared code

Yep, I’m just moving Dockerfiles around before deploy via a script now but would love more flexibility in how lk agent deploy works – specifying a dockerfile or even pushing our own image could generalize pretty well.

1 Like