-
Notifications
You must be signed in to change notification settings - Fork 5
Support agent orchestration #257
Copy link
Copy link
Open
Labels
featureCategorizes issue or PR as related to a new feature.Categorizes issue or PR as related to a new feature.needs-priorityIndicates a PR lacks a label and requires one.Indicates a PR lacks a label and requires one.needs-triageIndicates an issue or PR lacks a label and requires one.Indicates an issue or PR lacks a label and requires one.
Milestone
Description
Metadata
Metadata
Assignees
Labels
featureCategorizes issue or PR as related to a new feature.Categorizes issue or PR as related to a new feature.needs-priorityIndicates a PR lacks a label and requires one.Indicates a PR lacks a label and requires one.needs-triageIndicates an issue or PR lacks a label and requires one.Indicates an issue or PR lacks a label and requires one.
Type
Fields
Give feedbackNo fields configured for issues without a type.
What would you like to be added:
To run agents on kubernetes, there're several concerns, one of them is what if we want to extend the agents to different cloud providers, for example, if you want to user amd GPUs on aws, it's impossible. Then if we want to run agents on different providers, we need to make sure there's no security concern in the sandboxes, like no apikeys stored there, the llm can not do anything they want.
We saw similar architectures from:
Both of them keep the agent a quite clean environment, only for execution. To support this, we need to support sdks to send commands/scripts to the subagents, and they will run this commands once receive these events.
Why is this needed:
Completion requirements:
This feature requires the following artifacts:
The artifacts should be linked in subsequent comments.