-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a drag and drop team builder interface for AGS #4202
Comments
Thanks @victordibia for the analysis. Thoughts:
|
I think we also want to separate these two concepts for component:
Separating these two allows us to ease the breaking changes: if a change impacts just the definition, we don't need to worry about also updating the state, and vice versa. This also allows us to run analytics on the state without the analytic code to reconstruct the components, as some components can be heavy and doing so consumes a lot of compute. |
More regarding the state. I think in the beginning we might want to consider supporting only "ephemeral" components: that is their states exists in memory only. We still store their definitions. So, user can retrieve their designed components, but every time they do the components are all new. We can just have an export function to export all the state in JSON, if user want to see. But no import to start. |
Good ideas and points @ekzhu
|
👍 👍
Yep. I think that's right. |
The current rewrite of AutoGen studio has focused on representing teams declaratively in JSON.
It would be great to add a flexible GUI to let users modify team configurations. A team is made of up compontents - agents (models, tools, etc), termination conditions etc.
Component Serialization Decisions
The team (which defines the main workflow/orchestration behaviors) is the primary component in AGS.
There are two potential approaches for storing declarative team (and other component) specifications in the same internal ags database:
Fully Linked Components
In this approach, each component (model, agent, team, memory etc) maintains relationships at the database level. For example, an Agent table row would have foreign keys to its models and tools. Fetching a team's complete configuration requires traversing these relationships to assemble the full picture.
Pros:
Cons:
Independent Components
This approach serializes the complete configuration of each component. Rather than maintaining relationships, a team's configuration includes the full definition of all its agents, including their tools, models, and other settings. When you store a team using the weather_api tool, that tool's entire configuration is part of the team definition.
Pros:
Cons:
Key Decision Factors
The choice depends heavily on use case. For experimentation and reproducibility, Independent Components shines - each team captures a precise snapshot of its configuration at a point in time. For production systems prioritizing consistency, Fully Linked Components ensures changes propagate automatically.
A hybrid approach storing both relationships and snapshots is possible but adds complexity. The benefits of Independent Components - reproducibility, schema flexibility, and configuration portability - likely outweigh the storage overhead from duplication for most use cases.
Happy to get thoughts here.
@husseinmozannar , @ekzhu , @JingyaChen
The text was updated successfully, but these errors were encountered: