BeeAI
Replies: 1 comment 5 replies
-
|
For me, "deployment" means running agent(s) remotely, not on my laptop. I like to think about it as a continuum of different types of deployments, from a single, standalone agent all the way to a managed, multi-agent enterprise platform. For what it's worth, most of the use cases I've seen are closer to the former than the latter. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @psschwei ! you are mentioning individual agents, how about the actual UI (list of agents) or generally the platform server, is that something you consider integral part of the deployment? For instance; The ACP specification does not necessarily depend on a platform server and i can have a use case where i need to deploy just two agents communicating with each other. One of them may expose ACP channel to any of my services. |
Beta Was this translation helpful? Give feedback.
-
|
Good question -- I don't think it's necessary, but it's an extremely nice to have depending on the use case. There are certainly cases where maybe I don't need a UI, like say some kind of Github agent, where I'd be using webhooks and the Github API. For others though, espcially chat-based agents, a UI is pretty much table-stakes. And I don't think I'd want to have to be setting up a separate UI for each agent, so in this scenario the platform server probably should be required. That's a very long way of saying, it depends 😄 |
Beta Was this translation helpful? Give feedback.
-
|
+1 and we have requests for both. |
Beta Was this translation helpful? Give feedback.
-
|
Based on experience and documented in a video and in a blog post Develop and Deploy Custom AI Agents to watsonx.ai on IBM Cloud Main Personas:
Tools:
Agents:
Platforms / System Stack: Local (Developer)
OpenShift (IT Operation)
|
Beta Was this translation helpful? Give feedback.
-
Use case: hosted demosFor hosted demo purposes, we use the BeeAI platform to showcase various hosted agents and we treat each agent as an independent service running in its own OCP pod. The platform is being deployed alongside them in the same cluster. This gives us flexibility in managing updates across the separate agents/demos without coupling everything into a single image; especially important if we need to iterate quickly and in the event one agent broke, we don't lose access to the rest. Hosted demos often sit behind a VPN, which we get through deploying on a Kubernetes cluster, so support for that is useful! For demos, it might be okay to assume that all models will run on one infrastructure, but a fall-back mechanism at the Platform level might be helpful as well For example, if a model-hosting service is down, can we route those requests elsewhere? |
Beta Was this translation helpful? Give feedback.
-
One of the key considerations, as pointed out in https://github.com/orgs/i-am-bee/discussions/428, is whether a Docker-based solution for the platform is sufficient or if we need something more robust, it is invetably related to how users typicaly expect the agents and the platform to be deployed.
Definition of Deployment
We still need to understand users' needs and expectations around "Deployment." Here are some key use cases we've been considering.
Local Installation
The user installs the platform locally to explore the available agents or integrate their own agents to test multi-agent workflows. That's how the platform was originally envisioned to be used.
Individual Agent Deployment to Existing Infrastructure
User prefers deploying a specific agent to their existing infrastructure. Containerization supports this use case well, and communication is handled via the Agent Communication Protocol.
Multi-Agent Deployment to Existing Infrastructure
The user wants to deploy multiple agents to their existing infrastructure. Again, containerization aligns with this use case, and robust inter-agent communication (introduced via ACP) is crucial.
Deployment of the Entire Platform
User deploys the full platform: the agent catalog, platform server, and all out-of-the-box agents. Users may also include their own or GitHub-hosted agents.
One real-world example could be a small company that wants to share the entire platform internally so that all team members can experiment with and collaborate on the agents being shared.
Key distinction:
Potential Paths
We've been thinking about some potential ideas we can further explore:
Docker-based Solution
The platform only depends on Docker being available on the machine and uses it to manage the lifecycle of agents, where an agent is essentially a Docker container. The system interacts with the containers via the Docker API.
Lima VM-based Solution
The platform installs and depends on its own Lima VM, which then serves as an isolated environment to run the dockerized solution. This offers more control over the environment and networking.
Kubernetes Based Solution
The platform would run inside a Kubernetes cluster. This isolated environment provides robust control for running dockerized solutions, offering the highest flexibility and scalability. This might work really well with turnkey mode for production deployments.
Call To Action
Please share your thoughts on potential use cases and expectations when it comes to "Deployment."
Beta Was this translation helpful? Give feedback.
All reactions