-
Notifications
You must be signed in to change notification settings - Fork 7.8k
Supporting Teams as Participants in a GroupChat #5863
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
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #5863 +/- ##
==========================================
+ Coverage 80.74% 80.76% +0.02%
==========================================
Files 234 234
Lines 17892 17985 +93
==========================================
+ Hits 14447 14526 +79
- Misses 3445 3459 +14
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
python/packages/autogen-agentchat/src/autogen_agentchat/teams/_group_chat/_base_group_chat.py
Show resolved
Hide resolved
|
Just to play devil's advocate on the implementation here. This turns the entire Again, the above is a straw man and I think either way is great, just thinking out loud. |
|
@EItanya For unifying both One limiting factor of the custom agent wrapper approach is that the The benefit I see for the new nested team feature is simplicity. It reduces the lines of code and speedups prototyping. Regarding a declarative workflow APIs, I believe they can eventually become the low level API that we use to implement these high-level AgentChat patterns. Especially after #5787 |
|
Got it, I think I understand and agree. The behavior I want is more akin to the current wherein I run a society of mind like agent to keep the internal team encapsulated and just return a final result. Having both options will absolutely unlock more powerful options! |
|
Hi @ekzhu. When you have a moment, could you please provide an update on the current status of this pull request and, if possible, share an estimated timeframe for its merge? Currently I'm using the wrapper agent to nest the teams, and this feature would greatly improve the experience of working with nested teams in autogen. |
|
Out of curiosity, wouldn't agents/teams as tools work for this use-case? |
Would be different, as the agent/team tools does not have access to the full context of the caller, and is driven by the caller agent's model. In the case of nested teams, it is about adding to the topology of group chats. While both are nested and hierarchical, they are quite different in how they are triggered and how context is shared. |
python/packages/autogen-agentchat/src/autogen_agentchat/teams/_group_chat/_base_group_chat.py
Show resolved
Hide resolved
|
Overall, I think this works well for GroupChat usecases (where all message transparency is some type of implicit requirement - i.e, the state of the task is the conversation and for this to work all agents should see the conversation).
It might be worth adding a line in the description to clarify what we mean by inference. Overall, looks good.
|
Updated
It will break type hints of subclasses of the internal classes Will move to version 0.7.0 for the next release. |
|
Nested teams pattern for group chat. This is a draft design for getting ideas. I have found this to be very useful.
Generally, the idea is to forward all
ChatMessagefrom the parent team to the nested team and forward allChatMessagefrom the nested team to the parent team.Difference between this and
SocietyOfMindAgent: it doesn't perform any additional model client call or encapsulation of internal chat messages. The inner team is transparent to the parent team and vice versa. All agents share the same context as they all have access to the same set ofChatMessage. However, this pattern allows for flexibility in setting the order of speakers, as now you can have "inner loops".See example: